MCP development

What this gets you, in plain terms

Your customers are already using AI assistants. Right now, when they want to do something in your product, they leave the assistant, open your app, and do it by hand. MCP closes that gap: it lets the assistant talk to your product directly, so the customer can ask a question or make a change without switching context.

The business case isn’t "we added AI." It’s narrower and more useful than that. You already have the data and the logic. MCP is the adapter that makes both reachable from where your customer is already working, under your authentication, your permissions and your audit trail.

Four ways I implement it

Almost every MCP project I’ve worked on is one of these four shapes. Which one you need depends on what you want the assistant to be able to do, and how much it would cost you if it got that wrong.

1. Read-only connector

The assistant can look at your data but can’t change anything. This is the right starting point for most products, and it’s genuinely useful on its own, reporting, lookups, summaries, "what happened last month". It’s also the safest thing to ship first, because the worst outcome is that the assistant reads something it shouldn’t, which scoping handles.

2. Action server

The assistant can change things, create a record, update a booking, send something. This is where the design work starts. Every tool that writes needs to be narrow enough that a confused assistant can’t do real damage with it, and the failure responses have to be unambiguous, because the model reads them and decides what to do next. A vague error is worse than a clear refusal.

3. Multi-tenant server with per-user consent

The version most SaaS products actually need. Each of your users connects their own account, sees exactly what they’re granting, and can revoke it later without involving you. That means real OAuth, scoped grants rather than all-or-nothing access, and a connections screen inside your product where a user can see what is connected and disconnect it. This is the bulk of the engineering, and it’s the part that determines whether your security review passes.

4. Internal operations server

Not customer-facing at all, an MCP surface over your own systems so your team can ask questions and run routine tasks through an assistant instead of a runbook. Lower stakes, quick to build, and usually the fastest way to find out whether MCP is worth doing for your customers.

Where it goes wrong

• Tools that are too broad. One flexible "query" tool feels efficient and is a liability. Narrow tools with explicit arguments are easier for a model to use correctly and easier for you to reason about.
• All-or-nothing permissions. If connecting means handing over the whole account, sophisticated customers will decline, and they will be right to.
• Revocation as an afterthought. If a user can’t disconnect without emailing support, you don’t have consent, you’ve a subscription.
• Errors written for humans. The consumer here’s a model. If a failure doesn’t come back in the shape the protocol expects, the assistant will often retry it or invent a reason, and your logs won’t tell you which.
• Never testing with a real client. A server that satisfies your own test script and has never been driven by an actual assistant isn’t finished.

Products I’ve shipped this in

These are live, and the MCP work in them is mine. I’ve kept the descriptions at the level of what they do rather than how they’re defended, for obvious reasons.

Why now

MCP is early. Almost nobody is searching for it yet, and most products that will eventually need it haven’t started. That’s exactly why it’s worth doing now: the integration work takes weeks, the design decisions are hard to reverse once customers have connected, and the products that get it right early will be the ones assistants reach for by default.