core-mcp-server-authoringlisted

# MCP Server Authoring Every tool boundary exposed by an MCP server is an attack surface. The server receives JSON-RPC requests from an LLM harness that also controls tool selection — meaning a compromised or malformed tool call can trigger arbitrary server-side behavior if the server does not validate inputs rigorously. The ONLY trust boundary is the stdin/stdout channel: everything that enters the server through that channel is untrusted input until schema-validated. Everything that leaves through stderr is a diagnostic for the operator, not a JSON-RPC response, and must never carry secrets or user data that reaches the client. Build MCP servers as if the caller is adversarial by default. They probably are not, but the invariants that make the safe case safe also make the adversarial case safe. ## What This Skill Is (and isn't) This is authoring doctrine for building MCP server implementations — the rules, patterns, and examples a developer needs when writing a new server or adding a tool to an existing one. It pairs with `core/security-and-auth` (general boundary-defense patterns) and `core/observability-and-ops` (diagnostic / audit emission patterns). This skill is NOT the registry and configuration layer. Which servers are enabled, how they are registered, and how the framework discovers them at runtime is decided in ADR-042 (MCP server contract) and ADR-062 (RAG sidecar MCP opt-in). This skill governs how to build a server that satisfies those ADRs — not how to con