Your agent needs Circleback context: what a customer said on yesterday's call, which action items are still open, who attended the last three syncs. Circleback now ships two ways to get it. One is a hosted Model Context Protocol (MCP) server that went live in January 2026; the other is a REST API that landed in August. They overlap on reads, split hard on writes and email, and put you on completely different credential models. Here's how to pick.
Both surfaces read the same account data and respect the same meeting permissions. The difference is the consumer each was built for: MCP for AI clients, the API for code you write and control.
Circleback launched its MCP server on January 13, 2026. It is a centrally hosted remote server at circleback.ai/api/mcp, maintained by Circleback and served over Streamable HTTP. Authentication is OAuth with DCR: any compliant client registers itself and sends the user through a one-time browser consent. There is no developer app to create first.
The 11 tools are SearchMeetings, ReadMeetings, SearchTranscripts, GetTranscriptsForMeetings, SearchActionItems, SearchCalendarEvents, SearchEmails, FindProfiles, FindCompanies, ListTags, and SearchSupportArticles. Every one is a read. The official reference is the Circleback MCP article in Circleback's support center.
The REST API lives under circleback.ai/api and returns JSON. Its resources are Meetings, Action items, Calendar, Companies, People, and Tags. Unlike MCP, it writes:
Auth is a single mechanism. The user creates a key under Settings, API keys. The key is shown only once, is formatted cb_<secret>, and is passed as Authorization: Bearer. The official reference is the Circleback API documentation. Free plans include API, MCP, and CLI access, with limited meeting history.
Four dimensions decide the choice: what each path can do, which auth model it forces on you, what you own in production, and which agent shapes fit each one.
The read surfaces overlap heavily. The gaps are directional: email search and transcript-chunk search exist only on MCP, and every write exists only on the API. The two tables below split reads from writes.
The write gap is the one that decides architectures. Three agents that cannot run on MCP at all:
Those agents need PUT /action-item/{actionItemId}, the tag endpoints, and POST /meetings.
The reverse gap is email. SearchEmails queries the mailboxes the user has connected to Circleback, and the API reference has no email resource. A meeting prep agent that wants the last thread with a prospect alongside the last call gets both from one MCP connection. On the API path, email means a second connector.
MCP tools are written for models. Most of them require an intent parameter. SearchMeetings and SearchCalendarEvents use it to return relevant excerpts instead of full records. SearchTranscripts returns matching chunks with start and end timestamps, which is exactly the retrieval step you would otherwise build yourself on top of raw API transcripts.
On the API path, you fetch whole meeting objects and full transcripts, then chunk, rank, and trim them before they enter context. That costs more tokens and more code. In exchange, you control exactly what the model sees.
Each user signs in to Circleback and consents in a browser once. The resulting token is bound to that user's account and inherits their meeting permissions. Circleback states that users only see meetings they already have access to through MCP.
There is no client ID or secret to provision and no redirect URI to register. For a product onboarding hundreds of users, a consent click is the lowest-friction credential flow available. To understand the mechanics behind this, see the deep dive on Dynamic Client Registration in OAuth2 and its role in agentic auth.
The API documents one credential: a cb_ key the user creates by hand and copies out of Settings. The API overview describes no scopes, no expiry, and no OAuth option for third-party apps.
A key reads whatever the user can see and writes with the user's authority, including deleting meetings they own. Onboarding therefore means asking every user to generate a secret and paste it into your product. That is a support burden and a security surface at the same time.
Both paths end in the same place: one Circleback credential per user. MCP hands you an OAuth grant per user; the API hands you a pasted key per user. In neither case does the path itself solve storage, rotation, or revocation. Those are infrastructure problems regardless of which path you choose.
For a detailed comparison of the trade-offs, read OAuth vs API Keys for AI Agents.
MCP tools paginate by pageIndex:
A pageIndex is only valid with the exact same search parameters, so a model that changes a date filter mid-loop breaks its own pagination.
The API uses opaque cursors, returned in an RFC 8288 Link header with rel="next". Cursors cannot be reused with different filters.
Rate limits are counted per Circleback account, across all API keys and MCP or CLI OAuth tokens:
Requests over the limit return 429 with a Retry-After header. On Free, your agent shares 20 requests a minute with the user's own Claude or Cursor MCP session.
On the MCP path, Circleback owns the tool schemas and descriptions. When they change, your agent's tool selection can shift without a redeploy on your side. That is useful, but it is also untested drift.
On the API path, you own request construction, error handling, and retries. The API was only weeks old at the time of writing, and its overview does not describe a versioning scheme. Pin the behavior you depend on with contract tests.
The decision tracks what your agent produces, not a preference for one protocol. Use Circleback MCP when:
Use the Circleback API when:
Pick either path and the same infrastructure problem arrives with your second customer.
Fifty users means fifty Circleback credentials: fifty OAuth grants on MCP, or fifty cb_ keys on the API. Each one must be encrypted at rest, isolated per tenant, never logged, and never placed in the model's context.
Each can also stop working without warning. When a user disconnects the integration or deletes a key, your agent finds out on the next failed call.
The API path adds a sharper edge. A leaked cb_ key is the user's whole account, reads and writes, and nothing in the documented model narrows or time-limits it. For the storage side of this problem, see why a token vault is critical for agent workflows.
Scalekit's Circleback MCP connector runs the OAuth 2.1 and DCR flow, stores tokens in its vault, and refreshes them. Your agent calls tools by user identifier and never holds a Circleback token.
At the time of writing, the Scalekit catalog lists a Circleback MCP connector only. For the REST path, a custom connector with bearer auth plus Tool Proxy gives you the same model: a Scalekit hosted page collects the user's key, Scalekit stores it, and each request is signed server-side. The MCP vs API decision no longer changes your auth infrastructure.
Both paths share one runtime model: a connection configured once, a connected account per user, and calls resolved by user identifier. The examples below use Python and LangChain, with a TypeScript version at the end.
Create a connection for the Circleback MCP connector under AgentKit, Connections in the Scalekit dashboard. These examples use circlebackmcp as the connection name. The string you pass as connection_name must match the dashboard exactly; a mismatch here is the most common integration error.
In production, send the link to the user from your app instead of blocking on input(). The authorize a user guide covers that flow.
The agent should not load a flat connector catalog. list_scoped_tools, which the LangChain adapter calls under the hood, returns only the tools this user's connected account is authorized to call. The tool_names filter then narrows that to the four tools a follow-up agent actually needs. What the user can't do, the agent can't do.
For a single deterministic call, skip the model and call execute_tool directly:
Writes need the API. Register it once with the management API as a BEARER connector pointed at Circleback's API base URL. Get $env_access_token from your environment's /oauth/token endpoint using the Client Credentials grant.
Next, create a connection for the new connector in the dashboard; this example names it circleback-api. For non-OAuth connectors, the authorization link opens a Scalekit hosted page that collects the key, so the same ensure_active helper works unchanged.
actions.request() takes a path relative to the connector's proxy_url and returns the raw HTTP response. Scalekit attaches the stored key server-side, so the key never appears in your process.
To let the model decide when to write, wrap these calls in your own LangChain tool functions and bind them alongside the MCP tools. List endpoints paginate by cursor, so pass cursor in query_params on follow-up requests.
The Node SDK exposes the same two call shapes: executeTool for the MCP connector and request for Tool Proxy. Save this as agent.mts and run it with npx tsx agent.mts.
Two capabilities matter most once a Circleback agent leaves the demo: attributable logs for every downstream call, and Virtual MCP for agents that span several tools and tenants.
Every execute_tool and Tool Proxy call runs against a specific connected account. Scalekit's agent logs record who authorized each call, which agent ran it, and the response, and they can be exported to your SIEM.
Meeting data raises the stakes here, because transcripts carry pricing, personnel, and legal conversations. When a security reviewer asks which transcripts the agent read for which user, the answer is a queryable record, not a reconstruction from application logs. See agent tool observability and audit trails for agent auth.
Circleback agents rarely stop at Circleback. A follow-up agent reads the call, then posts to Slack. A Virtual MCP Server declares exactly that surface once: which connections, and which tools from each.
One server definition serves every user. Before each run, you mint a short-lived session token scoped to that user's connected accounts. There is no MCP server to deploy, host, or maintain.
LangChain connects through langchain-mcp-adapters, using the static server URL and the per-user token as bearer auth. The endpoint stays the same for every user; only the identity changes.
Circleback's 11 tools plus Slack's full catalog would put dozens of tool definitions into every context window. At roughly 200 tokens each, 40 tools burn 8,000 tokens before the agent does any work, and a model choosing from that many tools picks the wrong one more often.
The Virtual MCP Server above exposes four. The fix is not better prompting; it is surface reduction. For more on this pattern, read when to use a Virtual MCP Server. For a broader look at how tool calling auth patterns evolve as agents move to production, that post covers the full landscape.
If your agent answers questions over meetings, calendar, and email, start on Circleback MCP. You get 11 model-oriented tools, DCR onboarding, and the only path with email search.
If your agent writes back, the API is the only option: tagging calls, completing action items, importing history, or running a deterministic sync. Many production Circleback agents will use both, with MCP for retrieval and the API for the write-back step. Budget them together, because they share one per-account rate limit.
The credential problem is identical on both paths. That is the part that needs production-grade infrastructure.
Start with the Circleback MCP connector docs, browse the Circleback connector page, or scan the full connector library. For the REST path, follow add your own connector.
To start from a working pattern, adapt the meeting prep agent template or the sales call prep agent template. Pricing for agent tool calling is on the AgentKit pricing page. For sibling comparisons, read Granola MCP vs Granola API and Zoom MCP vs Zoom API.
Building a Circleback agent and want a second pair of eyes on the auth model? Use the Talk to us page for immediate help.
.png)
