MCP connect#

disburse ships a Model Context Protocol server, so agents can use search, enrich, and verify as native tools; the same engine as the REST API, exposed as tool calls.

The server lives at /mcp on the same host as the API and is bearer-authenticated with the same API keys.

Available tools#

All tools are read-only (declared via MCP annotations, so clients can call them without confirmation prompts) and the search tools declare output schemas and return structuredContent for typed, validated results.

Billing is per lead delivered: 1 credit for each NEW row that carries an email or phone. Contact-free rows, re-delivered leads, searching, filtering and verification are free, and each billed response reports the charge in its Summary.billing section.

Building lists#

For "give me N …" requests, pass count (1 to 25,000) in ONE call instead of paging: the server paginates, deduplicates and quality-filters internally. Up to 500 the rows come back inline; above that the same call becomes an export and returns a job id to poll with fetch_export. Every row carries a match_tier (strict / filtered / ranked) and the response Summary reports composition, what was excluded (with reasons), and a mandatory stopped_reason — so your agent can say "46 verified matches, padded to 100 with labeled close matches" instead of guessing.

{ "query": "founders in Australia", "count": 200, "quality_bar": "balanced" }

quality_bar: strict (high-confidence only, may honestly under-fill), balanced (default; strict first, then labeled backfill), broad (ranked). When answering "how many …", use StrongMatches — Total counts the structured filters alone; keywords rank, they never narrow. The one exception: when keywords are the whole ask on a people search (two or more words, nothing else), the set is narrowed to the records that clearly carry them, the response says so (keywords_gated), and Total counts that set.

Just want the click-by-click setup for Claude? See Connect Claude.

Connect with an API key#

Every client points at the same Streamable HTTP endpoint and passes your key as a bearer token. What differs is the file each one reads and what it calls the fields, so pick your client below. (Claude and ChatGPT use the sign-in connector instead; see Connect Claude and Connect ChatGPT.)

Claude Code, Cursor and most agent frameworks take this shape:

{
  "mcpServers": {
    "disburse": {
      "type": "http",
      "url": "https://api.disburse.dev/mcp",
      "headers": { "Authorization": "Bearer sk_live_your_key" }
    }
  }
}

Claude Code documents type as required for a remote server; Cursor does not need it and ignores it, so one block covers both. Claude Code can also add the server in one command:

claude mcp add --transport http disburse https://api.disburse.dev/mcp \
  --header "Authorization: Bearer sk_live_your_key"

Cursor#

Cursor has a one-click install: Add to Cursor opens Cursor with the server pre-filled and runs the sign-in flow. The shared block above also works under Settings → MCP → Add new server, in .cursor/mcp.json per project or ~/.cursor/mcp.json globally. Cursor resolves ${env:NAME} inside headers, so the key can live in your environment instead of the file.

VS Code#

VS Code reads .vscode/mcp.json (or your user profile) and names things differently: the root key is servers, not mcpServers, and type is required. Without it VS Code treats the entry as a local command and tries to run the URL as a program.

{
  "servers": {
    "disburse": {
      "type": "http",
      "url": "https://api.disburse.dev/mcp",
      "headers": { "Authorization": "Bearer sk_live_your_key" }
    }
  }
}

Windsurf#

Windsurf reads ~/.codeium/windsurf/mcp_config.json and calls the endpoint serverUrl. A block using url is accepted without an error and then never connects, so the wrong field looks like a server with no tools rather than a mistake.

{
  "mcpServers": {
    "disburse": {
      "serverUrl": "https://api.disburse.dev/mcp",
      "headers": { "Authorization": "Bearer sk_live_your_key" }
    }
  }
}

Codex#

Codex uses TOML at ~/.codex/config.toml, and takes the NAME of an environment variable rather than the key itself, so the token never sits in the file:

[mcp_servers.disburse]
url = "https://api.disburse.dev/mcp"
bearer_token_env_var = "DISBURSE_API_KEY"

Then export DISBURSE_API_KEY in your shell profile. Codex reads it at startup and sends it as the Authorization header. codex mcp add disburse --url https://api.disburse.dev/mcp writes the same entry for you.

ChatGPT#

ChatGPT adds remote MCP servers from its Plugins page (chatgpt.com/plugins; Business, Enterprise, Edu and Pro): select Add → Add custom MCP server, paste https://api.disburse.dev/mcp as the Server URL with OAuth, tick the custom-server acknowledgement, click Create as a plugin and sign in. The full flow, plus the older Custom GPT Action for other plans, is on Connect ChatGPT.

GitHub Copilot#

Copilot in VS Code reads .vscode/mcp.json (or your user profile via MCP: Open User Configuration), with servers as the root key and type required. Give it the URL alone and VS Code runs the sign-in flow on first use; or prompt for a key once and keep it out of the file:

{
  "servers": {
    "disburse": {
      "type": "http",
      "url": "https://api.disburse.dev/mcp",
      "headers": { "Authorization": "Bearer ${input:disburseKey}" }
    }
  },
  "inputs": [
    { "id": "disburseKey", "type": "promptString", "password": true, "description": "Disburse API key" }
  ]
}

Copilot CLI: in a session run /mcp add, choose HTTP, paste the URL, put {"Authorization": "Bearer sk_live_your_key"} in headers and * for tools. It writes ~/.copilot/mcp-config.json (mcpServers root, with a tools key); /mcp show disburse lists the tools it loaded.

Copilot coding agent (the one that works on issues and PRs on github.com) runs unattended and cannot sign in, so it needs a key stored as a secret. In the repository, Settings → Copilot → Coding agent: add a Copilot environment secret named COPILOT_MCP_DISBURSE_KEY (the prefix is required), then in MCP configuration:

{
  "mcpServers": {
    "disburse": {
      "type": "http",
      "url": "https://api.disburse.dev/mcp",
      "headers": { "Authorization": "Bearer $COPILOT_MCP_DISBURSE_KEY" },
      "tools": ["search_people", "search_companies", "enrich_person", "enrich_company", "get_account_info"]
    }
  }
}

tools is required there; ["*"] enables everything. The coding agent uses tools without asking and search and enrichment spend credits, so an explicit list is the safer default.

Microsoft 365 Copilot#

Microsoft 365 Copilot takes MCP through a Copilot Studio agent (or a declarative agent built with the Microsoft 365 Agents Toolkit). In Copilot Studio open your agent's Tools → Add a tool → New tool → Model Context Protocol, give it a name and description, set the server URL to https://api.disburse.dev/mcp, and choose OAuth 2.0 → Dynamic discovery: disburse supports discovery and dynamic registration, so there is nothing else to fill in. Create a connection, sign in with your disburse account, and Add to agent. Generative orchestration must be on, and a Power Platform data policy may need to allow the connector.

Prefer a key? Choose API key → Header, name the header Authorization, and enter the value as Bearer sk_live_your_key; the word Bearer is required. In the Agents Toolkit route choose OAuth (with dynamic registration); API keys aren't offered for MCP plugins there.

Any other client#

MCP is an open protocol and the list above is not exhaustive. For anything else, follow that client's own MCP setup and give it https://api.disburse.dev/mcp as the server URL. Use its sign-in flow where it has one; otherwise pass your key as an Authorization: Bearer header, whatever the client calls that field.

Clients that support sign-in for remote servers, Cursor included, also accept the URL alone and run the same sign-in flow Claude does (see below); pick whichever your client offers.

On a company-managed plan the client's admin usually has to allow a new MCP server before it can be added; the config is unchanged once they do.

One-click connect (OAuth)#

When the server is deployed with OAuth enabled, clients like Claude and ChatGPT can connect with a single "Connect" click instead of a pasted key: you sign in, approve the scopes on the consent screen, and the client is issued a token that maps to your organization. No key handling on the client side.

Both paths authenticate against the same accounts: an API key and an OAuth session resolve to the same org and the same rate limits.