Model Context Protocol (MCP)

Where MCP helps, where it does not, and why teams still need guardrails.

The way I think about MCP: it is a common contract between AI hosts and tools.

Without MCP, each host builds a custom integration per tool. With MCP, tools expose a shared interface and hosts integrate in a more standard way.

That matters because tool access is becoming part of the AI product surface. The more agents and assistants a team ships, the more painful one-off integrations become.

Mental shortcut

API as power socket. MCP as common plug format for AI tools.

Not perfect, but useful for intuition.

The shortcut also shows the limitation. A common plug does not make the appliance safe. MCP can standardize connection shape, but teams still need authorization, rate limits, audit logs, and careful tool design.

Basic pieces

The basic pieces are the host app, the MCP client in the host, and the MCP server exposed by the tool or data source.

Flow stays consistent: discover -> call -> return structured result.

Where MCP helps most

MCP is most useful when a team has many tools or many AI surfaces: an IDE assistant that needs code, tickets, and docs; a support copilot that needs CRM, knowledge base, and order data; an internal agent that needs read-only access to dashboards and runbooks; or a workflow assistant that needs several small tools instead of one giant API.

In these cases, the value is not just fewer lines of glue code. It is a more consistent way to describe capabilities, inputs, and outputs.

What MCP helps with

MCP helps with less connector duplication, faster tool onboarding, easier portability across hosts, and clearer capability boundaries.

Example rollout

If I were adding MCP to an engineering assistant, I would start with read-only tools: search docs, read repository metadata, fetch issue details, and summarize deployment status.

Only after those are stable would I add write tools like creating tickets, triggering workflows, or updating records. Read tools build trust. Write tools need stronger policy.

What MCP does not solve

MCP does not solve weak authorization design, unsafe tool behaviors, poor rate-limit or retry design, or bad auditability.

So I treat MCP as an interoperability layer, not a safety layer.

Checks before exposing a tool

Before making a tool available through MCP, I want clear answers to a few questions. What is the narrowest permission scope this tool needs? Can it be read-only first? What errors will be returned to the model? Does the response include enough structure for reliable downstream use? Which calls should be logged or require approval? What happens if the model calls this tool repeatedly?

These questions keep MCP from becoming a convenient way to expose too much power too quickly.

Rollout order I prefer

  1. Read-only tools first
  2. Scoped auth
  3. Audit logs
  4. Controlled writes

Practical rule

Every MCP server should have an owner, a permission model, and a failure story. If nobody knows who owns it, what it can access, or how it fails safely, the integration is not production-ready yet.

A useful boundary

I like treating MCP servers like small product surfaces, not internal plumbing. They need names, docs, examples, and predictable error messages. A model is much more likely to use a tool correctly when the tool describes itself clearly and returns structured responses instead of vague strings.

That means tool design is prompt design by another route. Better schemas reduce guesswork, and less guesswork usually means fewer strange agent behaviors.

Trend signals behind this note

Takeaway

MCP reduces integration tax. It does not replace security and policy design, and the safest rollout starts with boring read-only capabilities.

Related Mental Models

Friendly Copyright & Sharing Reminder by Tushar Mohan.

Hey there! I’m thrilled you stopped by and hope my posts spark ideas of your own.

Feel free to quote short excerpts for commentary, reviews, or academic purposes—but please don’t copy, republish, or remix substantial portions without first getting my written okay.

Need permission? It’s easy—just drop me a note on my email or connect with me on any of the social media platforms I have linked here, with a quick outline of what you’d like to use, and we’ll sort it out fast. Thanks for respecting the work that goes into each post, and for helping keep the internet a place where creators and readers both thrive.

Unless I’ve credited someone else, all articles, code snippets, images, and other goodies on this site are

© Tushar Mohan, 2026.