What MCP actually is
Model Context Protocol (MCP) is an open standard that defines how AI agents connect to the tools and data sources they need to do useful work. At a mechanical level, an MCP server exposes a set of capabilities — tools the agent can call, resources it can read, prompts it can reuse — through a stable protocol. The agent reasons about when to use those capabilities, and the MCP server handles the mechanics.
Before MCP, every agent framework had its own bespoke way of wiring up tool calls and resource access. Each CRM integration, each helpdesk connector, each internal API required framework-specific glue code. MCP collapses that into a single protocol, so the same tool implementation can be consumed by any MCP-aware client — Claude, Cursor, your own agent runtime, future models you haven't picked yet.
The practical effect is that AI agent work becomes portable and composable. A well-designed MCP server for your CRM is not throwaway work tied to one agent vendor; it's reusable infrastructure.
What a custom MCP is
A custom MCP is an MCP server you build yourself (or have built) to expose your own tools, data, and policies to AI agents. "Custom" is doing two kinds of work in that definition.
The first is surface: a custom MCP exposes capabilities that off-the-shelf connectors don't. That might be a proprietary internal API, a table in a data warehouse your agents need to read, a workflow that cuts across three systems, or a domain-specific action ("generate a reconciliation report for this period") that has no public analog.
The second is governance: a custom MCP enforces your specific rules. Which actions require human approval? Which records can the agent read and which are off-limits? What audit trail gets written on every tool call? These are not incidental details — for regulated deployments they are the entire point.
When you actually need one
Most teams don't need a custom MCP to get started. If your agent needs to talk to Salesforce, Slack, Gmail, GitHub, or another widely-supported system, there are already MCP servers for those — sometimes official, sometimes community-maintained — and you can adopt them without writing a line of protocol code.
You need a custom MCP when one or more of these is true: your tool surface is proprietary (internal APIs, domain-specific data, unusual workflows); your governance requirements exceed what off-the-shelf connectors offer (you need audit logging beyond what the vendor writes, or approval gates they don't implement); or your compliance posture requires data handling that a third-party connector can't give you (residency, encryption-at-rest standards, role-based boundaries).
If none of those apply, adopt what exists and move on. The cost of a custom MCP is the engineering work to build, document, test, and maintain it over years. That cost only pays back when the value it adds is structural, not cosmetic.
Anatomy of a good custom MCP
A good custom MCP has four properties: it is small in surface area, explicit in its boundaries, defensive in its defaults, and observable in its behavior.
Small surface means it exposes the minimum set of tools needed for the agent workflows you actually run. Every additional tool is additional risk: one more way the agent can misbehave, one more audit surface, one more thing to maintain. Resist the temptation to expose everything the agent might ever need; expose what this quarter's deployment needs and grow the surface deliberately.
Explicit boundaries means every tool describes what it does, what inputs it accepts, what side effects it has, and what it does not do. "Create record" is bad; "Create a Lead in Salesforce in the Inbound Web queue with these specific fields, no ownership change, no email trigger" is good. The MCP is both documentation and contract.
Defensive defaults means the tool refuses, not allows, when preconditions aren't met. Missing input? Refuse. Out-of-scope record? Refuse. Rate limit approaching? Back off. The agent can always retry with more context. What you cannot easily undo is a silent wrong action.
Observable behavior means every tool call writes a structured audit entry: who asked, what the agent decided, what ran, what came back, how long it took, and what policy evaluations gated it. This is the difference between an AI agent you can trust in production and one you can only run in a demo.
Common traps
The first trap is building one giant tool. A single tool that takes "what do you want to do?" as an argument is not a tool — it's a re-invention of the LLM inside your MCP. Break the surface into small, specific, well-named tools and let the agent compose them.
The second trap is leaking too much context. Every tool response that includes data is context the agent can now reason over — and potentially leak in its next turn. Return the minimum data needed for the specific action. If the agent needs more, it should call again.
The third trap is inconsistent governance. If your MCP has 20 tools and only 3 of them write audit logs, you effectively have no audit trail. Governance must be cross-cutting: apply the same policy engine, the same log structure, and the same permission model to every tool.
The fourth trap is treating MCP as an afterthought. Teams often build the agent prompting and reasoning layer first, then bolt on MCP at the end. The result is tools shaped around what the prompt already does, rather than what the agent actually needs. Design the tool surface first, then the agent.
How GrowTK approaches custom MCPs
In GrowTK engagements, custom MCP design is part of the discovery phase, not the build phase. We spend the first week mapping what the agent will actually need to do, what the audit surface should look like, and where policy boundaries sit. The MCP server comes out of that conversation.
Every custom MCP we ship includes: a tool surface sized to the deployment (typically 5–15 tools for a first deployment), explicit per-tool documentation, a shared policy layer that evaluates every call, structured audit logging that compliance teams can query, and integration tests that exercise both the happy path and adversarial cases.
We treat the MCP as the durable artefact. The agent prompting evolves; the foundation model changes; the governance layer should outlast both.