An AI assistant with a fully connected stack

An agent that sees only the project files is like a new employee with no access to the work systems: capable of a lot, but constantly asking questions. A connected stack is when the agent looks up the task in the tracker, finds the error in monitoring, checks the page in a browser and opens a pull request on its own. Almost all of this connects through a single protocol: MCP.

#What MCP is

Model Context Protocol is an open protocol that standardizes how LLM applications connect to external data and tools. The current revision of the specification is 2026-07-28. Roles:

• Host: the LLM application that initiates connections: Claude Code, Codex, Cursor;
• Client: a connector inside the host;
• Server: a service that provides context and capabilities.

Messages are sent in JSON-RPC 2.0 format. A server can provide:

• tools: functions the model executes;
• resources: data and context for the user or the model;
• prompts: templates for messages and workflows.

The standard transports are stdio (a local server runs as a child process) and Streamable HTTP (a remote server at a single HTTP address). Authorization is defined for HTTP transports and is based on OAuth 2.1; for stdio the specification recommends against using it, since credentials there come from the environment.

#What a stack can look like

The catalog of vetted connectors is the Anthropic Directory. Connectors added to your claude.ai account appear in /mcp and in Claude Code.

#Connecting in Claude Code

Commands from the MCP quickstart:

# remote server
claude mcp add --transport http claude-code-docs https://code.claude.com/docs/mcp

# local stdio server: everything after -- is passed to the server as is
claude mcp add playwright -- npx -y @playwright/mcp@latest

# verify
claude mcp list
claude mcp get claude-code-docs

Scopes. By default claude mcp add registers the server in the local scope: just you and just this project. --scope user is you in all projects (the mcpServers key in ~/.claude.json). --scope project is the whole team via .mcp.json at the repository root. Servers from .mcp.json need approval: a cloned repository cannot approve its own servers until you trust the folder.

Authorization. Services such as Sentry, Linear and Notion work through OAuth: after you add one, claude mcp list shows “Needs authentication”; then in /mcp you select the server and sign in through the browser. For servers that accept a token (GitHub, for example), you pass it with the --header "Authorization: Bearer <token>" flag.

Context. Tool search (MCP Tool Search) is on by default: at startup only tool names are loaded, and the agent loads a tool's full description when it decides to use it. So unused servers take up almost no context.

Channels. A separate kind of MCP server is channels: they push events into a running session (CI results, messages, alerts) so the agent can react while you are away. The research preview includes Telegram, Discord and iMessage.

In Codex and Cursor it works the same way: codex mcp add or the [mcp_servers] section in config.toml; in Cursor, .cursor/mcp.json in the project or ~/.cursor/mcp.json for all projects.

#Risks: what can go wrong

A connected agent reads a lot of other people's text: issues from users, web pages, API responses. Any of them can contain a prompt injection: instructions that try to steer the agent away from your task. OWASP puts prompt injection first in its list of LLM application risks and distinguishes direct injection (through the user's prompt) from indirect injection (through external content the model reads).

Security principles from the MCP specification:

• the user explicitly consents to data access and operations and stays in control;
• the host obtains the user's consent before passing their data to a server;
• tools mean arbitrary code execution; descriptions of tool behavior are considered untrusted unless the server is trusted; the host obtains consent before invoking a tool.

What to do in practice:

1. Connect only servers you trust. The Claude Code documentation warns explicitly: servers that fetch external content carry a prompt injection risk.
2. Minimal permissions for tokens. OWASP recommends giving the application its own tokens and keeping privileged functions in code rather than handing them to the model.
3. A human confirms anything dangerous. Writes, deletions, payments, sending emails: only with confirmation.
4. Deny what isn't needed with rules. The rule "deny": ["mcp__*"] blocks all MCP tools; mcp__github__get_* in allow permits only reads on the github server.
5. Separate untrusted content. Don't feed the agent unvetted text directly, and run scripts and external services in an isolated environment. These are recommendations from the Claude Code security section.

#Where to start

One server for one pain point. Most often, error monitoring pays off first: the agent finds the stack trace and writes a fix with a test on its own. Second is the browser: the agent checks the UI with a screenshot rather than taking its own word for it. Add the rest when a recurring task appears.

The last post in the series is the agent fleet: how to run several agents in parallel without losing control.