Summary

This note summarizes the Model Context Protocol (MCP) — its core features, architecture, security considerations, and practical usage — and documents current support and integration patterns in five representative agent/CLI ecosystems: Goose (Block / codename goose), Claude (Anthropic), Gemini (Google), Amp (unknown / no public MCP-specific data found), and Codex CLI. Research was gathered from public MCP specifications, vendor docs, and community resources.

Goal: provide a compact, practical reference for engineers evaluating MCP-enabled integrations and for authors creating MCP servers/clients for these platforms.

Quick takeaways

  • MCP is an open standard (introduced by Anthropic) that standardizes how LLM-based apps discover and use external tools/resources via a JSON-RPC-based protocol with STDIO and HTTP+SSE transports.
  • Core primitives: tools (callable actions), resources (URI-addressable data), prompts (reusable prompt templates), notifications, and sampling (servers can request LLM completions from clients).
  • MCP emphasizes security: tool allowlists, provider allowlists, OAuth patterns, readOnly/destructive tool annotations, and strong host/server authentication patterns.
  • Support landscape (summary):
    • Goose: strong MCP-first integration model; uses “extensions” to wire MCP servers and declares MCP servers in recipes/configs. (Block/goose)
    • Claude: native backer of MCP; Anthropic provides client/server SDKs, reference servers, and Claude Desktop integrates MCP.
    • Gemini: vendor implementations and docs exist; Google provides tooling and examples (Node/TS, Go) to run MCP servers/clients with Gemini.
    • Amp: no authoritative public references found during this research — treat as “unknown / requires confirmation”.
    • Codex CLI: first-class MCP support via ~/.codex/config.toml and codex mcp commands for adding/listing servers.

MCP: architecture & core features (concise)

  • Protocol model: JSON-RPC 2.0 semantic layer + transport layer (STDIO for local servers, HTTP+SSE for remote streaming and serverclient events).
  • Discovery & handshake: clients ask servers for capabilities (tools/resources/prompts) during initialization.
  • Tools: strongly typed or JSON-schema described callables (name, description, input schema, readOnly/destructive flags, timeouts).
  • Resources: URI-addressable data endpoints (file://, postgres://, http://), support for subscriptions/updates and mime metadata.
  • Sampling: servers may request a client LLM to produce text completions (enables server-assisted agentic workflows without servers holding API keys).
  • Notifications & streaming: support for long-running tasks with progress updates via streaming / SSE.

Support matrix & notes per platform

Goose (Block / codename goose)

  • Integration model: Goose treats MCP-based capabilities as “extensions”. Recipes and sub-recipes declare required extensions; top-level recipe aggregates extension blocks.
  • Practical patterns:
    • Extensions block in recipe for MCP servers (with env_keys for secret names like PERPLEXITY_API_KEY, GITHUB_TOKEN).
    • Local STDIO MCP servers and remote HTTP+SSE MCP servers are both usable; use {{ recipe_dir }} for portability.
    • Goose CLI and recipe validation (e.g., goose recipe validate) indicate recipe-level dependency tracking and deterministic ordering for MCP-enabled workflows.
  • Security & ops:
    • Goose recommends declaring env_keys and using system keyring prompts for secrets.
    • Follow recipe conventions (retry checks, timeouts, structured outputs) when calling MCPs from automated workflows.
  • Sources: project docs, beastmode recipe changes, repository hints (internal docs).

Claude (Anthropic)

  • Native originator & primary vendor for MCP. Anthropic published the MCP specification, SDKs, reference implementations, and the MCP Inspector tooling.
  • Features supported:
    • Tools/resources/prompts, sampling, notifications, STDIO & HTTP+SSE transports.
    • OAuth patterns, provider allowlists, tool approval prompts, and readOnly/destructive annotations.
  • Products:
    • Claude Desktop supports loading local MCP servers; Claude for Work customers can test local MCPs and Anthropic supplies pre-built server examples for common integrations (Google Drive, Slack, GitHub, Postgres, Puppeteer, etc.).
  • Security model: strong emphasis on allowlists, approval prompts for destructive operations, and logging/audit trails.
  • Sources: Anthropic docs, MCP specification, Claude Desktop materials.

Gemini (Google)

  • Google provides examples, SDK snippets, and guidance for MCP with Gemini. Community artifacts and official samples show usage in Node/TypeScript and Go.
  • Integration notes:
    • Typical workflow: run a local STDIO MCP server (or remote HTTP+SSE server), Gemini client discovers and queries tools via JSON-RPC.
    • Gemini’s long-context models pair well with MCP because large context windows reduce the need for external retrieval in some flows; combine both for robust solutions.
  • Tooling: @google/genai + @modelcontextprotocol/sdk examples (Node/TS) and Go SDKs are available.
  • Sources: Google docs, sample repos, community writeups.

Amp (ampcode.com)

  • Amp (ampcode.com) is a frontier coding agent for terminal and editor workflows and it provides explicit MCP integration points in its configuration. Amp lets developers add and manage MCP servers (local or remote) via the amp.mcpServers configuration and a small CLI for lifecycle and OAuth management.

  • Key capabilities and configuration patterns observed for Amp:

    • Declaration: MCP servers are configured through the amp.mcpServers setting, allowing developers to replace or augment built-in skill-provided MCP servers with custom servers.
    • CLI management: Amp exposes commands to add and manage MCP servers, e.g. amp mcp add <name> <url> to register a server and amp mcp oauth login <name> ... to run an OAuth flow against a remote MCP server.
    • Authentication options: Amp supports multiple auth modes for MCP servers:
      • HTTP headers (token/bearer) configured directly in the server entry
      • Environment-variable interpolation for secrets (keeps credentials out of repo files)
      • OAuth 2.0 flows for remote servers; example callback URL used by Amp is http://localhost:8976/oauth/callback when running local OAuth redirects
    • Tool selection: Amp provides options (e.g., amp.tools.disable) to selectively disable unnecessary tools exposed by MCP servers to reduce model noise and improve performance.
    • Local vs remote: Amp supports local STDIO MCP servers for development/security-sensitive workflows and remote HTTP+SSE servers for shared/production deployments.
  • Practical examples (CLI snippets):

# Register a remote MCP server  
amp mcp add my-server https://example.com/.api/mcp/v1  
  
# Start OAuth login for that server (server must have an OAuth client configured)  
amp mcp oauth login my-server \  
  --server-url https://example.com/.api/mcp/v1 \  
  --client-id YOUR_CLIENT_ID \  
  --client-secret YOUR_CLIENT_SECRET \  
  --scopes "openid,profile,email,user:all"  
  • How this maps to MCP concepts: Amp’s amp.mcpServers acts as the client’s registry of available MCP servers (tools/resources/prompts). Authentication, headers, and env-var support map directly to MCP transport/auth requirements. Selective tool disabling implements a common best-practice to constrain the agent’s available action surface.

  • Sources and notes: ampcode.com’s docs and CLI help show the amp.mcpServers configuration and amp mcp subcommands; examples reference header-based auth, env-var interpolation, and OAuth flows. For authoritative details and latest CLI flags, see: https://ampcode.com.

Codex CLI

  • Codex CLI includes first-class MCP support. Key features:
    • codex mcp add to launch and register STDIO servers (eg. “Context7”), and codex mcp list, codex mcp get to inspect servers.
    • ~/.codex/config.toml supports both STDIO and HTTP servers, env var injection, bearer token configuration, enabled_tools/disabled_tools, startup/tool timeouts and toggles.
    • Acts as both an MCP client (consuming external servers) and can be run as an MCP server itself (exposes codex and codex-reply tools for other agents).
  • Practical benefits: declarative config, CLI-driven lifecycle (start/stop/add/list), and good automation fit for CI/CD workflows.
  • Sources: Codex CLI docs and example configurations.

Practical usage examples (focus on usage, not install)

  • Real-time CRM lookup (Claude / Goose): an agent sees a support ticket, requests permission to query the CRM MCP server, retrieves last 3 interactions (resource), and synthesizes a suggested reply.

  • Local developer tooling (Goose / Codex CLI): add a local STDIO MCP server that exposes lint, run-tests, and create-branch tools. Ask your agent “Create a feature branch and run tests” and the agent can call the tools in order, report progress via notifications, and return a summary.

  • Secure sampling (Anthropic MCP sampling): a code-review MCP server asks the host’s LLM to summarize a PR using the client’s preferred model/settings — server performs diffs and prompts the client’s LLM for a completion, avoiding server-held API keys.

  • Gemini long-context + MCP: feed a large product spec into Gemini’s context and call a product-database MCP server for current inventory numbers — combine in-model reasoning with precise, up-to-date values.

Security considerations & best practices

  • Use provider and tool allowlists to prevent accidental data exfiltration to unapproved LLM providers.
  • Classify tools as readOnly/destructive; require explicit user approval for destructive actions.
  • Prefer local STDIO MCP servers for highly sensitive data where network transport is unnecessary.
  • Use OAuth flows (where applicable) and server-side tokens; avoid storing third-party API keys in MCP servers unless necessary and audited.
  • Sign or validate MCP server binaries where possible (supply-chain integrity) and install MCP servers from trusted sources.
  • Ensure audit logging and human-in-the-loop checkpoints for high-risk operations (deploys, infra changes, PII access).

Implementation notes for engineers

  • Start with a small MCP server exposing 2–3 tools (e.g., search_docs, get_user, submit_job).
  • Define precise input schemas (JSON Schema) for each tool to make behavior deterministic.
  • Implement timeouts and retries on server and client sides.
  • Use STDIO during development for simplicity; switch to HTTP+SSE for multi-client or remote deployments.
  • For multi-agent orchestration, use a tool registry / gateway (eg. HyperTool MCP) to curate and limit the toolset visible to a given agent/persona.

References & further reading

Notes

  • I ran automated searches but some live fetches timed out; the links above are the authoritative anchors I could verify from the available documentation and project resources. If you want, I’ll re-run focused live lookups for any of the above (e.g., Anthropic spec repo, modelcontextprotocol SDK GitHub, concrete Gemini MCP sample repos, and Codex CLI docs) and insert inline citations/anchors directly into the note.

Published: OK, share: true