Adrata Developers

MCP Server

Adrata exposes customer-gated tools for revenue agents: intro paths, buyer rooms, company research, people enrichment, pipeline scoring, and workspace memory. These docs explain the contract. Real data requires an authenticated Adrata workspace.

Install

Use MCP when the agent environment supports tools directly. Use the REST API when you need server-side control, webhooks, or product integrations.

Terminal

npx -y @adrata/adrata-mcp

Environment

ADRATA_API_KEY=adrata_live_xxxxxxxxxxxxxxxxxxxxxxxxxx
ADRATA_API_URL=https://api.adrata.com

ADRATA_API_URL is an origin, not a versioned path — the server appends /api/v1 itself. It already defaults to https://api.adrata.com, so most installations can leave it unset.

An API key is not the whole product

An API key alone gives you the pro tier. Buyer rooms, opportunities, and governed writes need a workspace session — either an OAuth token in ADRATA_OAUTH_TOKEN, or the interactive connect_workspace tool, which opens a browser consent screen and binds the server to the workspace you approve there.

Workspace session

connect_workspace

Why the tool list can look wider than your access

Workspace-session tools are advertised in tools/list on every tier, so an agent can call one and receive an upgrade response rather than data. That is deliberate — an agent should be able to discover what exists — but it means the tool list is a catalogue, not an entitlement. The five tools below are the ones this affects.

Where to start (10 of them)

A fresh tools/list carries about 377 tools the moment the server starts — the whole CRM surface is registered up front. That is a lot to read, so these are the ones to reach for first. Intro groups come first because access opens the deal.

Intro Groups

find_intro_path

Find warm paths into a company or stakeholder.

get_access_score

Inspect whether the team can reach the people who matter.

Companies and People

search_companies

Search companies by name, domain, filters, vertical, or CRM context.

enrich_company

Return available firmographic, signal, and source-provenance fields.

search_people

Search people by available workspace and provider fields.

enrich_person

Return available role, contactability, and provenance fields.

Pipeline and Actions

list_actions

List assigned or relevant actions with status and ownership.

get_path_to_power

Inspect the route into the stakeholders who can move the deal.

Research and Memory

save_memory

Save approved workspace memory for future recommendations.

recall

Retrieve approved team memory for an account, person, or vertical.

Needs a workspace session (5 tools)

Visible on every tier, but they return data only once the server holds a workspace session.

list_buyer_groups

List buyer-room records available to the authenticated workspace.

get_buyer_group

Read a buyer-room record, including roles, coverage, and provenance.

search_opportunities

Search accessible opportunities and deal context.

create_action

Create a governed action when the tool and workspace permit writes.

create_intro_request

Create a governed intro request when the workspace permits it.

Toolsets: the rest of the surface, loaded on demand

The server registers 377 tools at startup. Eight named toolsets declare 76 tools, including names already registered at startup; loading all eight brings the unique total to 448. Call list_toolsets to see what exists and enable_toolset to load one. Three toolsets (crm, communications, infrastructure) require a workspace session. Your tier, scopes and workspace permissions determine which operations you can use.

Loading a toolset

list_toolsets
enable_toolset({ name: "prospecting" })

// research_company is now callable

Primitive	Use	Key APIs
prospecting	10 tools	Cited company research, including research_company.
intelligence	5 tools	Signals, triggers, and account intelligence.
outreach	8 tools	Sequences, campaigns, and messaging.
crm	7 tools	Records, pipeline, and CRM maintenance.
communications	7 tools	Calls, text messages, delivery status, calling identities, calendar, and meetings.
knowledge	4 tools	Documents, memory, and workspace knowledge.
infrastructure	10 tools	Webhooks, exports, and operational surfaces.
matrix	25 tools	Analytics, forecast risk, anomalies, and GTM intelligence.

How MCP differs from the REST API

The two share an authentication model, scopes, and idempotency behaviour: an idempotencyKey on a governed write becomes an Idempotency-Key header, so a retried call cannot double-apply. Three things do not carry over, and it is better to know now than during an incident.

Tiers and toolsets are MCP-only. REST has no equivalent of the pro/workspace ladder or of enable_toolset; scopes alone decide access.
Rate-limit headers are not surfaced. The REST x-ratelimit-* family does not reach an MCP caller. The server honours retry-after and paces its own retries.
Request IDs are not surfaced. A tool result carries no x-request-id, so quote the tool name and a timestamp when contacting support rather than a request ID.

MCP also records to its own audit channel rather than the REST audit log, and that channel is best-effort by design: it will not block a tool call in order to record one.

Governed by default

API keys and OAuth scopes decide exactly which workspace data and actions an agent can use. Every read, write, enrichment call, and outbound action carries provenance, owner, and budget controls. Agents should react to changes through webhooks and async jobs rather than polling.