# MCP is a product, not a sidecar. I design and ship MCP servers that let AI agents act on real platforms safely. --- ## What I've built A non-custodial crypto payment platform. I designed and shipped its MCP surface end to end — these are the verified facts, not a pitch. (Name withheld here; happy to share it in a conversation.) - **Production authenticated MCP server** — 33 agent-callable tools, covering the full payment lifecycle: payment requests and orders, conversion quotes, balances, deposit addresses, plus webhooks, payee identity, and reseller sub-account and credit management. Built on the same platform as its REST/OpenAPI API. - **Access split by trust level** — Merchant tools, reseller tools, and a separate public payer server (5 tools) so an agent can complete a payment without ever holding merchant credentials. Separate dev and production environments. - **WebMCP tools on the public site** — Verified via WebMCP's public tool directory: a read-only fee-schedule tool, and a contact tool that only drafts — a human reviews and sends. - **Agent discovery** — An llms.txt with agent-specific variants, plus MCP manifests and server cards on /.well-known paths, audited with Google Lighthouse. --- ## Principles ### Design the tool surface like an API product Tool names, scopes, and descriptions determine whether an agent picks the right tool and calls it correctly. A coverage gap or a vague description is a product bug, not a documentation nit. **How I applied it:** Its 33 tools were built on the same platform as its REST/OpenAPI API — same naming discipline, same source of truth, so the tool surface didn't drift from the API it's standing on. ### Least privilege by default Read-only defaults, scoped permissions, and access levels matched to the caller — not one flat permission set — limit the blast radius of a bad or manipulated tool call before it happens. **How I applied it:** The platform splits by trust level: merchant tools, reseller tools, and a separate 5-tool public payer server, so an agent completing a payment never needs to hold merchant credentials. ### Identity is the foundation MCP's authorization model is OAuth-based (the server is an OAuth resource server, the client an OAuth client). The bigger decision is architectural: reuse the identity and business logic your APIs already trust, instead of standing up a parallel stack for agents. **How I applied it:** Its MCP server is built on the same platform as its REST API — same identity, same business logic, not a bolted-on second system. ### Humans stay in control of consequential actions Separate "answer" tools from "transact" tools. An agent should be able to draft a consequential action, but a person approves it — with a traceable, reversible trail behind that approval. **How I applied it:** Its WebMCP contact tool only drafts a message; the human reviews and sends it. Nothing consequential fires without that step. ### Agent-specific threats are real Prompt injection, tool poisoning, and over-permissioned tools aren't hypothetical — a tool description and anything a tool returns are both attack surface an attacker can shape, not just documentation for the model. **What I'd do:** Threat-model the tool surface the same way you'd threat-model an API — assume a hostile prompt reaches every tool description and every returned payload, and design scopes so a single compromised call can't cascade. ### Govern the server lifecycle An MCP server needs the same lifecycle discipline as any other production API: a versioning and breaking-change policy, a real dev-to-prod path, and a clear owner between the platform team and the domain team that owns the underlying data. **How I applied it:** It runs separate dev and production MCP environments — the server graduates the same way the rest of the platform does, not as a side project. ### Make it discoverable An agent can't use a tool it can't find. llms.txt, /.well-known manifests and server cards, and OpenAPI as the single source for docs, SDKs, and MCP tools all exist to answer the same question: how does an agent find out what's here without a human pointing it there first. **How I applied it:** It publishes an llms.txt with agent-specific variants plus MCP manifests and server cards on /.well-known paths — audited with Lighthouse like any other production surface. ### Measure it Track tool invocation success rate, task completion, latency, cost per task, time to first successful call, and coverage across products — and run evals that check whether an agent chose the right tool, as a regression suite, not a vibe check. **What I'd do:** Wire tool-selection accuracy and task completion into the same dashboards and alerting the rest of the platform already has, rather than treating agent traffic as a separate, unmeasured channel. --- ## Is your MCP server production-ready? - [ ] Every write tool has a read-only alternative, or requires explicit confirmation before it executes. - [ ] Tool descriptions state exactly what the tool does, what scope it needs, and any side effects — not just a name. - [ ] Access is split by trust level (public / single account / reseller or portfolio), not one flat permission set. - [ ] The MCP server reuses your existing identity and authorization system, not a parallel one-off stack. - [ ] Consequential actions (payments, sends, deletes) are drafted by the agent and confirmed by a human, not auto-executed. - [ ] Every tool call and its outcome is logged and traceable back to a caller and a human decision. - [ ] Tool descriptions and anything returned to the model are treated as untrusted input, not just documentation. - [ ] The MCP server has its own versioning and breaking-change policy, separate from your public API. - [ ] There is a real dev-to-production path for the server, not one shared production instance everyone edits live. - [ ] Someone specific owns the MCP server's quality bar — it isn't everyone's job and no one's job. - [ ] The server is discoverable by agents (llms.txt, /.well-known manifests, or equivalent) without a human pointing them to it. - [ ] You track tool-selection accuracy and task completion, not just uptime. --- ## Talk MCP strategy Building an MCP server, or deciding whether to? I help teams design the tool surface, the access model, and the governance around it before it ships — not after. Contact: https://technical.pm/mcp (see page for consultation and contact forms) _Technical references on this page verified against the MCP spec, revision [2026-07-28](https://modelcontextprotocol.io/specification/2026-07-28)._