Anatomy of an MCP Integration

What your engineering team is actually building (explained without code).

The Scenario

You have decided to build an MCP integration. Your tech lead sends you a technical design doc full of "servers," "tools," "resources," and "prompts." You need to translate this into user stories, acceptance criteria, and a roadmap your stakeholders understand.

This module is the translation layer. It explains the architecture in product language, not engineering language. By the end, you will be able to brief your CEO, write scoping documents, and make prioritisation decisions about what to build first.

The Three MCP Primitives

An MCP integration is built from three building blocks: Tools, Resources, and Prompts. Everything your team builds will fall into one of these three categories.

Examples in Product Language

If Your Product is a Project Management Tool

Tools (what Claude can do):

• Create a new task with title, description, and assignee
• Update a task status (to-do, in progress, done)
• Add a comment to a task
• Create a new project
• Assign a team member to a project

Resources (what Claude can read):

• List of all projects in the workspace
• List of all tasks for a given project, with metadata (status, assignee, due date, priority)
• Team member list with roles and permissions
• Project timeline and critical path
• Budget tracking and resource allocation

Prompts (guided workflows):

• "Help me plan a new project" (gather requirements, create structure, assign owners)
• "Show me my team's workload this week" (read projects, read tasks, summarise capacity)
• "Move overdue tasks to tomorrow" (read overdue tasks, update dates, notify assignees)

If Your Product is a CRM

Tools: Create contact, update deal status, log a call, send an email, add a note to an opportunity.

Resources: List of contacts, list of deals with amounts and stages, sales pipeline, customer interaction history, revenue forecast.

Prompts: "Who are my highest-value at-risk deals?", "Generate a list of warm outreach targets," "Summarise my sales this quarter."

Deciding What to Build First: The Surface Area Mapper

You cannot expose everything at once. And you should not. Starting small with your highest-value surface area is the fastest path to a working MCP integration.

Step 1: List Your Top 10 User Actions

Ask your analytics team: what are the top 10 most-performed actions in your product? These are the actions your users do most frequently. These are the actions an AI assistant should be able to help with.

For a project management tool, this might be: create task, update task, view project, add comment, mark complete, assign task, change priority, add due date, view dashboard, search tasks.

Step 2: Score Each Action

For each top action, score it on three dimensions. This gives you a weighted priority.

Scoring logic: Multiply automation potential (how useful to an agent) by frequency (how often users do it) by inverse complexity (how easy to build). This surfaces the actions that are high-value to agents, heavily used, and fast to implement. Those are your Phase 1 features.

High-value MCP integrations start with 2-3 Tools and 2-3 Resources that cover the most frequent, most automatable user actions. Do not try to expose your entire API on day one.

Common Mistakes to Avoid

Mistake 1: Exposing Too Much

The temptation is to expose your entire API surface as MCP Tools. This creates security risks, maintenance burden, and confusion. An AI assistant with 50 available tools is less useful than an AI with 5 clearly focused tools.

Solution: Start with 5-7 Tools. Expand later based on usage data.

Mistake 2: Exposing Too Little

The flip side: if your MCP integration is so limited that it does not actually help users, it becomes a feature demo instead of a platform feature. An AI that can only read data but not act is less valuable than an AI that can do both.

Solution: Include both Tools (write) and Resources (read). A mix of 60 percent actions, 40 percent data is a good starting point.

Mistake 3: Engineering-Driven Instead of User-Driven Exposure

Some teams expose what is easiest to build in the code, not what is most valuable to users. This results in a confusing MCP surface that does not match user workflows.

Solution: Prioritise based on user frequency and automation potential, not code simplicity. The Surface Area Mapper forces you to think about user value first.

Mistake 4: No Documentation or Discovery

An undocumented MCP server is invisible. AI assistants discover Tools through your server's documentation and schema. If you do not invest in clear descriptions, example workflows, and error handling, the integration will feel broken to users.

Solution: Treat Tool descriptions as product documentation, not code comments. Write them for a user, not an engineer.

The MCP Surface Area: Your Product's AI Footprint

Think of your MCP Surface Area as the set of capabilities your product exposes to the AI layer. It is distinct from your core product. Not every feature needs to be an MCP Tool.

Your product might have 100 features. Your MCP Surface Area might have 7 Tools and 5 Resources. That is fine. You are optimising for the most valuable subset that agents can actually use.

Over time, your MCP Surface Area will expand based on usage data. But start narrow and focused. This is the difference between a successful MCP integration and one that gets buried in your roadmap.

Building a Roadmap

Phase 1 (Weeks 1-2): MVP MCP server with 2-3 core Tools and 2-3 core Resources. Something that works but is deliberately scoped small.

Phase 2 (Weeks 3-4): Add 2-3 more Tools. Polish error handling and edge cases. Start collecting usage data.

Phase 3 (Month 2): Add Prompts (guided workflows). Start building based on what users are actually doing with your Tools and Resources.

Phase 4 (Month 3+): Advanced features, authentication refinement, and scaling. Only after you understand usage.