Skip to main content
abm.dev
← Notes from the data layer

enrichment MCP server

enrichment MCP server

Stuart McLeod5 min

Here is a working config. Drop it into your MCP client and your agent can call verified B2B enrichment immediately.

{
  "mcpServers": {
    "abm": {
      "type": "url",
      "url": "https://mcp.abm.dev/mcp"
    }
  }
}

No SDK swap. No new dependency tree. The agent discovers the tools, reads the schema, and calls them. That is the whole point of MCP.

What is an enrichment MCP server, exactly?

MCP — Model Context Protocol — is the standard that lets an AI agent discover and call external tools at runtime, without you hardcoding every API client into the agent loop. An enrichment MCP server is a server that exposes data-enrichment capabilities through that protocol.

The agent asks: what tools do you have? The server returns a manifest. The agent picks the right tool, passes the right arguments, and gets back structured data — company firmographics, verified contact details, funding rounds, technographics — whatever the server exposes.

Three capabilities, at minimum, define a useful enrichment MCP server:

  1. Company enrichment — takes a domain or company name, returns canonical firmographic data: headcount, industry, revenue band, tech stack, recent funding.
  2. Contact enrichment — takes a name plus domain, returns verified contact details, title, LinkedIn URL, seniority.
  3. Account search — takes an ICP definition, returns a ranked list of matching companies. The prospecting primitive.

Without all three, you have a lookup tool, not an enrichment layer.

Why does the agent need MCP instead of a direct API call?

It does not need MCP. You can hardcode a direct API call in every agent. Plenty of teams do.

The problem is what happens at scale. Six enrichment tools means six auth schemes, six error surfaces, six rate-limit budgets, and six sets of field names that do not agree with each other. employees from one provider, headcount from another, staff_count from a third. The agent has to reconcile all of it before it can act — and if you have not built that reconciliation layer, it acts on whichever number it saw last.

Featureform's EnrichMCP framework names this cleanly: agents need agentic enrichment — type-safe, relationship-aware data models the agent can introspect, not raw API responses it has to guess at. Their Apache-licensed Python framework is built precisely to give agents a navigable data layer rather than a pile of JSON.

MCP solves the discovery and interface problem. A good enrichment MCP server solves the data quality problem underneath it.

How does an agent actually discover and call the tools?

The flow is straightforward.

  1. Agent initializes. It calls tools/list on the MCP server.
  2. Server returns a manifest: tool names, descriptions, input schemas, output schemas.
  3. Agent receives a task — enrich this account list before the sequence fires.
  4. Agent selects the company enrichment tool, passes {"domain": "stripe.com"}.
  5. Server calls its upstream providers — aggregates, dedupes, and returns one canonical object.
  6. Agent receives structured data with field-level confidence scores and source citations.
  7. Agent acts. Writes the personalization. Triggers the sequence. Logs the provenance.

Step six is where most enrichment MCP servers fail. They return data. They do not return provenance. The agent cannot tell whether the CEO name came from a live LinkedIn scrape this morning or a cached record from eighteen months ago. It cannot tell whether the email was validated or guessed. So it acts on bad data at machine speed — which is exactly the failure mode your team is trying to avoid.

This is the problem we wrote about in detail here: why your AI SDR is hallucinating prospect data.

What separates a production enrichment MCP server from a prototype?

Look at what is circulating in the open-source ecosystem. Enrich.so's MCP server exposes a broad set of enrichment tools through a single URL endpoint — emails, contact validation, company search — accessible to Claude, ChatGPT, Cursor, and any other MCP-compatible client. Useful starting point. General-purpose.

MSAdministrator's enrichment-mcp takes a different angle: enrichment for security observables, built in Python, pulling from multiple security data products. A proof-of-concept that shows how narrow the use case can get when you build MCP enrichment for a specific domain.

Both illustrate the same architectural truth: the MCP interface is the easy part. Anyone can wrap an API in an MCP server in an afternoon. The hard part is what runs behind the interface.

For B2B go-to-market, the production requirements are specific:

  • Multi-provider aggregation. One field, ten providers behind it. The server reconciles; the agent does not have to.
  • Confidence scores per field. Not a single score for the whole record. Field-level. The agent needs to know whether to trust the mobile number before it dials.
  • Source citations. Where did this data point come from? When was it last verified? Agents operating in autonomous loops need this to make defensible decisions. See company and contact data with citations and confidence scores for what that looks like in practice.
  • Freshness signals. Stale data is not neutral. It is actively harmful. A funding round that closed two years ago, presented as current context, sends your agent in the wrong direction.
  • No silent fallbacks. If a provider returns nothing, the server should say so — not quietly substitute a lower-confidence value and pretend it did not.

No fabricated facts. No silent fallbacks. No per-source bills your team has to reconcile at month-end.

Why abm.dev built MCP as a first-class channel

Most enrichment APIs bolt MCP on as an afterthought. A thin wrapper. A weekend project someone shipped to the docs page.

We built it the other way. The MCP server is a first-class distribution channel because the people building AI-agent go-to-market are not sitting in dashboards. They are writing agent loops in Python and TypeScript. They need data that arrives in the shape an agent can use — eighty-nine canonical fields, reconciled across ten providers, with confidence scores and source citations attached.

A great rep once knew every account. Now your agents do.

That is not a metaphor. It is an engineering requirement. The agent has to know the real budget cycle, the actual decision-maker, the technology the account is running today — not last quarter. It has to know what it does not know, so it does not act on a gap.

Personalization, at scale.

That is what an enrichment MCP server is actually for.

Try it

The abm.dev playground is free. Point your MCP client at https://mcp.abm.dev/mcp, run a tools/list call, and see the manifest. Then enrich a domain. Check the confidence scores. Check the citations.

If it looks right — and it will — use code LAUNCHCODES for launch credits.

abm.dev — the account-based marketing API for AI agents.

Stuart McLeod · Co-founder, abm.dev