MCP Course Home → Module 6 of 7

MCP is approved. You have the budget. You have the engineering commitment. Now you need to fit it into a roadmap that is already full. Your team has Q3 commitments. There is a major feature launch next month. Two engineers are on holiday in August. Where does MCP go without blowing up the plan?

The single biggest mistake teams make with MCP is trying to build the full surface area in one release. Do not do this. MCP is a feature, and like every feature, it benefits from phased delivery.

Phase 1: Read-Only Foundation (Week 1 to 2)

Start with 2 to 3 read-only resources. These expose data from your product that AI assistants can retrieve. No write actions. No side effects. No risk.

This is the lowest-stakes MCP work possible. It proves the infrastructure works, establishes the deployment pipeline, and gives you something to demo internally. If anything goes wrong, the worst case is that an AI assistant reads some data it was authorised to read.

Examples: "Get user profile," "List recent projects," "Fetch report data."

Phase 2: Action Tools (Week 3 to 4)

Add 2 to 3 tools that allow AI assistants to take actions. These are the write operations: creating records, triggering workflows, updating fields. They require more careful permission handling and validation.

Start with actions that are low-risk and high-frequency. "Create a new task" is better than "Delete all tasks." "Send a notification" is better than "Modify billing settings."

Phase 3: Packaged Workflows (Month 2)

Add prompts that bundle your tools and resources into named workflows. These make your MCP integration more powerful and easier for AI assistants to use effectively.

"Generate weekly summary" might combine reading project data, reading team metrics, and formatting a report. The user asks for one thing, and MCP handles the orchestration.

Phase 4: Advanced Features (Month 3 onward)

Multi-step workflows. Real-time subscriptions (AI assistants get notified when data changes). Analytics on MCP usage. Advanced authentication scopes. MCP marketplace listings.

This is the long tail. You only need to get here if MCP is working and usage is growing.

The best way to fit MCP into a full roadmap is to attach it to work you are already doing.

Already building a new API endpoint? Add MCP tool exposure as part of the same work. The incremental effort breaks down roughly as follows: 5 percent for tool definition (writing the schema, description, and parameter specs), 10 percent for testing (verifying that the MCP tool returns the right data in the right format, edge cases, permission checks), and 5 percent for documentation (updating your MCP server's tool list and descriptions so AI assistants understand what the tool does). That is roughly 20 percent on top of the API work, and it drops to 10 percent for your third and fourth tool as patterns are established.

One caveat: this 20 percent estimate holds when you already have a clean, well-documented API. If your API layer is messy, undocumented, or requires significant refactoring, the MCP work will expose that debt. In that case, budget for API cleanup as a separate task. Do not let MCP become the reason you finally fix your API, because the timeline will balloon.

Already improving onboarding? Add an MCP prompt that guides new users through setup via their AI assistant. "Set up my account in [your product]" becomes a supported workflow. Same onboarding logic, new distribution surface.

Already building analytics dashboards? Expose the underlying data as MCP resources. Now AI assistants can answer questions like "What were my top metrics last week?" using your product's data, without the user needing to open your product at all.

The key mental model: MCP is a distribution layer on top of features you are already building. It should accelerate your roadmap, not compete with it.

Here is what an MCP integration looks like in practice, using Slack as the example.

What Slack exposes through MCP:

Resources (read-only data): channel list and metadata, message history (with permissions), user profiles and status, thread contents.

Tools (actions): send message to channel, reply to thread, search messages, set channel topic, post formatted blocks.

Prompts (packaged workflows): "Summarise this channel's last 24 hours," "Draft a reply to this thread," "Find all messages mentioning [topic]."

What this enables for Slack users:

A user opens Claude and says: "Summarise what happened in #engineering today and draft a standup update for me."

Claude uses the MCP integration to: (1) Read the #engineering channel history (Resource: message_history). (2) Filter for today's messages (Tool: search_messages). (3) Analyse the content and generate a summary (Claude's own capability). (4) Draft a standup update (Claude's own capability). (5) Optionally post it to #standups (Tool: send_message, with user confirmation).

The user never left Claude. Slack's data and actions were available through MCP. Claude orchestrated the workflow.

What this means for your product: Replace "Slack" with your product name. Replace "channels" and "messages" with your product's data and actions. The pattern is the same: expose resources and tools through MCP, and AI assistants orchestrate workflows your users would otherwise do manually.

Once your MCP server is live, track these four numbers:

1. MCP Connection Count. How many unique AI clients are connected to your MCP server? This is your reach metric. It tells you how many AI assistants can use your product.

2. Tool Invocation Volume. Which MCP tools are being called, and how often? This is your engagement metric. It tells you which parts of your surface area are actually valuable to AI users.

3. User Activation via MCP. How many new users discovered your product through an MCP-connected AI assistant? This is your acquisition metric. It tells you whether MCP is a meaningful distribution channel.

4. Support Ticket Deflection. How many user queries are being handled by AI assistants through MCP instead of by your support team? This is your efficiency metric. If AI assistants can answer "What is my subscription status?" via MCP, that is one fewer support ticket.

MCP usage data is product intelligence. If users are calling your "get_project_status" resource 10 times more often than your "get_team_members" resource, that tells you something about what your users value. If a tool you expected to be popular is barely used, that is a signal too.

Build a monthly review into your process: look at MCP usage data alongside your regular product analytics. The patterns will often be different, because AI-mediated usage reveals different priorities than direct UI usage.

Take your existing product roadmap. Add a parallel MCP track underneath it. For each major feature in your roadmap, ask: "Can we add MCP exposure to this feature with 20 percent incremental effort?" If yes, tag it.

The overlay should show:

This is not a separate roadmap. It is an enhancement to your existing one. That framing matters when you present it to leadership.

Create a visual roadmap (your preferred tool: spreadsheet, slide, or roadmap software) with:

The goal: make it visually obvious that MCP is mostly incremental, not additive.

← Module 5: Selling MCP Internally | Course Home | Next Module: The MCP Ecosystem Playbook →