What Is an MCP Server? A Practical Guide for GTM Data

An MCP server gives an AI client a controlled way to use external systems. For GTM data, that means the model can request a search or enrichment run without becoming the system that stores, validates, or invents the resulting records.

What an MCP server is

An MCP server is a service that exposes external capabilities as tools an AI client can discover and call.

Model Context Protocol is a standard way for AI clients to work with those tools. A client such as Claude, ChatGPT, Cursor, or Codex can connect to an MCP server, inspect its available tool definitions, and invoke a tool when it is relevant to the user's request.

This separates several things that are often conflated:

• The AI model interprets the user's request and decides whether a tool may help.
• The AI client hosts the model interaction and connects to the MCP server.
• The MCP server describes available tools, validates inputs, performs the requested work, and returns results.
• The external data service finds or resolves the requested records.
• The user still defines the goal, constraints, and acceptable output.

An MCP server is not a chatbot. A chatbot is a user interface for conversation. It may use MCP tools, but it can also operate without them.

It is also not the same thing as a REST API. A REST API exposes HTTP routes directly to an application you control. An MCP server exposes named tools to an AI client using the Model Context Protocol. Both can sit over the same underlying data and validation layer.

For example, Enrichments provides an MCP server at /api/mcp over Streamable HTTP. It uses the same API key as the REST API. Its tools include people and company search, people and company enrichment, and job retrieval.

The important boundary is simple: the model can ask for data work, but the enrichment system remains responsible for running that work and returning the record fields it actually resolved.

How MCP tool calls work in practice

An MCP tool call follows a structured sequence: the client discovers tools, selects a tool, sends validated inputs, and receives structured output.

The client first learns what the server can do. Tool descriptions tell it the tool name, its purpose, and the input shape it accepts. That description matters. It gives the client enough context to distinguish a people search from a people enrichment request, or a company lookup from a job poll.

A typical flow looks like this:

1. You describe a task in natural language.
2. The AI client examines the available MCP tools.
3. The client selects a relevant tool based on the request and tool description.
4. The client sends structured inputs to the MCP server.
5. The server validates the request and starts or completes the data work.
6. The client receives the returned result and presents it in the conversation or workflow.

The model chooses when to call a tool. The server controls what the tool accepts and what it does.

That distinction becomes important when an operation can spend credits or trigger a live data lookup. A vague prompt such as “find good prospects” is not enough operating detail for a repeatable GTM workflow. The client needs to turn that request into constraints that the tool can validate.

For enrichment work, constrained inputs prevent several common failures:

• Requesting fields that do not exist in the field catalogue.
• Treating a company search as though it enriches a known company record.
• Assuming a work email is included when it was never requested.
• Sending a broad request without reviewing its expected spend.
• Writing incomplete or unmatched data back into a CRM.

Schemas also make the response easier to consume safely. You do not need to infer whether an operation succeeded from conversational prose. You can inspect a job status, result wrapper, and returned data fields.

MCP authentication belongs in this flow as well. The AI client authenticates to the MCP server with the API key required by the service. Keep that key in the environment or credential system used by your integration. Do not place it in prompts, exported chat transcripts, or user-visible tool arguments.

Where enrichment fits into an MCP workflow

Enrichment fits after you define whether you need to discover new entities or resolve entities you already hold.

That distinction is the foundation of useful enrichment workflows.

Search for new people

Use a people search when you need to find people matching an ideal-customer profile. The search_people MCP tool is for requests shaped around criteria such as:

• Titles
• Seniority
• Department
• Location
• Employer

A search returns people who match the request. It is useful for building a research set from a defined audience.

The tool does not return work email addresses by default. If you need addresses, treat that as a separate and explicit field request during people enrichment.

Enrich contacts you already know

Use people enrichment when you already hold an identifier for a person and need additional fields.

The enrich_people tool can resolve a LinkedIn URL, an email address, or a name plus employer into a person record. You can request fields such as:

• title
• seniority
• department
• location
• company
• company_domain
• linkedin_url
• email

This is where a work email address can be requested. The email field is billed only when an address is found, and the returned address includes an email status. Valid values are verified, probable, unverified, risky, undeliverable, and unknown.

A returned email is a work address found from public sources. The service probes the address and returns its status as part of the run. The status is useful operational data, but it does not remove your responsibility to define how your team handles outreach, suppression, and record retention.

Resolve company context

Use company enrichment when your starting point is a domain, company name, or LinkedIn URL.

The enrich_companies tool resolves company records with fields including company name, domain, LinkedIn URL, location, country, and headline. Company rows also include firmographics such as industry, employee count, founded year, annual revenue, total funding, latest funding round, and monthly visits.

This supports practical GTM data automation patterns:

• Start with account domains from a target-account list.
• Resolve company context before assigning account tiers.
• Search for companies matching a defined firmographic profile.
• Enrich known contacts after a form fill, event list import, or CRM export.
• Present the resulting records for analyst review before any system writeback.

The data is live rather than a licensed static database. A repeated query can legitimately return different data later. Your workflow should preserve when a record was enriched and avoid assuming that a field will remain unchanged.

Design controls for agent-led data enrichment

Agent-led enrichment needs operating controls around identity, fields, spend, and downstream actions.

The agent should help you plan and execute a request. It should not silently define your target market, choose costly fields, or write records into a CRM without matching rules.

Start with explicit field selection. The people field catalogue is closed. A request for a field outside the supported set is a validation error, not an empty column. That is useful because it forces the workflow to name the data it expects.

For people, use only the fields needed by the next step. If you are routing leads, title, seniority, department, and company_domain may be enough. If you need a work email, request email explicitly. If you need phone, request phone explicitly and treat it differently from email.

A mobile number is sourced from a LinkedIn profile URL and billed only when found. It has no deliverability verdict. Availability is not a representation that it is lawful to call. Your obligations under consent rules, DNC registries, TCPA, and local requirements remain yours.

Next, make spend visible before execution where the interface supports it. The in-product chat agent shows what it is about to spend. CSV upload provides a cost preview before the run begins. In an agent workflow, the same principle still applies: keep the request narrow, name the fields, and review the intended scope before triggering the tool.

Then separate exploration from CRM writeback.

A safe sequence is:

1. Define the target criteria and exclusions.
2. Run the search or enrichment.
3. Review the returned rows and item-level outcomes.
4. Apply identity matching rules for your CRM.
5. Define field-level overwrite rules.
6. Write only approved fields to the destination system.

Do not let a conversational summary become the writeback payload. Use the structured result. Define whether a returned title can replace an existing title, whether blank results preserve existing fields, and how you handle multiple possible matches.

Natural-language requests should also become concrete targeting criteria before execution. A useful brief names:

• The audience: title, seniority, department, location, or employer criteria.
• The entity type: people or companies.
• Known identifiers: LinkedIn URLs, emails, names plus employers, domains, or company names.
• Exclusions: departments, geographies, employers, or other groups you do not want.
• Requested output fields.
• The intended review or destination step.

That turns an open-ended agent request into a reviewable data operation.

Handle synchronous and queued enrichment results correctly

You should inspect the response envelope before polling because some requests return results inline and others are queued.

A people or company search for ten results or fewer can return inline. An enrichment request with five rows or fewer can also return inline. In those cases, the HTTP response already contains results, and job.status is already terminal.

Larger requests are queued. Requests asking for the email field are queued as well. A request using async: true or Prefer: respond-async is also queued.

Every search, enrichment, and job-poll response uses the same envelope:

{
  "job": {
    "object": "job",
    "id": "job_id",
    "type": "people_enrich",
    "status": "running",
    "fields": ["title", "company"],
    "requestedCount": 0,
    "resultCount": 0,
    "creditsUsed": 0,
    "error": null,
    "createdAt": "timestamp",
    "startedAt": "timestamp",
    "finishedAt": null,
    "url": "job_url"
  },
  "results": null,
  "page": null,
  "estimatedCredits": 0
}

The conceptual consumer pattern is:

1. Read job.status.
2. If results is present, process the returned items.
3. If results is null, poll GET /api/v1/jobs/{id}.
4. Continue until the job reaches a terminal status.
5. Follow the opaque forward-only cursor in page when results are paged.

The job statuses are queued, running, succeeded, empty, failed, and cancelled. The terminal states are succeeded, empty, failed, and cancelled.

Do not assume every input resolved just because the job reached succeeded. Results are wrappers, not direct person or company rows:

{
  "position": 0,
  "status": "succeeded",
  "data": {
    "title": "Example title",
    "company": "Example company"
  },
  "evidence": null,
  "error": null
}

Each item has its own status: pending, running, succeeded, not_found, or failed. The resolved person or company record is inside data.

This matters for CRM workflows and exports. Preserve input order through position, inspect the item status, and avoid treating not_found as a successful enrichment with blank fields.

If your application retries a REST request, include the same Idempotency-Key header as the original request. That is what makes the retry deduplicated. Without it, a retry is a new request with a new job and a new hold.

When an MCP server is the right integration surface

Use an MCP server when an analyst or AI agent needs to explore, plan, and execute enrichment work through tool calls.

MCP works well when the operating pattern is conversational or agent-led:

• An analyst describes an ICP and reviews the resulting people.
• An agent turns a defined brief into a company search.
• A research workflow enriches known identifiers and returns structured records.
• A client needs AI agent tools available inside its existing environment.

Use REST when you need application-controlled pipelines. The REST API is the better fit when your own service controls request timing, retries, queue handling, storage, and downstream system writes. It exposes search and enrichment routes under /api/v1, with an OpenAPI document at /api/v1/openapi.

Use the in-product chat agent for guided ad hoc work. It plans a run from a plain-language brief, shows expected spend, and returns a table you can export.

Use CSV upload when the source of truth is a file. You can upload a list, map columns to requested output fields, review the cost preview, and download the enriched file.

These surfaces serve different operating patterns, but they share the same data validation and credit model. A lookup that returns nothing costs nothing. Enrichment is charged only when at least one requested field is resolved. Searches are charged per person or company returned because identity is the delivered unit.

For a narrow pilot, use this checklist:

• Choose one GTM use case, such as enriching known contacts with current titles and employers.
• Define the identifiers you already hold.
• Name the exact fields you need.
• Decide which results require human review.
• Keep CRM writeback out of the first exploratory run.
• Inspect job and item statuses rather than relying on a conversational summary.
• Document retry behavior and use Idempotency-Key for REST retries.
• Review the resulting fields before expanding the workflow.

An MCP server is useful when it gives an agent a clear boundary: the agent can request work, while your enrichment system remains accountable for the data returned, the validation applied, and the credits charged.