MCP

What MCP is

The Model Context Protocol (MCP) is a standard way for the agent to talk to external tool servers. Instead of the agent being limited to reading files and running shell commands, an MCP server can expose anything — a database client, a ticket tracker, a search API — as a set of tools the agent calls by name.

Concretely: you configure a server, the agent discovers the tools it offers, and those tools become available to it like any built-in tool, gated by your permission rules.

When to use it

• The agent needs data that is not in the repo (a running database, an issue tracker, a metrics API).
• You want the agent to take an action through a controlled interface rather than raw shell (e.g. “create the ticket via the API” instead of “open a browser”).
• A tool would be unsafe or awkward as a shell script and safer as a constrained server.

Do not wire up MCP for things the agent can already do well (reading files, running tests). Each server is surface area to configure, permit, and maintain.

How servers are configured

Servers are declared in a .mcp.json file (the recommended approach when you have more than one). Two server types are common:

• stdio — the agent spawns a local process and talks to it over standard input/output.
• sse — the agent connects to an HTTP server (Server-Sent Events).

A stdio entry names the command to run, the args to pass, and any environment variables the server needs. Secrets should come from the environment, not be hard-coded in the config.

A generic example

A stdio server that wraps a database client:

{
  "database-tools": {
    "command": "node",
    "args": ["./tools/db-mcp/index.js"],
    "env": {
      "DB_URL": "${DB_URL}"
    }
  }
}

The ${DB_URL} is read from the environment at launch — the value never lives in the file. After this is configured, the agent can call that server’s tools (a read_query tool, say) the same way it calls Read or Bash.

Permissions are the safety layer

MCP tools are subject to the same permission system as built-in tools. You control them with allow / ask / deny rules. Two patterns that matter:

• Prefer least privilege. Allow the specific tool by name (mcp__server__read_data) rather than a wildcard (mcp__server__*). A wildcard lets the agent call tools you have not reviewed.
• Deny anything destructive. If the server exposes a write or delete tool you do not want the agent using unsupervised, deny it in settings rather than hoping it will not be called.

See Security for the broader permission model.

Pitfalls

• Hard-coding secrets in .mcp.json. The file is often committed. Use environment substitution (${VAR}) and keep the values out of the repo.
• Wildcard permission grants. mcp__server__* approves every tool the server exposes, including ones added later without your review.
• Trusting server output blindly. An MCP tool can return anything. If it returns text the agent treats as instructions, you have a prompt-injection surface. Treat tool output as data, and keep the agent’s permission scope tight.