Brokerkit MCP
Use Brokerkit's remote MCP server to let an AI assistant read authorized team data and prepare actions for human approval. It uses the existing Brokerkit OAuth and API permissions.
For connection steps, see Connect Brokerkit to Claude and ChatGPT. For underlying request fields and REST responses, see the OAuth API reference.
Connection and authentication
| Setting | Value |
|---|---|
| Production MCP URL | https://mcp.brokerkit.com/mcp |
| Transport | Streamable HTTP |
| Authentication | OAuth through Brokerkit sign-in and user consent |
| Account access | Existing administrator access to an active Brokerkit team |
| Data boundary | The connection's authenticated user, selected team and granted scopes |
Configure the assistant with the MCP URL and OAuth. Team API keys belong to the direct API integration, not this connection. Users authorize independently; tool arguments cannot select another team or supply another user's token.
Rate limits
MCP uses Brokerkit's OAuth API allowance: 100 API requests per minute
per Brokerkit OAuth access token, shared across all /v2/
endpoints using that token. MCP adds no separate rate limit.
One MCP request or tool call can make multiple API requests for identity and permission checks, target reads and the requested operation. These requests count toward the same allowance, so 100 API requests does not mean 100 MCP tool calls.
When the API returns HTTP 429 Too Many Requests, MCP reports the
rate-limit failure and retains valid Retry-After guidance where
available. Wait for the indicated delay; a rate limit alone does not require
reconnecting. MCP does not automatically retry. Before attempting a write again,
inspect its receipt and reconcile any unknown outcome to avoid duplicate changes.
See OAuth API rate limits for the response headers.
Available operations
The current MCP maps 19 API operations: 12 reads and seven actions that first create a preview. Approval and receipt helpers support those actions. Tool availability is filtered by the connection's actual permissions.
| Capability | Operation names | Required scopes |
|---|---|---|
| Connected identity and team | getMe |
contacts_read |
| Team reference data | listLabels, listCampaigns, listLeadSources, listLeadStatuses, listTeamMembers, listProductionLabels |
contacts_read |
| Contact lookup and activity | findLeadsByEmail, getLead, listLeadActivities |
contacts_read |
| Saved searches and matching contacts | listSavedSearches, listSavedSearchLeads |
contacts_read |
| Create or update a contact | createOrUpdateLead |
contacts_read + contacts_write |
| Change campaign enrollment | enrollLeadInCampaign, removeLeadFromCampaign, enrollSavedSearchInCampaign, removeSavedSearchFromCampaign |
contacts_read + campaigns_write |
| Create or schedule email | createLeadEmail, createSavedSearchEmail |
contacts_read + emails_write |
Lists return one page, normally 25 records and at most 100. Use the returned
pagy.next with the operation's pagination parameters to continue. The service
does not automatically retrieve every page. Array-only responses omit pagination
metadata and do not establish that the whole result set was retrieved.
Preview, approval and receipts
- Call the selected action to save a preview. This step does not submit a business change to the Brokerkit API.
- Review its full payload, target, team, schedule and disclosed side effects.
- Use the client's human approval interface. Supported clients show an inline Approve/Cancel card; a supported confirmation form is another permitted path. A chat message or model-supplied approval boolean cannot authorize dispatch.
- Read
getWriteReceipt(preview_id)through the same authenticated connection to inspect the result. TheexecuteWriteconfirmation helper is used only where the client supports its human confirmation flow.
Previews expire after five minutes. Identity, permissions, target information and expiry are rechecked before dispatch. Cancelling before dispatch prevents submission; cancelling cannot undo a request already submitted. Reopening a saved card does not grant a second execution.
| Receipt result | Meaning / next action |
|---|---|
accepted |
The API returned a successful response. Inspect its HTTP status, result and outcome; HTTP 202 means queued, with completion or delivery unverified. |
cancelled / expired |
The preview was stopped before dispatch. A later attempt needs a new preview. |
failed |
Inspect the sanitized failure details. Correct the cause before creating another attempt. |
unknown |
Submission may have happened. Reconcile the receipt with Brokerkit before retrying. |
These are terminal or uncertain outcome examples; intermediate statuses can also appear while awaiting approval or verifying. The service does not automatically retry failed or uncertain business requests. Receipts are stored durably within their retention window and cleaned up after 24 hours; save evidence needed for longer-term records. A receipt is not a permanent deduplication key or a promise of exactly-once upstream execution.
Important behavior
- Contact updates: follow the OAuth API reference's required email, duplicate
matching and notification rules.
test: truevalidates without saving a contact; it does not prove duplicate matching or a real save succeeded. - Emails and campaigns: inspect recipients, timing and sender limitations. Campaigns can trigger later outreach. Saved-search actions use the contacts matching when the background worker runs; the preview count is an estimate, not a frozen recipient list. Accepted email work is not delivery evidence.
- Permissions and errors: current Brokerkit access rules remain authoritative. A missing or narrower grant can hide tools or deny a call. See Rate limits for API throttling and retry guidance.
- Availability: the initial service uses one instance, so maintenance can interrupt access. No universal uptime, throughput or all-client guarantee is implied by the connection instructions.