Your agent needs to read and write a creator's Kit account. Kit ships a remote MCP server at app.kit.com/mcp and a full REST API at api.kit.com/v4, and Kit's own documentation describes the MCP as sitting on top of the API. That framing makes the two look interchangeable. They are not. The auth model, the throughput ceiling, and the set of writes that will actually complete without a human in the loop all differ. Here is how to pick.
Both surfaces authenticate against the same v4 backend, and both act on a single creator account. The difference is what sits between your agent and that account, and what each layer is willing to do unattended.
The Kit MCP is a remote server at app.kit.com/mcp, built and operated by Kit. Authentication is OAuth on behalf of the creator; the AI client opens a Kit authorization flow on first connect and the resulting access token is scoped to that creator's account. Scalekit's connector page classes the flow as OAuth 2.1 with Dynamic Client Registration, which is why clients like Claude Desktop and Cursor connect from a URL alone with no client ID to register.
Running any tool requires a paid Kit plan, Creator or Creator Pro. Free accounts can connect and inspect the catalogue, but tool execution returns an upgrade prompt instead of a result. Official reference: Kit MCP on developers.kit.com.
The v4 REST API lives at api.kit.com/v4 and covers subscribers, tags, segments, custom fields, forms, sequences, sequence emails, broadcasts, snippets, posts, products, purchases, domains, and webhooks. Pagination is cursor-based; v3 is still reachable but deprecated and slated for sunset.
Two auth mechanisms are supported. API keys go in an X-Kit-Api-Key header and are meant for automating your own account. OAuth 2.0 uses the Authorization Code grant, with the refresh token flow for web servers and PKCE for public clients, and it is the only path Kit supports for apps that other creators install. Official reference: Kit API v4 overview.
Four dimensions decide this for an agent team: what the tools can do, what completes without a human, what throughput you get, and what you own when it breaks.
Kit's published tool reference, last updated in July 2026, enumerates 72 tools across 17 groups. The connection guide quotes "65+" and notes the catalogue grows as new tools ship; Scalekit's connector currently catalogues 81, including beta landing page tools, Commerce product tools, and two entries flagged as stale after Kit renamed them upstream. Those three numbers are not a contradiction. They are the shape of an unversioned tool surface.
The coverage is genuinely broad. The gaps cluster in one place: anything a scheduled, unattended pipeline needs to finish on its own.
The MCP's create_webhook takes an event object with a single name plus optional filter IDs, and a target_url. That is the shape of Kit's legacy /v4/webhooks resource, and Kit has explicitly superseded it. Legacy webhooks carry one event type each, ship no signature, and drop failed deliveries on the floor.
The replacement, /v4/webhook_endpoints, is API-only. It gives you many event types per endpoint, HMAC-SHA256 signature verification via X-Kit-Signature, batched envelopes of up to 100 events, live secret rotation with an overlap window, UUID event IDs for deduplication, and eight retry attempts across roughly 41 hours.
If your Kit agent is event-driven rather than polling, that row alone decides the question. You cannot build a verifiable, retried event pipeline on the MCP surface.
This is the constraint most teams discover after the demo. Kit annotates every MCP tool with readOnlyHint, destructiveHint, idempotentHint, or openWorldHint, and clients use those hints to decide when to prompt.
Two separate mechanisms follow from that, and they behave differently. The first is client-side: your AI client prompts before each call, and Kit states plainly that this is enforced by the client and cannot be disabled server-side. The second is Kit-side and much harder to route around.
For destructive or open-world actions, Kit's MCP does not run the action at all. It returns a deep link into the Kit app, and the write fires only when someone clicks Confirm there. Kit names the set: sending a broadcast, deleting an email sequence, unsubscribing a subscriber, and firing a webhook.
Reads and ordinary writes do execute. Creating a subscriber, applying a tag, and drafting a broadcast all complete over MCP without ceremony. But a nightly re-engagement agent that unsubscribes hard-bounced contacts and sends a win-back campaign will stop and wait for a human. That is not a retry problem. It is a design decision, and it is the right one for the creator sitting in Claude Desktop.
The MCP supports OAuth and nothing else. There is no API key mode, no service credential, no headless bootstrap. A background agent that has never had a browser session for a given creator cannot get on the MCP surface at all.
The v4 API accepts both. API keys authenticate through X-Kit-Api-Key, are created per account in Developer settings, and are explicitly not supported for public integrations. They also cannot reach the bulk namespace or purchase creation. OAuth 2.0 is required for anything other creators install, and it is what unlocks the full endpoint surface.
Kit's OAuth grants expose exactly two scopes, read and write. You cannot issue a Kit token that reaches subscribers but not broadcasts, or analytics but not deletes. Whichever path you pick, the credential your agent holds is coarse. Narrowing it is your job, above the token.
Kit rate-limits the MCP to 120 requests per minute per token. Kit rate-limits API keys to 120 requests over a rolling 60-second window, and documents 600 for OAuth on the same window.
Read that twice. The MCP authenticates with OAuth but is capped at the API key tier. You get OAuth's identity model with an API key's throughput.
For a creator asking questions in a chat window, 120 is invisible. For an agent paginating a 40,000-subscriber list, it is the whole story. Kit's own guidance confirms the shape of the problem: the MCP returns subscribers a page at a time to protect the client's context window, so each page is a separate tool call, and bulk operations surface a confirmation roughly every 100 subscribers.
With the MCP, Kit owns the server, the tool schemas, and the mapping onto v4. When Kit ships a capability, your agent picks it up without a redeploy. That is real operational value, and the beta landing page tools that appeared on the MCP surface show where Kit is investing.
What you still own: the OAuth token per creator, storage, refresh, revocation detection, and tenant isolation. You also own schema drift. Kit's MCP tools are unversioned, and the two entries in Scalekit's catalogue marked stale after upstream renames are the visible evidence.
With the API you own the whole stack: endpoint selection, cursor pagination, error handling, retries, and the token lifecycle. In exchange you get a stable contract and the endpoints the MCP does not expose.
Four situations where the hosted server is the faster and better choice.
Five situations where the MCP's constraints are disqualifying rather than inconvenient.
Pick either path and you end up in the same place: one Kit OAuth credential per creator, held by you, valid until someone revokes it.
Kit's own multi-account guidance makes the multi-tenant shape obvious. To serve a second creator, Kit tells the user to install a second connector with a distinguishing suffix on the URL. That is a workable answer for an agency managing three newsletters from one desktop. It is not an architecture for a product with 200 customers.
Kit is also explicit that MCP access is account-level. Once the MCP is connected, every user on that Kit account inherits it, and there is no per-user restriction today. Your product has to draw that boundary, because Kit does not.
The MCP OAuth flow gives you a token per creator. The API's OAuth flow gives you a token per creator. Neither gives you encrypted storage, proactive refresh before expiry, revocation detection, or tenant isolation. Those are infrastructure, and they cost the same to build regardless of which surface you called.
A creator can revoke a client from Kit's MCP settings page at any time, and your agent finds out on the next call, mid-run, as an auth error. If you are not handling that explicitly, the failure is silent.
Scalekit's Kit connector handles the OAuth flow, encrypted token storage, refresh, and revocation for the MCP path, so the MCP vs API decision does not change what you build for auth.
Recommended reading: Token Vault: Why It's Critical for AI Agent Workflows and How to Handle Token Refresh for AI Agents.
Kit states it directly: audit logging for MCP actions is not currently exposed, and creators should check whether their AI client offers its own trail. Kit logs MCP requests the way it logs any web request, and per tool call it captures only a categorical user_goal plus an anonymous session_id, both of which are stripped before the request reaches the Kit API.
For a personal newsletter, that is fine. For a B2B product whose customers ask which agent tagged 8,000 subscribers on a Tuesday, it is a gap you have to close yourself.
Scalekit ships Kit as a vendor MCP connector under the slug kitmcp. Some tools in the catalogue have both a REST connector and an MCP connector on separate pages; Kit currently has one, the MCP connector, which matches Kit's own OAuth-only position. Full tool schemas live on the Kit MCP connector docs.
The connection name in code must match the connection you configured in the Scalekit dashboard. This is the single most common integration error.
Install with pip install scalekit-sdk-python, or npm install @scalekit-sdk/node for TypeScript.
Before the agent sees a single tool, decide which tools it is allowed to see. list_scoped_tools returns the tools this creator's connected account is authorized to call, not a flat catalogue. Kit's own scopes cannot make that distinction, so this is where the narrowing happens.
Handing all 81 Kit tools to a model is an accuracy problem before it is a cost problem. At roughly 200 tokens per schema, the full surface burns well over 15,000 tokens before the agent does any work, and the model is choosing from a decision space it was not designed for. Scoping to the five or six tools a list-hygiene agent needs fixes both. The fix is not better prompting. It is surface reduction.
Credentials resolve server-side at call time and never enter the model's context. The response carries an execution_id that ties the call to the audit trail.
actions.langchain.get_tools() returns native StructuredTool objects, so there is no schema reshaping between Scalekit and LangChain. The loop below is the whole thing.
Note what this prompt deliberately does not ask for. It drafts, it does not send. A send would hit Kit's confirmation deep link and the loop would stall waiting on a human.
Signed webhook endpoints, purchase creation, and scheduled sends are not on the MCP surface. When your agent needs them, register the Kit v4 REST API through Add your own connector with your own Kit OAuth app, then call it through Tool Proxy with custom tools. The same connected accounts, the same vault, and the same audit trail cover both surfaces, so a single agent can draft over MCP and dispatch over REST without two auth stacks.
Kit's MCP exposes everything the creator can do, including unsubscribe, bulk_delete_tags, and delete_sequence. Kit's OAuth scopes cannot narrow that. Virtual MCP servers are where the narrowing actually happens.
You declare which connections and which tools an agent role can see, once, and get back a static mcp_server_url. Not once per user.
Four tools instead of 81. Nothing that unsubscribes, nothing that deletes, nothing that sends.
Check the creator's connections are still active, then mint a short-lived token bound to that creator. One server definition, per-user credential isolation.
Mastra's MCP client reads tools and schemas from the endpoint, so there is no Zod conversion to maintain. Pass the current creator's token, never a process-wide one.
Install with npm install @scalekit-sdk/node @mastra/core @mastra/mcp @ai-sdk/openai. The same pattern works with LangChain, Google ADK, CrewAI, and the Anthropic SDK.
Kit gives you a read scope and a write scope. A Virtual MCP server gives you a tool allowlist, which is the granularity Kit's OAuth layer does not offer. For a multi-tenant product that is the difference between an agent that could unsubscribe a customer's entire list and one that structurally cannot.
It also closes the audit gap. Kit does not log MCP actions, but Scalekit records who authorized the connection, which agent ran, which tool it called, and what came back, with 90 days of retention and export to your SIEM. When a customer asks who tagged 8,000 subscribers, that query has an answer.
Recommended reading: Access Control for Multi-Tenant AI Agents and Audit Trails for Agent Auth in B2B SaaS.
If a creator is present and the agent's job is to analyse, segment, and draft, build against the MCP. Kit maintains the tools, the confirmation wall is a feature rather than an obstacle, and 120 requests per minute is more headroom than a conversation will ever use.
If the agent runs on a schedule, needs to dispatch rather than draft, listens for signed webhook events, or imports purchase data, build against the v4 API with OAuth. The confirmation deep link and the missing endpoints are architectural facts, not configuration you can toggle.
Does your agent need to complete a destructive or sending action while nobody is watching? If yes, the API is the only viable path. If no, the MCP is on the table and it is the faster one.
Most production Kit agents end up running both: MCP for the interactive surface, REST for the scheduled jobs. That is a reasonable place to land. What does not change across either half is the credential problem, and that is the part worth building on infrastructure rather than rebuilding twice. For a deeper look at secure token management for AI agents at scale, the patterns apply directly to multi-tenant Kit deployments.
Understanding agent tool calling auth patterns is also worth reviewing before you commit to an architecture — production failures tend to cluster around the same handful of anti-patterns regardless of which connector you use.
Browse the Scalekit Kit MCP connector, read the connector docs, or start from a working agent template. Pricing is on the AgentKit pricing page, and the full catalogue is at all connectors.
Building a Kit agent and want a second pair of eyes on the auth model? Join the Scalekit community on Slack, or talk to an engineer for help scoping a multi-tenant deployment.
