Your agent needs cap table data. Maybe it prices an option pool refresh before a board meeting. Maybe it assembles the LP report at quarter close. Maybe it just answers "what is our fully diluted count" in Slack without a finance lead opening a spreadsheet. Carta ships a hosted MCP server and a five-suite REST API, and they are not two views of the same surface. They differ on what is reachable, how a credential is obtained, and how long that credential survives.
Two objects, two very different shapes. One is a conversational dispatcher gated by a user's Carta role. The other is a partner-integration platform gated by a Carta review process.
Carta hosts a remote MCP server at mcp.app.carta.com/mcp over HTTP transport. Authentication is OAuth: the first connection opens a browser, the user signs in to Carta, and the client reuses the grant afterwards. Carta layers three official Claude plugins on top of that endpoint (Cap Table, Investors, CRM), which are skill bundles rather than separate servers.
Coverage is genuinely broad. Carta's own plugin guides describe ownership by share class, SAFEs, convertible notes, option grants and vesting, 409A valuations, financing history, waterfall and exit modeling, fund NAV and TVPI, LP capital accounts, portfolio company financials, and Total Comp benchmarks.
The REST platform sits on api.carta.com with date-free versioned paths, currently v1alpha1. It is organized as five suites, each aimed at a stated partner type: Launch for incorporation partners and law firms, Investor for fund operators, Issuer for law firms and technology partners, Portfolio for personal finance management partners, and CRM for investment teams.
Auth is OAuth 2.0 (RFC 6749) with two grant types: Authorization Code for third-party data and Client Credentials for data inside your own Carta account. Scopes follow a read_{package_and_resource} and readwrite_{package_and_resource} pattern, so read_issuer_securities covers issuer option grants.
The CRM does not follow either pattern cleanly. Its MCP documentation lists 158 generally available tools at the same hosted endpoint, split 91 read-only and 67 write, covering contacts, companies, deals, fundraising, investors, fees, notes, tasks, themes, reports, and email campaigns.
The CRM REST API, by contrast, authenticates with an API key that an organization admin generates from Settings, not with platform OAuth. Carta's plugin setup guide confirms this: the CRM plugin expects an API key in the environment while the other two plugins use OAuth. If your agent spans equity and CRM, you are managing two credential types from the same vendor.
The capability gap here is not the usual "MCP covers 80 percent of the API" story. In several places the MCP surface reaches further than the public REST suites, and the REST suites reach places MCP does not go at all.
Read the middle rows carefully. Modeling, fund performance, and comp benchmarks are the places where the MCP surface goes further than the documented REST suites, which inverts the usual assumption.
The operational differences decide more agent architectures than the data gaps do. Two rows in particular, headless execution and a pinned contract, are the ones that force teams onto the REST path regardless of coverage.
Most vendor MCP servers map one tool to one endpoint. Carta does not. The connector surfaces 18 tools, and four of them do almost all the work: cartamcp_discover lists available commands filtered by domain and scope, cartamcp_fetch executes a read command, cartamcp_mutate executes a write, and cartamcp_search_tools plus cartamcp_call_tool reach named tools.
The upside is real: 18 tool schemas in context instead of 158, and new Carta commands become reachable without a schema update on your side. The cost is that your agent has to discover before it can act.
A deterministic pipeline wants to know at build time exactly which call it will make. On the Carta MCP path, the command name is resolved at runtime from a discover result, which means an extra model turn, an extra chance to pick the wrong command, and a failure mode that only appears when a command name changes.
Cache the discovery output per domain and validate the command string before you pass it to cartamcp_fetch. Treating discover as a per-run lookup is what makes cap table agents slow and non-reproducible.
Carta's Cap Table plugin guide is explicit: all queries are read-only, and the plugin cannot create, modify, or delete records. The Investors guide says the same, and adds that its Excel and financial-statement skills write workbooks locally rather than back to Carta.
The tool surface tells a slightly different story. cartamcp_mutate exists and documents POST, PATCH, PUT, and DELETE, and cartamcp_discover accepts scope=write. The reconciliation is that writes resolve per domain and per role. For agent design, assume equity data is read-only until discover proves otherwise for your specific domain, and never build a workflow whose success depends on an unverified write path into a cap table.
Both paths issue a credential per user. Neither issues one you can safely treat as permanent, and only one of them supports running without a human present.
The hosted server authenticates through an interactive OAuth flow. There is no API key alternative, no service account, no static credential shortcut. Carta's security notes make the delegation model explicit: the agent can only reach data the signed-in account already has permission to view.
For an interactive equity assistant that is exactly right. For a scheduled job that runs at 6am with no user in the loop, it is a hard constraint, not a configuration option.
Client Credentials is the meaningful difference. You create a Carta user that exists only for API access and cannot log in to the web app, associate it with your client credentials, and your agent authenticates with no interactive flow.
That unlocks background execution. It also centralizes risk in one credential whose blast radius is the whole account, which is the standard tradeoff. If you are weighing this generally, OAuth versus API keys for AI agents covers the decision in more depth.
This is the number most Carta agent builders miss. Access tokens live one hour. Refresh tokens live 14 days, and each successful refresh returns a new access token and a new refresh token, so the clock resets on every refresh.
Go 14 days without refreshing and the grant is gone. The user has to complete the consent flow again. A quarterly board reporting agent that only wakes up four times a year will find every credential in its store dead on arrival. The fix is a proactive refresh schedule that runs independently of agent execution, which is a different system from your agent. Handling token refresh for AI agents walks through the failure modes.
Carta re-verifies the granting user's role on every call. If a company admin changes that user's role after consent, the API returns 403 Forbidden with reason MISSING_INTERNAL_PERMISSION.
Your agent needs to distinguish that from a token problem. A revoked grant and a downgraded role fail differently and need different recovery paths: one requires re-consent, the other requires a human at the customer to restore access.
Carta manages hosting, schema updates, and permission enforcement on the MCP path. Everything about the credential lifecycle stays with you on both paths, plus a few Carta-specific constraints worth planning around.
Carta allows bursts to 10 requests per second with a ceiling of 300 requests per minute, and returns X-RateLimit-Remaining-Second and X-RateLimit-Remaining-Minute headers on every response.
Agentic workloads amplify request counts in a way traditional integrations do not. A single "show me red flags across the portfolio" prompt can fan out into a discover call, an account list, and one fetch per company. Across 40 portfolio companies that is dozens of calls for one user turn. Read the headers and back off rather than discovering the limit in an incident.
The MCP path needs a Carta login. The API path needs Carta's approval. Carta requires you to build in the playground environment first, incorporate approved branding assets if your app is user-facing, document your rollout plan and expected traffic, and record a demo of the full integration flow.
Submission review takes one to two weeks by Carta's own estimate. The suites are also audience-gated by design: Launch is described for incorporation partners and law firms, Portfolio for personal finance management partners. If your product is not one of those, the suite you want may not be available to you at all.
MCP tool schemas are unversioned. When Carta updates the hosted server, your agent picks up the change without a redeploy, which is convenient right up until a command signature moves under a running pipeline.
REST paths are versioned, currently v1alpha1, so you pin and migrate on your own schedule. For a workflow where an unexpected schema change is an incident rather than an inconvenience, that difference decides the question.
Both lists below are specific to Carta. Generic MCP advice does not survive contact with a cap table.
Scalekit's catalog ships one Carta connector today, the vendor MCP connector at slug cartamcp. It is a genuine constraint worth naming up front: there is no separate Carta REST connector, so direct API work goes through a custom connector rather than a catalog entry.
Without it, you are writing the Carta OAuth dance, a token store, a refresh scheduler that beats the 14-day window, a revocation path, and per-tenant isolation, before your agent reads a single share class.
The Carta MCP connector docs list the exact tool names and schemas, and the Carta connector page covers the auth lifecycle. Credentials resolve server-side at request time and never enter LLM context.
Install the SDK and create or look up the connected account for the current user. The connection_name string has to match the connection name configured in your Scalekit dashboard exactly; this is the most common integration error.
For production redirect handling and verify_connected_account_user, see Authorize a user.
Before the agent loads anything, it is worth being precise about what is being loaded. list_scoped_tools does not return a flat catalog of everything Carta offers. It returns the tools this connected account is authorized to call, which for a stakeholder with limited Carta permissions is a smaller surface than for a company admin.
actions.langchain.get_tools() returns native StructuredTool objects, so no schema reshaping is needed. Bind them and run the loop.
Filtering the tool list you hand the model is not enforcement. The model can still be talked into calling anything the connection exposes, and cartamcp_mutate is a write path into a cap table.
A Virtual MCP server is where the allowlist becomes real. You declare which connections and which tools the endpoint exposes, once per agent role, and get back a static mcp_server_url. For a board reporting agent, that means four tools instead of 18, with cartamcp_mutate structurally absent rather than merely discouraged.
The server definition is shared across all users. The token is not. Check that the stakeholder's connection is still active, then mint a short-lived token scoped to that one user.
This check is where the 14-day refresh window surfaces as a clean, recoverable error instead of a mid-task failure. Set expiry longer than the expected run and never reuse a token across sessions.
Mastra's MCP client discovers tools and Zod schemas directly from the endpoint, so there is no manual conversion step. Pass the per-user URL and token from your backend, never a process-wide value; a shared token runs every request as one stakeholder.
When your agent needs a REST suite the MCP server does not cover, Launch or the Data Warehouse for instance, register Carta's REST API as a custom connector and call it through the same proxy. The credential still resolves server-side and the call lands in the same audit chain.
That is the point of running both paths through one layer: the MCP versus API choice stops being an auth decision and becomes a routing decision.
Cap table data is among the most sensitive material a B2B agent will ever touch. Ownership percentages, strike prices, liquidation preferences, and LP capital accounts are the kind of records where a cross-tenant leak is not a bug report, it is a disclosure event.
Carta's per-user model is architecturally correct. Every MCP tool call runs as the authenticated stakeholder, and the API re-verifies that user's role on every request. A stakeholder who cannot see board-confidential documents in the Carta web app cannot reach them through your agent.
That is enforcement of identity. It is not management of the credential.
For an agent serving 60 finance users across 12 portfolio companies, that is 60 OAuth grants to store encrypted and isolated per tenant, 60 access tokens to rotate hourly, 60 refresh tokens to keep alive inside a 14-day window, and 60 revocations to honor when someone changes jobs.
The token type differs between the MCP and API paths. The infrastructure does not. This is the same problem described in access control for multi-tenant AI agents, and it does not get easier because you picked one path over the other.
A shared service account makes every Carta read look identical in your logs. For equity data, that is the difference between an answerable audit question and an unanswerable one.
Scalekit attributes each downstream call to the stakeholder who authorized it: who triggered it, which tool ran, what came back, with 90 days of history and SIEM export. When a compliance officer asks who pulled the Series B preference stack in March, the answer is a query rather than an investigation. Agent tool observability covers what these logs need to contain.
The honest answer for Carta is not the usual one. The MCP server is not a reduced view of the API; on modeling, fund performance, and comp benchmarks it reaches further than the public REST suites do.
If a human is present and the agent answers questions, Carta MCP is the better path and probably the only one you need. If the agent runs unattended, onboards companies, or queries fund data in bulk, you need the API, which means clearing Carta's partner review before you can ship.
Most production Carta agents end up on both: MCP for the interactive assistant, REST for the scheduled pipeline. What does not change across that split is the credential layer. Sixty stakeholders, sixty grants, a 14-day expiry window, and an audit trail that has to name a person rather than a service account. That is the part worth building on infrastructure instead of building yourself.
Start with the Carta MCP connector docs for the full tool reference, or browse the Carta connector page for the auth lifecycle and framework snippets.
Adjacent finance connectors worth wiring alongside it: QuickBooks, Xero, and Stripe MCP. The full catalog is at all agent connectors.
For patterns to start from, the revenue forecast commentary agent, deal room sync agent, and meeting prep agent templates all use the same per-user auth model. Usage tiers are on the pricing page.
Building an equity or fund agent on Carta and hitting the refresh window, the partner review, or the dispatcher design? Talk to an engineer.
