mcp-architectlisted

# MCP Architecture Vanilla MCP servers exposing **tools**, **resources**, and **prompts** to LLM clients over JSON-RPC 2.0. Spec target: **2026-07-28** (current stable, published final 2026-07-28; supersedes 2025-11-25 with a stateless protocol core — see [§12](#12-versioning--deprecation)). Server-focused; brief client section in [RECIPES §10](RECIPES.md#10-client-quick-reference). Pinned deps in [STACK.md](STACK.md). Pairs with: - [security-reviewer](../../quality/security-reviewer/SKILL.md) — MCP servers expand the agent's blast radius; treat every tool call as untrusted input. - [rest-api-architect](../rest-api-architect/SKILL.md) and [grpc-architect](../grpc-architect/SKILL.md) — many MCP servers wrap an existing API; reuse those error and pagination conventions. ## 1. When to pick MCP (and when not to) MCP exists to let an LLM client (Claude Desktop, Cursor, VS Code, ChatGPT, an agent) plug into your capabilities without per-client glue code. Reach for it when: - The same capability is consumed by multiple LLM clients and you don't want N integrations. - You need an LLM to call your tools, read your resources, or render your prompt templates inside a chat. - The agent needs to dynamically discover what your service can do — REST/gRPC contracts are static; MCP `tools/list` is dynamic per session. **Don't** use MCP when: - The caller is server-to-server backend code — use [gRPC](../grpc-architect/SKILL.md) or [REST](../rest-api-architect/SKILL.md). MCP is for LLM-m