Model Context Protocol (MCP): How to Plug AI Agents into Your Product

What MCP Is, in Plain Words

The easiest way to picture MCP is a universal plug. Before USB-C, every device needed its own charger. Before MCP, every AI app needed its own custom connector for every product. With M AI apps and N products, that's M × N integrations to build and maintain. With a shared protocol, each side implements it once: M + N.

There are three roles:

A server can offer three kinds of things, and the key difference is who is in control:

How a Conversation Actually Flows

1. 1The host connects to your server and they agree on capabilities (a short handshake).
2. 2The host asks for the list of tools. Their names, descriptions and input schemas become part of the model's context.
3. 3A user asks something. The model decides a tool would help and produces a call with structured arguments.
4. 4The host sends that call to your server, ideally after asking the user to confirm anything risky.
5. 5Your server runs normal business logic and returns a result, which the model uses to write its answer.

Under the hood, these are plain JSON-RPC 2.0 messages, nothing exotic:

// What actually travels over the wire (JSON-RPC 2.0)
// Host → server
{ "jsonrpc": "2.0", "id": 2, "method": "tools/call",
  "params": { "name": "get_order_status", "arguments": { "orderId": "1042" } } }

// Server → host
{ "jsonrpc": "2.0", "id": 2,
  "result": { "content": [{ "type": "text", "text": "Order 1042: shipped, arriving Thursday" }] } }

Try It: The MCP Flow Explorer

Below is a pretend online-store MCP server with three tools. Pick a request and step through the messages. The last scenario hides an attack inside a product review. Run it with the approval setting on, then off, and you'll understand MCP's biggest risk better than any diagram could explain it.

Designing Tools AI Agents Use Well

An MCP server is an interface for a model rather than a developer. That changes what good design looks like:

• Design around tasks, not endpoints. Don't mirror every REST route. Expose the handful of things users actually ask an assistant to do. Five well-chosen tools beat fifty thin wrappers that confuse the model.
• Descriptions are prompts. The model chooses tools from their names and descriptions. Say what the tool does, when to use it, and what it won't do, in plain language.
• Keep inputs small and typed. Use clear parameter names, enums instead of free text where possible, and sensible limits. Validate everything on the server.
• Return concise, useful results. Models work best with focused output. Summarize, paginate large lists, and return helpful error messages the model can act on ("order not found for this account"), not stack traces.
• Start read-only. Ship search and lookup tools first. Add tools that change data later, one at a time, with confirmation built in.

A Minimal MCP Server

With the official TypeScript SDK, a working server is a few dozen lines. Notice that the tool calls your existing business logic and reuses its permission checks. The MCP layer only describes and translates:

// mcp/store-server.ts: a minimal MCP server (TypeScript SDK)
import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js"
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js"
import { z } from "zod"
import { orders } from "../core/orders" // your existing business logic

const server = new McpServer({ name: "acme-store", version: "1.0.0" })

server.registerTool(
  "get_order_status",
  {
    title: "Get order status",
    description: "Look up the shipping status of one of the signed-in customer's orders.",
    inputSchema: { orderId: z.string().describe("Order number, e.g. 1042") },
    annotations: { readOnlyHint: true },
  },
  async ({ orderId }) => {
    const order = await orders.findForCurrentUser(orderId) // same auth as your app
    return { content: [{ type: "text", text: `Order ${orderId}: ${order.status}` }] }
  },
)

await server.connect(new StdioServerTransport())

SDK APIs evolve, so check the current documentation before copying this into production. The shape stays the same: name, description, typed input, handler. Official SDKs exist for most mainstream languages, and the same architecture applies to all of them.

Local or Remote?

Security: The Part You Can't Skip

Connecting an AI agent to your product means a language model, which can be persuaded by text, now sits between users and your data. The demo's last scenario isn't far-fetched: prompt injection through tool results is the defining security problem of agentic AI. Five rules cover most of it:

1. 1Treat tool results as untrusted input.Anything your server returns (reviews, emails, documents) may contain instructions written by an attacker. The model can't reliably tell data from commands.
2. 2Act as the user, never as a superuser.Authenticate each user (OAuth for remote servers) and scope every tool to what that user may do. No shared admin tokens behind the scenes.
3. 3Confirm anything that changes data.Mark destructive tools and make sure the host asks the user first. Hints such as destructiveHint help, but enforce critical limits in your server too.
4. 4Limit, log and alert.Rate-limit per user, cap how much a single call can do, and keep an audit trail of every tool call with who asked for it.
5. 5Vet third-party servers.Installing someone else's MCP server is like installing a dependency with access to your data. Review it, pin versions, and grant the minimum permissions.

Where MCP Fits in Your Architecture

The healthiest pattern is to treat the MCP server as just another adapter over your core business logic, alongside your web app, mobile app and public API. It shouldn't contain business rules of its own. If that sounds familiar, it's the same core-plus-adapters idea from Framework-Agnostic Frontend Architecture, applied to AI agents instead of UI frameworks.

Larger organizations with many servers often add an MCP gateway in front of them: one place to handle authentication, rate limits, logging and policy, so each team's server can stay small and focused.

A Safe Rollout Plan

1. 1

   Internal, read-only

   Expose search and lookup tools to your own team. Watch which tools the model picks, and fix confusing names and descriptions.

2. 2

   Limited writes

   Add one or two data-changing tools with confirmation, behind a feature flag, for a small group of real users.

3. 3

   Public remote server

   Launch with OAuth, rate limits, audit logs and documentation telling users which assistants are supported.

4. 4

   Measure and iterate

   Track tool-call success rate, errors, latency and support tickets. Real failures become test cases.

When You Don't Need MCP

If all you want is one AI feature inside your own app, such as a smart search box or a writing assistant, you control both the model call and the functions it can use. Plain function calling is simpler, and MCP adds little. Reach for MCP when other AI applications need to use your product, when you want one integration to serve many assistants, or when internal teams are building agents that need shared, governed access to the same systems.