Your agent needs partner ecosystem data. It needs to know which partners already sit inside an open opportunity, who can make a warm introduction, and what moved in the ecosystem overnight. Crossbeam ships a hosted MCP server and a Partner REST API, and they are not two views of the same surface. They cover different capabilities, sit behind different plan gates, and bill against two entirely different meters. Here is how to pick.
These are two separate products with separate access models. Reading them as "the AI one" and "the programmatic one" will lead you into the wrong plan tier.
Crossbeam MCP is a Crossbeam-hosted remote server at https://mcp.crossbeam.com/mcp over Streamable HTTP. Auth is OAuth 2.1 with PKCE and Dynamic Client Registration (DCR). Every tool is read only.
It went generally available on all plans on September 1, 2026, the same day Crossbeam Credit metering began enforcement. Some pages on Crossbeam's marketing site still describe the earlier Supernode and Enterprise early access; the Crossbeam MCP Server documentation carries the current state. Full tool schemas and the changelog live in the official MCP Server technical docs.
The Crossbeam Partner API is a REST surface covering partners, populations, partner populations, records, partner records, overlaps, reports, and ecosystem signals. You register a custom integration in Crossbeam to get a client_id and client_secret.
Auth is OAuth 2.0 Authorization Code against https://auth.crossbeam.com/authorize with the audience https://api.getcrossbeam.com. Documented scopes are openid, read:partnerships, read:reports, read:populations, and write:activity-timeline. Access tokens are valid for 24 hours; add offline_access to receive a refresh token. Every request carries an Xbeam-Organization header holding the org UUID, which you resolve from /v0.1/users/me.
This is the constraint most teams discover after they have already written code. REST API access is available on the Supernode plan and above. Signal webhooks are Enterprise only.
MCP has no such gate. Free, Connector, Supernode, and Enterprise all get it, subject to a per-plan credit allocation and a per-user seat requirement.
Four dimensions decide this: what the agent can call, what auth path you land on, what the call costs you, and what breaks in production. Capability is the least interesting of the four, so start there and get it out of the way.
The MCP server is the only place Crossbeam's derived intelligence is exposed. Partner recommendations run on the same engine as Deal Navigator. Partner suggestions run on Partnerbase data. Net new accounts come from Pipeline Generation. None of these are documented as REST endpoints.
The Partner API is the only place you get raw scale and push. Bulk record search, population objects, report-scoped record pulls, and the signals webhook exist nowhere in the MCP tool list.
Crossbeam states this plainly: the MCP tools read ecosystem intelligence and return it. get_list_link generates a shareable link so a human can jump into the UI, but no documented tool changes data in Crossbeam.
For an agent, this is a design constraint, not a limitation to work around. A co-sell agent that reads overlap and then does nothing is a search box. The action half of that workflow lives in Slack, Salesforce, or HubSpot, which means your Crossbeam agent is a multi-connector agent by construction.
Crossbeam Credits meter MCP access only. Baseline allocations are 50 per year on Free, 500 on Connector, 2,500 on Supernode, and 5,000 on Enterprise. Credits pool across the whole organization, reset annually, and do not roll over.
REST calls and webhooks do not touch credits. They count against Record Exports instead, where each unique record is counted once per term. Supernode includes 25,000; Enterprise starts at 100,000.
Take a stated scenario: one Enterprise tenant, 25 sales reps, an always-on co-sell agent that scans overlaps and refreshes account context on a schedule.
Crossbeam's own Credits FAQ estimates roughly 1,000 credits per month for an always-on automation pattern. At 25 reps that is 25,000 credits a month, which exhausts the 5,000 credit annual baseline in under a week. Annualized at the flat rate of $0.10 per credit, and buying the discounted 100,000 packs, you are looking at roughly $27,000 a year in credits alone.
Now run the same agent on the Partner API. Re-reading the same 20,000 accounts every day consumes 20,000 unique records against the term limit, not 20,000 per day. The Record Export meter is indifferent to frequency. The credit meter is not.
MCP gives you Authorization Code with PKCE and DCR, per user, browser-interactive. Every rep authorizes with their own Crossbeam credentials, and the data returned reflects their seat and permissions. SAML SSO is supported. A Full Access or Sales seat is required to connect at all, which is a real onboarding failure mode in a multi-tenant agent: a valid tenant with the wrong seat type simply cannot complete the flow.
The Partner API also uses Authorization Code, but you register one integration and hold a refresh token. Crossbeam even sells a dedicated Integration User seat on Supernode and Enterprise, which is an explicit blessing of the service-account pattern.
Per-user MCP identity is the correct security posture. It also means N OAuth grants, N seat allocations, and N revocation events per tenant.
A single Integration User is operationally simpler and centralizes risk. Every call runs under one grant, so you lose per-user attribution and you inherit whatever that one user could see. Crossbeam's own Gong integration surfaces the tradeoff verbatim: choose Shared access and everyone using the connection sees the data the authorizing person is permitted to see, regardless of their own seat or permissions. That is the shared-credential failure mode, documented by the vendor. What the user can't do, the agent can't do, only holds if the agent runs under that user.
MCP requires an interactive browser flow per user before the first call. There is no static credential shortcut. Once the grant exists, a background agent can keep calling, but the initial consent is unavoidable and per person.
The Partner API is friendlier to schedules. One authorization produces a refresh token; access tokens expire every 24 hours and you rotate proactively. Crossbeam does not document a client credentials grant, so "no human ever" is not on the menu either. The difference is how many humans, and how often.
On MCP, Crossbeam owns hosting, scaling, and permission enforcement. You own token storage per user, re-consent when a grant is revoked, credit budget monitoring, and tolerance for tool schema changes you do not control.
On the Partner API, you own all of that plus request construction, pagination, retries, and webhook verification. Webhook security is HMAC: validate X-Crossbeam-Signature-256 against the body plus X-Crossbeam-Timestamp, reject timestamps outside a 300 second window, and expect retries on 408, 429, 500, 502, 503, and 504.
Crossbeam states that Partner API rate limits are defined in its security policy and subject to change at its discretion. No numeric limit is published.
Plan for backoff you cannot size in advance. For a deterministic nightly pipeline that is manageable. For a latency-sensitive interactive agent it is a reason to keep the call count per user turn low.
The MCP tool surface is a managed contract, and it changed. find_overlaps became find_overlapping_accounts_and_leads. find_overlap_partners became find_overlapping_partners. Three tools were added: find_partner_shared_contacts, find_new_accounts, and get_partner_overlaps_shared_context.
Agents that hard-coded tool names against the earlier surface break silently, because a missing tool looks like a model that chose not to call anything. The fix is structural: enumerate the authorized surface at runtime instead of pinning names in source. Every code sample below does exactly that.
Crossbeam does the identity part well. It does not do the lifecycle part at all, and neither does the protocol you picked.
Per-user MCP grants inherit the authorizing user's seat and sharing rules. Partner data a partner has not shared does not appear, no matter how the agent phrases the request. That is the right enforcement point and it is genuinely enforced.
What Crossbeam gives you is an access decision at call time. What it does not give you is a place to keep the resulting credential.
In a multi-tenant agent serving 25 reps across 8 customer orgs, the MCP path produces 200 OAuth grants to store encrypted, isolate per tenant, refresh, and revoke when a rep leaves. The Partner API path produces 8 integration credentials with 24-hour access tokens and refresh tokens that also need proactive rotation.
The token type differs. The infrastructure does not. Both need a vault, tenant isolation, proactive refresh rather than reactive 401 handling, and a revocation path tied to your own offboarding events. Scalekit's Crossbeam MCP connector handles the OAuth flow, token storage, and refresh for the MCP path, so the choice between paths does not change your auth infrastructure.
Scalekit's catalog entry for Crossbeam is the MCP connector, exposed under the connection name crossbeammcp. For the Partner REST API you register a custom connector and call it through the Tool Proxy. Both end up in the same connected-account model.
Create the connection once in the Scalekit dashboard under AgentKit > Connections, then install the SDK.
The connection_name used in every call below must match the connection name configured in your Scalekit dashboard exactly. Mismatched connection names are the single most common integration error.
The rep authorizes Crossbeam once. Scalekit runs the OAuth 2.1 flow with PKCE and DCR against mcp.crossbeam.com, then vaults the resulting credential against your identifier for that user.
Remember the seat requirement. If this rep does not hold a Full Access or Sales seat in Crossbeam, the flow will not complete, and that is worth surfacing as a distinct onboarding error rather than a generic auth failure.
Before the agent calls anything, retrieve the tools this rep's connected account is authorized to call. This is not a catalog lookup. It is the scoped, deterministic surface derived from one user's grant, and it is also your defence against the September tool renames.
For a deterministic step where you already know what you want, call execute_tool directly rather than routing through the model.
Verify tool names against the Crossbeam MCP connector reference rather than copying them from an older integration. get_account_context, get_partner_context, find_partner_recommendations, and get_ecosystem_activity survived the September release unchanged; the two overlap tools did not.
actions.langchain.get_tools() returns native StructuredTool objects scoped to this rep, so there is no schema reshaping and no Scalekit-specific logic inside the loop. This is the same pattern described in our LangChain tool calling deep dive.
If your agent needs populations, reports, or bulk records, the Partner API is the only path. Register it as a custom connector, then call upstream endpoints through the Tool Proxy with actions.request().
The credential is resolved server side at request time. It never enters your agent runtime, your logs, or the model context. See Add your own connector for the connector definition.
Because Crossbeam MCP is read only, any useful co-sell agent spans at least two connectors: Crossbeam for the intelligence and something else for the action. That is exactly the shape Virtual MCP servers exist for.
A standard MCP server exposes every tool it has. Point an agent at Crossbeam MCP and Slack and it sees the union of both surfaces, most of which it will never need.
Virtual MCP servers invert that. You declare which connections and which specific tools an agent role can see, once. Each run then gets a short-lived token scoped to one user's connected accounts. The endpoint is static; the identity is not.
Four tools total: three reads from Crossbeam and one write to Slack. The agent cannot generate list links, cannot query the knowledge base, and cannot touch any Slack tool other than sending a message.
OAuth grants expire and users revoke them. Check before every run rather than discovering it mid-task.
Mastra's MCP client reads the tool list and Zod schemas straight off the URL, so there is no schema conversion step.
Tool bloat is normally an accuracy and token-cost argument: 40 tools at roughly 200 tokens each burns 8,000 tokens before the agent does any work, and models select badly from a decision space that large. Scoping to five or ten tools cuts that overhead by around 80%.
With Crossbeam, there is a third cost. Every speculative MCP tool call the model makes because it had too many options draws real credits from a pooled annual balance that does not roll over. Surface reduction stops being a quality optimization and becomes a line item. Model upgrades help. They are not the lever.
Crossbeam's Plan and Billing page shows credit consumption broken down by MCP tool call and active user, and only admins can see it. That tells your customer's admin how much was spent. It does not tell you which agent run spent it or why.
Every tool call Scalekit executes is logged with full attribution: who authorized the call, which agent ran it, what came back, and whether it failed on your side or upstream. executeTool returns an executionId you can correlate against your own traces.
For a credit-metered upstream, this is the difference between "our Crossbeam bill tripled" and "the retry loop in the nightly scan is calling get_partner_context four times per account." More on the pattern in agent tool observability and audit trails for agent auth.
In a multi-tenant deployment, a Crossbeam credit exhaustion in one tenant looks identical to a revoked grant in another if all you have is a stack trace. Logs keyed to the connected account separate them.
That separation is also what a security reviewer asks for. See access control for multi-tenant AI agents for how the isolation model holds up under that questioning.
Two clean cases, then the messy one most teams actually land in.
If your agent is rep-facing and its value is Crossbeam's derived intelligence, build against MCP. Partner recommendations, partner suggestions, and Pipeline Generation net new accounts exist nowhere else, per-user seat enforcement is doing real work for you, and credit consumption stays tied to human conversation volume.
If your agent runs on a schedule over a stable account set, or needs populations, reports, bulk records, or push, build against the Partner API and accept the Supernode floor. Per-unique-record billing is structurally kinder to frequency than per-call credits.
Most production Crossbeam agents end up on both, plus a third connector for the write. So the deciding question is not which surface is richer.
It is which meter your call pattern runs into first, and whether your credential infrastructure can carry N per-user grants and a service credential at once without you building it twice.
Browse the Crossbeam MCP connector on Scalekit or read the connector reference. Pair it with the Salesforce, HubSpot, Gong, and Slack connectors for the write half of a co-sell workflow, or browse all connectors.
Starting from a template is faster than starting from a blank file. The CRM AI agent, sales call prep agent, deal intelligence agent, and outbound prospecting agent all follow the pattern above, and the full set lives under GTM and RevOps. Usage-based details are on the pricing page.
Building a Crossbeam agent and hitting something specific? Join the Scalekit Slack community, or talk to us for immediate help.
