8 min readmedium+45 XP

Add an MCP Server to an Agent

Learn the concrete moves to register an MCP server with a host: pick the transport, write the config block, declare arguments and environment, and verify capability negotiation before the agent runs.

After this topic, you'll be confident about Host, Client, Transport and 1 more concept.

Add an MCP Server to an Agent

Wiring an MCP server into a host is mostly mechanical, but every host repeats the same four-step pattern: pick a transport, write the config block, supply args and env, and let capability negotiation confirm the server speaks the protocol. Master that template and any host's UI feels obvious.

The config block, dissected

A typical local stdio entry in a host config looks like this:

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "/workspace"],
      "env": { "LOG_LEVEL": "info" }
    }
  }
}

Every field is doing real work:

| Field | Purpose | Watch for | | --- | --- | --- | | command | The binary the host launches. | Use the absolute path or rely on PATH; missing npx/uvx is a top cause of "server failed to start". | | args | Positional flags and scope (e.g. allowed directory). | Always include -y for npx to skip the install prompt. | | env | Secrets and runtime config. | Inject from a secret manager; never commit raw tokens. | | url | Used instead of command for remote HTTP servers. | Mixing url with command is undefined behaviour. |

Capability handshake

When the host launches the server it sends an initialize request advertising which client features it supports (sampling, roots, elicitation). The server responds with its own capabilities — crucially, whether it offers tools, resources and/or prompts. The host then calls tools/list to populate the agent's tool surface. If any step fails the agent sees zero tools and the user sees a silent failure.

The exam loves "tools list is empty" scenarios. The diagnosis is almost always: transport mismatch, server crashed, or server only declared resources.

Assemble the config

+45 XP

Drag the snippets in order to build a valid stdio server entry for the official Git MCP server.

Your config

Empty — pick from the right.

Available blocks

Pick blocks in the right order (0/8)

Where this shows up on the exam

Expect a fill-in-the-config item or a debug scenario ("the agent sees no tools, what changed?"). Remember the order: transport choice → command/url → args and env → capability handshake. When something is wrong, that order is also your checklist.

Anchor concepts

Key terms

Host: The user-facing LLM application (VS Code, Claude Desktop, Copilot CLI) that loads MCP servers and exposes their tools to the model.
Client: The per-server connector inside the host that speaks JSON-RPC 2.0 to one MCP server.
Transport: How the client talks to the server: `stdio` (subprocess, local) or HTTP / Streamable HTTP (remote).
Capability negotiation: The startup handshake where client and server declare which features (tools, resources, prompts, sampling, roots) each supports.

Watch out

Common pitfalls

Forgetting the `-y` flag on `npx` so the server hangs forever waiting for an interactive install prompt — and the host reports 'server failed to start' with no hint why.
Storing secrets directly in `args` instead of `env` so the token ends up in shell history and shared configs.
Mixing transports — pointing a stdio config at an HTTP URL, or vice versa. The handshake never completes and the tool list stays empty.