Your agent needs to build on Replit. Replit ships an official remote MCP server that turns prompts into deployed apps, and it also documents an Admin API. It is tempting to treat these as the familiar "high-level MCP wrapper over a full REST API" pairing and pick accordingly. For Replit, that instinct is wrong. The two surfaces solve different problems, and only one of them can actually build an app. Here is how to choose, and what your production auth looks like either way.
These are two distinct objects with almost no capability overlap. Read this section as a definition of scope, not a feature list, because the scopes are the whole story for Replit.
Replit's official MCP server documentation describes a hosted, remote server that lets any compatible client create, find, inspect, update, and publish Replit Apps. The direct endpoint is https://replit-mcp.com/server/mcp, the transport is Streamable HTTP, and authentication is OAuth using protected-resource metadata discovery.
The build work is done by Replit Agent behind the tools. The server exposes eight tools: create_app_from_prompt, update_app_using_prompt, publish_app, get_publish_status, list_apps, search_apps, resolve_app_by_name, and ask_question. Access is scoped to apps the authenticated user can edit, including apps shared with them.
Replit's only officially documented HTTP API is the Enterprise Admin API, currently in beta. It gives Enterprise account admins scope-based access to account analytics and administration, authenticated with a bearer key that begins with rpl_.
Its scopes are governance-oriented and mostly read: usage and cost, workspaces, members, and projects are read scopes; the only write scope is budgets. The Projects scope lists and searches projects across Team Workspaces; it cannot create, change, or publish them. This is a reporting and operations API, not a build API.
For GitHub or Notion, the MCP server is a convenience layer over a large REST API, so the decision is about ergonomics and auth. Replit inverts that. The MCP server is the primary programmatic interface for building apps, and no documented REST API mirrors it. The choice is less "which path to the same capability" and more "which capability domain you are in." For a broader look at how MCP and APIs fundamentally differ, the structural contrast is worth understanding before picking a path.
The comparison below fixes on the questions a production agent forces you to answer: what it can do, how it authenticates, and what you own when it runs. Keep the domain split in mind as you read each dimension.
The capability gap is not a matter of a few missing endpoints; the two surfaces barely intersect. The table uses plain values rather than symbols so the scope boundaries stay unambiguous.
The last two rows matter for expectation-setting. Community Replit MCP servers expose file and secret operations; the official server does not. Build the mental model from the official surface, not from a community fork.
Every create, update, and publish action is an asynchronous Agent job. Your agent starts the work, gets an acknowledgement, and then checks back; it does not receive a finished result inline.
That changes your control flow. A create_app_from_prompt call requires an appDescription and an app_stack (for example react_website, mobile_app, or data_visualization), and returns while Agent keeps building. To know when an app is live, the agent calls get_publish_status and reads the public URL. Design the loop around polling and idempotent retries, not around a single blocking request.
The two paths do not just use different tokens; they hold credentials at different granularities. That distinction drives everything downstream in a multi-tenant product. Understanding credential ownership across agent tool-calling patterns is essential before committing to either path.
Replit is explicit that clients should not run a custom OAuth server for MCP: the server publishes the protected-resource metadata the client needs. For a multi-tenant B2B agent, that yields one connected account per user, which is the correct model for acting on each user's behalf. The Admin API points the other way: a single high-privilege key represents the whole account, which is convenient and centralizes risk in one credential.
MCP being hosted removes real work; it does not remove the parts that break at scale. Be precise about the line between what Replit runs and what you run.
On the MCP path, Replit owns the server, the tool schemas, and the Agent runtime. You own the per-user OAuth tokens: encrypted at rest, isolated per tenant, refreshed before expiry, revocable on offboarding. You also absorb tool-schema drift when Replit updates the server, since MCP tool contracts are not versioned like a REST API.
On the Admin API path, you own custody of a powerful account key and the discipline to keep it read-only where possible. It has no build capability, so it is never the answer for shipping apps, only for governing them.
The split is unusually clean here because the surfaces do different jobs. Match the path to the job rather than to a preference for MCP or REST.
Use the Replit MCP server when:
Use the Replit Admin API when:
Neither path hands you production-grade credential management; they hand you a credential and a problem. The problem simply takes a different shape on each path, and both shapes are infrastructure, not application logic.
The MCP path gives you a token per user. In a multi-tenant agent that is N tokens to store, isolate per tenant, refresh before they expire, and revoke on offboarding.
None of that is provided by the OAuth flow itself. A "redirect and store the token" approach works in demos and does not survive production scale, because refresh races and silent expiry surface only once real users are connected continuously. The operational burden of secure token management for AI agents at scale is real and compounds quickly as user count grows.
The Admin API path has the opposite failure mode. One rpl_ key can represent the entire account, so a leak is not a single user's exposure; it is the account's.
Least privilege is the mitigation: mint read-only keys where you can, and never let a write-capable key sit in agent runtime. The credential management burden is still yours; it just concentrates instead of multiplying.
Scalekit's Replit MCP connector handles the OAuth flow, encrypted token storage, and automatic refresh for the per-user path, and it keeps credentials out of your agent runtime. The MCP-versus-API decision then stops dictating your auth architecture, because the connected-account model is the same regardless of which Replit surface you call.
This section shows the per-user MCP path end to end in Python, using the Claude SDK for the agent loop. The sequence is always the same: connect the user's account, retrieve the tools that account is authorized to call, then execute. One prerequisite matters more than any other: the connection name in your code must match the connection configured in the Scalekit dashboard exactly.
A connected account is the record that holds a user's Replit credentials. You create or fetch it, and if it is not yet ACTIVE, you send the user through authorization once.
In production, redirect the user to the authorization link and resume after the OAuth callback rather than blocking on input().
list_scoped_tools returns the tools this specific connected account is authorized to call, not a flat catalog. This is the list you pass to the model, and it is why the agent sees only what the user's Replit account permits.
The loop sends the scoped tools to the model, executes each requested tool through Scalekit, and feeds results back until the model stops asking for tools. Because Replit builds are asynchronous, a realistic agent will call get_publish_status (via replitmcp_get_publish_status) on a later turn to read the live URL.
If you already build with LangChain, Scalekit returns native tool objects with no schema reshaping. The scoping and execution semantics are identical; the connection name still has to match the dashboard. For a deeper look at how LangChain tool calling works and where it stops, the tradeoffs are worth reviewing before picking your integration pattern.
Full setup, connection configuration, and other frameworks are covered in the Scalekit tool calling docs and the AgentKit quickstart.
Because the MCP server is the only real build surface for Replit, the production question is not "MCP or API"; it is "how do I run the MCP path safely for many users." That is exactly where Scalekit's connected-account model earns its place.
Handing an agent every tool a connector exposes degrades tool selection and burns tokens before any work happens. list_scoped_tools returns only the tools the current user's connected account is authorized to call, so the surface shrinks to what is relevant for this user and this task. Scope is a function of identity: what the user cannot do, the agent cannot do. Surface reduction is the lever here; a bigger model on a bloated tool surface still underperforms a correctly scoped one. This aligns directly with the access control principles for multi-tenant AI agents that prevent privilege creep across tenants.
When an agent creates or publishes an app on a user's behalf, you need a record of what ran and under whose credentials. Scalekit records each tool execution against a connected account, giving you a per-user audit trail rather than an opaque Agent action. That is the difference between answering a security review and guessing. The reasoning behind treating this as first-class is covered in agent tool observability and the auth logs overview.
Most real Replit agents do more than build; they read a spec from another tool, build the app, then post the URL somewhere. A Virtual MCP server gives that agent one scoped endpoint that declares exactly which tools and connections it can see, with per-user isolation handled by short-lived session tokens. One server definition serves all users; each run receives a token scoped to that user's connected accounts. There is no MCP server for you to deploy, host, or maintain.
If your agent builds, updates, or ships Replit Apps for a user, build against the Replit MCP server; it is the only officially documented surface that can. If your agent reports on or governs an Enterprise account, use the Admin API, and keep it read-only wherever you can. The two are not substitutes, so most teams that build with Replit will live on the MCP path and reach for the Admin API only for governance. Either way, the credential lifecycle is the part that decides whether it survives production, and that is infrastructure worth solving once. This is why understanding how tool calling auth changes when you move from single-tenant to multi-tenant matters before you scale.
Pick the surface that matches your agent's job, then let Scalekit own the auth.
Start with the Scalekit Replit MCP connector docs, browse the full connectors directory and the connectors overview, and compare plans on the pricing page. If you are shaping a broader build-and-ship workflow, the DevOps assistant agent and auto release notes agent templates are useful starting points.
Building a Replit agent and want a second set of eyes? Join the Scalekit Slack community, or use the Talk to us page for immediate help.
