mcp

MCP — Model Context Protocol Cheatsheet

Practical guide to Model Context Protocol: understand hosts, clients, servers, tools, resources, prompts, auth boundaries, and debugging workflows.

2026-09-25 (3 weeks ago)
5 steps
~85 min total

mcp
model-context-protocol
tools
resources
prompts
servers
debugging

MCP — Model Context Protocol Cheatsheet

One-line: Model Context Protocol is an open protocol for connecting LLM applications to external tools, resources, and prompts through standardized servers that hosts can discover and call safely.

Installation

MCP is a protocol, so installation depends on whether you are using an existing server, building a server, or configuring a host.

# Typical Node project bootstrap for an MCP server
mkdir my-mcp-server
cd my-mcp-server
npm init -y
npm install @modelcontextprotocol/sdk

First-run checklist:

Pick the host application that will connect to MCP servers.
Choose or build a server with a narrow capability set.
Define tools, resources, and prompts with clear schemas.
Test locally before connecting credentials or production systems.

Step-by-Step Setup & Optimization

Step 1 — Learn the topology

Goal: The six MCP components and who controls each oneTime: ~10 minLevel: beginner

Component	Role
Host	The user-facing AI app or IDE.
Client	The host-side MCP connection to one server.
Server	A process exposing capabilities through MCP.
Tool	Model-controlled action with an input schema.
Resource	Application-controlled context such as files or records.
Prompt	Reusable prompt template exposed by the server.

You can explain host vs client vs server and name a tool, a resource, and a prompt.

Step 2 — Start with read-only capabilities

Goal: Working read paths before any write action existsTime: ~30 minLevel: intermediate

Before exposing write actions, build resources and read-only tools.

resources/list        # discover available context
resources/read        # read selected context
tools/list            # discover callable actions
tools/call            # call one action with validated inputs

Write tools should have explicit names, narrow schemas, and auditable side effects.

resources/list and tools/list return your read-only capabilities before any write tool exists.

Step 3 — Design tool schemas for intent

Goal: Tool names and schemas that say what user outcome they supportTime: ~20 minLevel: intermediate

A good tool name says what user outcome it supports.

{
  "name": "search_docs",
  "description": "Search approved project documentation.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "query": { "type": "string" },
      "limit": { "type": "integer", "minimum": 1, "maximum": 10 }
    },
    "required": ["query"]
  }
}

Avoid generic tools like run_any_sql or shell unless the host adds strong approvals.

Every tool name states an outcome and its schema is narrow — no generic run_any_sql or shell.

Step 4 — Treat auth as part of the boundary

Goal: Credentials scoped and stored outside promptsTime: ~15 minLevel: intermediate

Store credentials in the server environment or host-approved secret storage, not in prompts. Scope tokens to the minimum API permissions and log only metadata needed for debugging.

Tokens live in server env or host-approved storage — never in prompts — with minimum scopes.

Step 5 — Debug in layers

Goal: A fixed order for isolating which layer is failingTime: ~10 minLevel: intermediate

When a server does not work, isolate the layer:

Does the process start?
Can the host discover the server?
Do list calls show expected tools/resources/prompts?
Does a minimal valid call succeed?
Are auth, network, or schema errors surfaced clearly?

You identified which numbered layer fails first instead of guessing.

Best Practices

Do

✅ Prefer narrow, intention-revealing tools over broad escape hatches.
✅ Start read-only, then add writes with confirmations and audit logs.
✅ Validate all inputs at the server boundary.
✅ Keep server logs useful but free of secrets.
✅ Version tool names or schemas when breaking clients.
✅ Document who controls each capability: application, user, or model.

Don’t

❌ Put API keys in issue bodies, prompts, or resource content.
❌ Expose raw shell, database, or admin APIs without guardrails.
❌ Assume every host supports the same auth or approval UX.
❌ Change tool semantics without updating descriptions and tests.
❌ Let untrusted documents instruct the host to install or call servers.

Quick Command Reference

Concept or method	Use
`tools/list`	Discover tools exposed by a server.
`tools/call`	Invoke a tool with validated JSON input.
`resources/list`	Discover readable resources.
`resources/read`	Read selected resource content.
`prompts/list`	Discover reusable prompt templates.
`prompts/get`	Retrieve a prompt template with arguments.
`@modelcontextprotocol/sdk`	Official SDK package for building servers in Node projects.

Expected Outcomes

After setup, you should have:

A clear mental model of host, client, server, tools, resources, and prompts.
A local MCP server or configured existing server with narrow capabilities.
Tool schemas that describe intent, validate inputs, and limit side effects.
An auth boundary that keeps credentials out of model-visible text.
A debugging checklist for startup, discovery, schemas, calls, and permissions.

Reference

Sources & deeper reading