Wiring the MCPs: What an FDE Must Uncover About MCP During Customer Discovery

The skill is useless if the AI can't reach the data.

A brilliant skill that formats a customer health report is worthless if the health data is locked inside a CRM the AI has never seen. This is the second rung of the ladder, and it's where a lot of promising AI projects quietly die - not because the AI can't do the work, but because it can't access the world where the work lives.

That access layer is MCP - the Model Context Protocol - the open standard that lets AI plug directly into the tools and data sources a customer already uses. And discovering MCP requirements is a fundamentally different kind of detective work than discovering Skills. Skills discovery is about human behavior. MCP discovery is about systems, data, and access. This post is what you should care about when you make that shift.

First, Reframe What You're Looking For

When you were discovering Skills, you watched people. Now you're mapping infrastructure. Your questions move from "what do you do?" to "where does that live, who controls it, and can we get in?"

An MCP connection has three ingredients: a system that holds the data or does the action, access to that system, and trust that the AI should be allowed to read or write there. Every question you ask in this phase should be pulling on one of those three threads.

What You Should Care About in Discovery

1. Build a Complete System Inventory

You can't wire together tools you don't know exist. Before anything else, care about mapping the customer's actual stack - not the official one, but the real one.

• "For the workflows we identified, which systems does the data touch?"
• "What tools do people have open on their screen during a normal day?"
• "Are there spreadsheets, shared drives, or shadow tools that aren't officially sanctioned?"

That last question matters more than it looks. The official architecture diagram rarely matches reality. The real workflow often runs through a Google Sheet someone maintains by hand or a Slack channel where decisions actually get made. MCP has to connect to where the work is, not where the org chart says it should be.

2. Assess Data Quality Before You Celebrate Access

Here's the trap: a customer says "yes, it's all in Salesforce" and you get excited. But MCP will faithfully pull whatever is in there - including stale records, blank fields, and inconsistent tagging. AI reading garbage produces confident, well-formatted garbage.

Care about hygiene, hard:

• "How clean and current is the data in this system, honestly?"
• "If I pulled a record at random, how likely is it to be accurate and complete?"
• "Are fields used consistently, or does every rep fill them in their own way?"

MCP discovery is where a customer's operational debt becomes visible. When you find messy data feeding a high-value skill, you've just discovered that data cleanup is a prerequisite workstream - not a nice-to-have. Naming that early protects the whole engagement.

3. Map Access, Permissions, and Identity

A system existing isn't the same as the AI being able to use it. During discovery, care about the authentication and permission reality of every system you want to connect.

• "Who has access to this system today, and at what permission level?"
• "How does authentication work - SSO, API keys, service accounts?"
• "Should the AI act as itself, or on behalf of a specific user with that user's permissions?"

That last distinction is subtle and important. If the AI acts with broad service-account access, it can see everything - which may violate the principle that a user should only get AI answers based on data they're personally allowed to see. Surfacing this early shapes the entire integration design.

4. Separate Read from Write - Carefully

MCP can let AI read data or take action - and those carry wildly different risk profiles. Reading a ticket is low-stakes. Closing a ticket, sending an email, or updating a customer record is not.

During discovery, care about the boundary:

• "For each system, do we just need to read from it, or write back to it too?"
• "What's the blast radius if the AI writes something wrong here?"
• "Which actions absolutely require a human to approve before they execute?"

Most early engagements should lean heavily toward read-only connections plus human-approved writes. Knowing where the customer will and won't tolerate autonomous action tells you exactly how to scope the MCP layer.

5. Uncover the Security and Compliance Constraints

Nothing kills momentum like discovering, in week six, that the customer's security team was never consulted. Get ahead of it. During discovery, care about the guardrails the organization operates under.

• "What data here is sensitive, regulated, or customer-confidential?"
• "Does your security or compliance team need to review AI access to these systems?"
• "Are there data residency, retention, or audit requirements we must respect?"

You want the security stakeholders in the room early, not as a last-minute veto. An FDE who proactively raises compliance builds enormous trust - and avoids the classic trap of building something the organization can never actually turn on.

6. Check Connector Availability and Effort

MCP is an open standard, and major platforms - the CRMs, ticketing tools, project trackers, and collaboration apps - increasingly ship MCP connectors or accessible APIs. But not everything does. During discovery, care about the practical integration path for each system.

• "Does this tool have an existing MCP connector or a documented API?"
• "Is it a modern SaaS platform, or a legacy system with no clean way in?"
• "If there's no connector, how important is this system - worth building one, or can we route around it?"

This is where you separate the systems that are a quick win from the ones that require real engineering. That distinction directly shapes your sequencing and your timeline.

7. Understand Freshness and the "Source of Truth" Problem

Some skills need real-time data; others are fine with a nightly snapshot. And in many organizations, the same fact lives in multiple systems that quietly disagree with each other. Both issues surface at the MCP layer.

• "How current does this data need to be for the skill to be useful?"
• "If two systems disagree, which one is the source of truth?"
• "Who decides that, and is it documented anywhere?"

Answering this prevents a maddening class of production bugs where the AI is technically correct but pulls from the wrong system. If the customer can't tell you the source of truth, you've uncovered a governance gap worth flagging.

8. Identify the System Owners

Just as every Skill needs a validating owner, every MCP connection needs a system owner - the person or team who controls access, understands the data model, and can grant the permissions you need. During discovery, find them.

• "Who administers this system? Who do I talk to about access?"
• "Is there someone who deeply understands how this data is structured?"
• "Who has to approve connecting an AI to it?"

These people are your unlock. An MCP integration stalls fast without a cooperative system owner, and identifying them during discovery turns a future bottleneck into an early partnership.

The Discovery Mindset for the MCP Layer

If Skills discovery made you an anthropologist of work, MCP discovery makes you a cartographer of systems - and a diplomat. You're mapping the terrain, but you're also building relationships with the IT admins, security leads, and system owners whose cooperation you'll need.

Three habits serve you well here:

Trace the data, not just the task. For every skill you identified in Part 1, physically follow the data from where it originates to where it ends up. Every system it passes through is a potential MCP connection - and a potential point of failure.

Treat security as a partner, not an obstacle. The FDEs who bring compliance in early move faster overall, because they never have to unwind work that was never going to be approved. Raise the hard questions yourself before someone else does.

Distinguish "connected" from "trustworthy." Getting the AI plugged into a system is the easy half. Ensuring the data it reads is clean, current, and permission-appropriate is the half that determines whether anyone trusts the output.

Final Thoughts

You've now found the Skills worth building and mapped the MCP connections that feed them. The AI knows how to do the work, and it can reach the data to do it. But so far, a human still has to invoke each skill, one at a time.

The final rung is where it all comes together - where AI plans, chains skills across connected systems, and executes multi-step work on its own. That's the domain of Agents, and it's what the last post in this series is all about.