ag-kit: Skill for Claude Code

MCP Builder

Build interoperable MCP implementations against the stable 2026-07-28 specification. Treat extensions as negotiated, opt-in capabilities rather than core protocol guarantees.

---

1. Stable baseline and compatibility

• The authoritative stable baseline is MCP 2026-07-28.
• Core requests are stateless and self-contained. Do not infer protocol version, client capabilities, identity, conversation, or task state from a transport connection or process lifetime.
• Put cross-request state behind explicit identifiers supplied on every relevant request.
• Negotiate the protocol version and capabilities; do not assume that a client or server implements every optional feature.
• Preserve compatibility with earlier peers where the specification requires it, including accepting legacy resource-not-found error code -32002 while emitting -32602 for invalid parameters in the current protocol.

Core versus extensions

Layer	Status	Engineering rule
Base protocol, versioning, message patterns	Stable core	Required for every implementation
Resources, prompts, tools, elicitation	Optional core features	Advertise and check capabilities before use
Tasks, Skills over MCP, MCP Apps	Extensions	Opt-in; require explicit support from both peers
Draft or vendor extensions	Experimental/vendor-specific	Isolate behind adapters and feature flags

Never label an extension as stable merely because one SDK or host supports it. Check the extension's own official status and version.

---

2. Architecture

MCP uses JSON-RPC 2.0 between hosts, clients, and servers.

host application
  └─ MCP client / runtime adapter
       ├─ stdio transport
       └─ Streamable HTTP transport
            └─ MCP server
                 ├─ resources
                 ├─ prompts
                 └─ tools

Stateless request model

Every request must carry the protocol metadata required by the negotiated version. For 2026-07-28 this includes per-request protocol version and client capability metadata under reserved _meta keys.