Study notes · 2.3% of the exam

Evaluate connection protocols and select the appropriate integration mechanism (MCP, API/CLI, agent-to-agent)

Select the right integration mechanism for a capability: MCP for reusable tool and resource exposure across clients, direct API or CLI calls for a single tight integration, and agent-to-agent delegation for expertise owned behind another boundary.

Key points

  1. 1

    Decision rule: MCP when the same tools, resources or prompts must be consumed by several Claude clients (Claude Code, Agent SDK apps, the Claude apps, the MCP connector); direct API or CLI calls in code when one application has one tightly scoped integration and deterministic side effects; agent-to-agent delegation when the capability is a specialized agent that another team maintains with its own data access, guardrails and evals.

  2. 2

    MCP architecture: a host application (Claude Code, Claude Desktop, an SDK app) creates one MCP client per server; the server exposes primitives over JSON-RPC. Write the integration once, reuse it from every host.

  3. 3

    Server primitives and who controls them: tools are model-controlled executable actions (tools/list, tools/call); resources are application-controlled context data (files, schemas, records); prompts are user-controlled reusable templates. Map each capability to the primitive that matches its control model rather than making everything a tool.

  4. 4

    Transports: stdio for a local process serving a single client on the same machine; Streamable HTTP for remote servers serving many clients, with OAuth bearer tokens for authentication. The older SSE transport is deprecated in favour of Streamable HTTP.

  5. 5

    Claude Code scopes: local (private to you and one project), project (.mcp.json committed with the repository and shared with the team, approved before first use), and user (all your projects, not shared). Version-controlled team configuration means project scope.

  6. 6

    The MCP connector lets a Messages API application call tools on a remote MCP server without writing an MCP client: mcp_servers names the server (URL plus optional authorization_token), and an mcp_toolset entry in tools enables, allowlists or denylists individual tools. The server must be reachable over HTTP; local stdio servers cannot be connected this way.

  7. 7

    In the Agent SDK, MCP servers are configured in mcpServers (stdio command, http/sse URL, or an in-process SDK MCP server for tools defined in your own code); MCP tools are named mcp__<server>__<tool> and need explicit allowedTools entries. Large tool results (over 25,000 tokens by default) are spilled to a file rather than the context.

  8. 8

    A plain API call is not worse than MCP; it is the right choice when there is one consumer, the steps are fixed, and side effects such as database writes should be deterministic application code rather than model decisions. Adding an MCP server to a batch pipeline adds a process, a protocol and model-driven writes for no reuse benefit.

  9. 9

    Agent-to-agent delegation (subagents, or a separately deployed agent behind a request/response contract) keeps the other team's privileged data, prompts and guardrails inside their boundary and returns only the outcome. Exposing their tools through MCP or copying their prompts leaks capability across the boundary and bypasses their evals.

  10. 10

    Subagents in the Agent SDK run with their own fresh context, can be restricted to specific tools, and return only their final message to the parent, which is what makes them suitable for cross-boundary or high-volume work without polluting the orchestrator's context.

  11. 11

    Security across all three: least privilege on exposed tools (allowlist, read-only where possible), per-user OAuth identity rather than shared long-lived keys, treat tool results as untrusted input, and never let the model supply an identifier that the application should derive from the authenticated session.

  12. 12

    Distractors the exam likes: pasting API documentation into the prompt as if it were an integration, writing the same tool three times in three apps, wrapping a single-consumer pipeline in MCP "for standardization", using a deprecated transport for a new deployment, and exposing another team's privileged tools instead of delegating to their agent.

Test yourself on Evaluate connection protocols and select the appropriate integration mechanism (MCP, API/CLI, agent-to-agent)

Ten questions, with the answer and explanation after each one.