MCP / Agentic Platforms
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.
How the pieces fit together
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?
Check off what's true today. This stays in your browser — nothing is sent anywhere.
A handful of gaps is normal — most of these take a focused sprint, not a rebuild.
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.
Technical references on this page verified against the MCP spec, revision 2026-07-28.