MCP (Model Context Protocol)

1. What is it?

The Model Context Protocol (MCP) is an open standard for connecting AI applications to external tools and data. Instead of every application hand-rolling its own function-calling wiring, MCP defines a common interface: servers expose tools (and resources/prompts) with typed schemas; any MCP-compatible client can discover and call them.

The useful framing: MCP is to AI tools what ODBC/JDBC was to databases — a boring protocol layer that quietly changes what is economical to build.

2. Why does it exist?

Before standards like MCP, every AI application re-solved the same integration problem:

• N applications × M systems = N×M bespoke integrations, each with its own auth, errors, and schema drift.
• Tool logic was trapped inside one app’s codebase — unusable by the next agent project.
• There was no clean boundary between “the AI part” and “the enterprise systems part.”

MCP collapses that to N+M: each system exposes itself once as a server; each application speaks the protocol once. Tools outlive frameworks — that is the whole point.

3. How does it work?

• An MCP server (I use FastMCP in Python) registers capabilities: functions with typed parameters, descriptions, and return schemas.
• A client (an agent application) discovers those tools and invokes them through the protocol; transport is typically stdio (local) or HTTP-based (remote, e.g., Streamable HTTP).
• The model never “calls” anything directly — the orchestration layer presents tool schemas to the model, receives a structured call request, executes it against the server, and returns the result as context.

4. Important concepts

5. Production considerations

• Treat servers as products — versioned, deployed, monitored, owned. Not scripts.
• Schema evolution — tools change; plan for backward compatibility or explicit versioned surfaces, because you will not control every consumer.
• Latency — every tool call is a network round trip in the critical path of a model loop. Batch where sensible; cache where safe.
• Security — a tool server is a privileged service: scoped credentials, input validation, rate limits, full audit logging of every invocation.
• Observability — log which consumers called which tools with what parameters and how long it took. This is the data that tunes your retrieval strategy over time.
• Onboarding cost — the real payoff of MCP: a new agent project integrates enterprise context in days, because the surface already exists.

6. How I approach it

I architected an MCP-based semantic retrieval platform (SIRIUS MCP) that exposes enterprise configurations as tools: a FastMCP server in front of Aurora PostgreSQL/pgvector, fed by an ETL pipeline that vectorizes enterprise configurations, with a three-tier retrieval strategy (site-specific → global standards → historical examples).

Design rules I hold to:

1. The server is the API team’s territory. Typed schemas, versioning, changelogs — the same discipline as any internal platform API.
2. Access control inside the tool layer. Agents are untrusted clients by definition.
3. Precedence encoded structurally. Tiered retrieval answers “which source wins” deterministically — auditors can read it, developers can reason about it.
4. The tool surface stays small. A handful of well-designed tools beat twenty overlapping ones; models navigate small surfaces far more reliably.
5. Reuse beats elegance. The same MCP layer now serves the recipe-authoring agent and other AI platforms — that reuse is the return on the standardization investment.

7. Architecture

AI agents (any framework)
      │  MCP protocol
      ▼
FastMCP server  ── typed tools, auth, audit log
      │
      ▼
Retrieval engine ── tiered strategy (site → global → history)
      │
      ▼
Aurora PostgreSQL + pgvector  ←── ETL vectorization pipeline ←── enterprise configs

8. Common mistakes

• Exposing raw database queries as tools instead of meaningful operations.
• Auth in the client (“the agent promises it’s allowed”) — no.
• One mega-tool that returns everything, leaving context construction to the model.
• No versioning, then breaking every consumer in one schema change.
• Forgetting that tool descriptions are prompts — vague descriptions produce vague calls.

9. Interview perspective

• “Why MCP over direct function calling?” — reuse and decoupling: one governed surface serves every consumer; integrations survive framework churn.
• “How do you design a good tool?” — like an API: single purpose, typed, documented, validated, observable. If you cannot describe it in one sentence, it is two tools.
• “How do you secure it?” — per-tool authorization in the server, scoped credentials, audited invocations, input validation against schemas.

10. Related topics

• Agentic AI — who consumes MCP tools.

• RAG — the retrieval these tools typically wrap.

• Vector Databases — storage and search underneath (see AI index).

• Tools — model-invoked functions. Design them like APIs: small, composable, well-documented, schema-validated. A tool description is a prompt; write it like one.

• Resources — read-only context the client can pull. Good for documents and references.

• Prompts — reusable, parameterized prompt templates exposed by servers.

• Tool granularity — the classic API-design problem again: too fine and the model drowns in calls; too coarse and results are unmappable to decisions.

• Authorization — enforcement lives in the server, per tool, per tier — never in the client’s promises.