Your agent needs to hand engineering work to Devin: open a session from a task, follow its progress, review the pull request, keep its knowledge base current. Devin gives you two ways in, an official MCP server and a REST API, and they are not the same surface. The usual assumption that MCP means browser OAuth and the API means keys does not hold here; both paths authenticate identically. What actually differs is how much of Devin you can reach and how much control you get over each call. Here is how to pick.
These are two access surfaces over the same Devin platform, maintained by Cognition. You have almost certainly called the REST API pattern before. The MCP server is the piece worth establishing first, because it behaves differently from the MCP servers of most other tools.
The Devin MCP server is Cognition's official, authenticated Model Context Protocol implementation. Its base URL is https://mcp.devin.ai/, and it speaks Streamable HTTP at the /mcp endpoint; the legacy /sse endpoint is deprecated. It gives any MCP-compatible agent or IDE programmatic access to Devin sessions, playbooks, knowledge, schedules, integrations, and repository documentation. Authentication is a Devin API key in the Authorization: Bearer header. Full setup lives in Devin's official MCP server documentation.
The Devin REST API is a versioned HTTP interface, currently on v3, split into an Organization scope at https://api.devin.ai/v3/organizations/* and an Enterprise scope at https://api.devin.ai/v3/enterprise/*. The Organization scope covers sessions, playbooks, knowledge, and more; the Enterprise scope covers cross-organization analytics, audit logs, user management, and billing. Both scopes use the same cog_ service user credentials. OpenAPI specs are published for client generation. Details are in Devin's REST API reference.
It is easy to conflate the two, so it is worth naming a third object. DeepWiki MCP (https://mcp.deepwiki.com/) is a separate, no-auth server that exposes only three tools (ask_question, read_wiki_structure, read_wiki_contents) for public repositories. The Devin MCP server is the authenticated superset: public and private repositories plus full platform management. If your agent only reads public repo docs, DeepWiki MCP is the lighter option; everything else in this article concerns the authenticated Devin MCP server and the REST API.
The comparison runs across four dimensions: what your agent can do, the auth path each one puts you on, what you own in production, and when each one wins. The headline for Devin is unusual, so keep it in mind through all four: the auth model is identical on both paths, which pushes the real decision onto capability and control.
Both surfaces cover the interactive core of driving Devin. The gaps appear at the edges: the MCP server adds agent ergonomics the API leaves to you, and the API adds administrative and per-user control the MCP toolset does not expose.
Two rows above are worth calling out because they are genuine agent-time conveniences. devin_session_gather waits for multiple sessions to reach a settled state, which removes the polling loop you would otherwise write around parallel sessions. ask_question runs a context-grounded query across up to ten repositories in a single tool call. And the whole toolset arrives as typed, model-ready schemas; the agent connects and gets a working tool list without you translating REST endpoints into tool definitions.
The API is the surface for control the tools do not express. Session attribution is the clearest case: with create_as_user_id, a service user can create sessions on behalf of any user, so the session appears in that person's list and counts toward their usage. That call requires the ImpersonateOrgSessions permission, which only exists because the API is built around RBAC-scoped service users. The Enterprise scope adds audit logs, analytics, billing, user management, and IP access lists. None of that is reachable through the MCP toolset.
Here is the part that makes Devin different from GitHub, Slack, or Notion in this series. There is no OAuth consent screen and no separate MCP credential type. The MCP server accepts the same tokens as the REST API, so choosing MCP does not change how your agent authenticates.
Devin distinguishes tokens by principal, not by path. A service user key authenticates as a non-human account with its own RBAC role and org memberships; a personal access token authenticates as the human who created it. Both start with cog_.
Because the transport auth is identical, the meaningful choice is which principal your agent acts as, not which surface it calls. For a background agent, a service user key with a least-privilege RBAC role is the correct default; it is revocable independently of any human and scoped to exactly the endpoints it needs. For an agent acting as one specific engineer, a personal access token attributes work to that person automatically. This is an identity decision, and it is the same decision whether you go through MCP or the API.
With either path, Cognition runs the server and the model; you own everything around the credential and the calls. That split is where the operational cost actually sits, and it is identical on both surfaces.
With the MCP server, Cognition maintains the tool schemas and the endpoint behind them. You still own key storage, the X-Org-Id header for enterprise keys and PATs, and adapting when the tool surface shifts as Devin ships new capabilities. That surface is expanding: Cognition's docs enumerate a core toolset across sessions, playbooks, knowledge, schedules, integrations, and repo docs, while newer capabilities such as Devin Review, Oncall, and code scanning are appearing as additional tools.
With the REST API, you own request construction, pagination, retries, error handling, and the full lifecycle of the cog_ credential. The tradeoff is stability: endpoints are versioned, v1 and v2 remain during their deprecation window, and OpenAPI specs let you generate typed clients. For a deterministic pipeline that calls the same handful of endpoints on a schedule, that versioned contract is worth more than tool ergonomics.
Both paths are legitimate; the split follows the shape of your agent. Reach for the MCP server when the agent is interactive and you want ergonomics over fine-grained control:
Reach for the REST API when the agent needs control, attribution, or administration rather than editor-side convenience:
The auth model being shared removes one distraction and exposes the real problem underneath. Whether your agent calls the MCP server or the REST API, it authenticates with a Devin credential, and in a multi-tenant product there is never just one.
A single-tenant script can hard-code one cog_ key. A B2B agent cannot. Each customer, and often each user, acts under their own Devin identity, which means N credentials to store encrypted, isolate per tenant, refresh, and revoke when someone offboards or churns. The MCP server and the REST API both hand you a credential per principal; neither gives you a vault, a rotation routine, or a revocation flow. That is infrastructure you own regardless of the path.
Scalekit's Devin connector handles the credential side for both surfaces: it stores the Devin key in a token vault, scopes the tool surface to the connected account behind an identifier, and keeps credentials out of the agent runtime. The MCP vs API decision stays a capability decision, not an auth-infrastructure decision.
Scalekit ships one Devin connector rather than separate MCP and API connectors: devinmcp, a vendor MCP connector that surfaces Devin's tools with your Devin API key vaulted and injected per request. The walkthrough below is Python with the Claude SDK; the same connected-account pattern works in TypeScript with @scalekit-sdk/node and with LangChain, Google ADK, and CrewAI.
You need a Scalekit account with a Devin connection created under AgentKit, its connection name (devinmcp), and your SCALEKIT_ENVIRONMENT_URL, SCALEKIT_CLIENT_ID, and SCALEKIT_CLIENT_SECRET. You also need a Devin service user key and an Anthropic API key. Install the dependencies:
The connection name is case-sensitive and must match the dashboard exactly. A mismatch is the most common reason a scoped tool list comes back empty. Setup steps are in the Scalekit Devin MCP connector docs.
Devin uses API-key authentication, so there is no OAuth redirect to run. You connect a user by vaulting their Devin service user key against an identifier from your own authenticated session. Do this once per user, typically when they link Devin on a settings page.
Before the agent runs, load its tools. The important part is what list_scoped_tools does: it returns only the tools the current user's connected account is authorized to call, already bound to that identifier. The agent is not loading a flat connector catalog; it is loading this user's authorized surface.
The Scalekit Python SDK returns protobuf objects, which is why MessageToDict converts each tool into the plain dict the Anthropic SDK expects. The result is Anthropic's native tool format; you pass it straight to messages.create().
With the scoped tools in hand, the loop is the standard Anthropic pattern. Claude decides which tool to call, your code executes it through Scalekit with the user's identifier, and the result goes back to Claude until it produces a final answer. Devin's tools arrive prefixed, so Claude will call names like devinmcp_devin_session_create.
execute_tool passes the tool name, the connection, the user identifier, and the inputs to Scalekit, which calls Devin using the vaulted key for that user. The token never enters your agent code or the model context. Wrapping the call in try/except feeds any error back to Claude, which usually corrects itself on the next turn.
The scoping is not cosmetic. LLMs select tools poorly when handed a large catalog, and every tool in context costs tokens before the agent does any work. Loading only the tools a given user is authorized to call shrinks the decision space and the token overhead at the same time. The fix for tool-calling accuracy here is surface reduction, not better prompting; a stronger model on a bloated tool surface still underperforms a correctly scoped one.
Two Scalekit capabilities matter specifically once a Devin agent leaves a single developer's machine and starts acting for many users. Both address problems the raw MCP server and REST API leave to you.
When Devin opens sessions, edits knowledge, or triggers reviews on behalf of your users, you need to answer who did what, as whom, and when. Scalekit records every downstream tool call as a queryable event, so the agent's actions against Devin are auditable from one place rather than reconstructed from scattered application logs. That record is what a security review asks for, and it connects directly to the broader topic of audit trails for agent auth in B2B SaaS.
A standard MCP server exposes every tool it has. A Devin agent that only creates sessions and reads reviews does not need the full surface for every user. Virtual MCP Servers let you declare exactly which tools an agent role can see and whose credentials it acts with, from a single server definition, with no MCP server to deploy or host. One definition serves all users; before each run, a short-lived session token is minted scoped to that user's connected accounts. The endpoint is static; the identity is per-user.
The same per-user, scoped-tool pattern applies across a wide range of coding workflows. It generalizes cleanly to Devin agents that span multiple tools — for example an engineering standup agent or an auto release notes agent that delegates work to Devin and reports back. The DevOps assistant agent for GitHub, Linear, and Slack shows the same pattern across a full coding workflow.
The decision is unusually clean for Devin because the auth model is off the table. What is left is capability and control, and those map directly to the shape of your agent.
If your agent is interactive and lives in an editor, delegating tasks and reading repo context, build against the MCP server. If your agent is a deterministic pipeline, needs per-user attribution, or touches enterprise administration, build against the REST API. Many production systems use both: the MCP surface for the interactive loop, the API for orchestration and governance.
Whichever surface you choose, you are holding one Devin credential per user or service identity, and that is what needs production-grade storage, scoping, and revocation. Solve it at the infrastructure layer and the MCP vs API question becomes a design choice rather than a rewrite. The challenge of moving from single-tenant to multi-tenant tool calling is exactly where credential management becomes the critical investment.
Browse the Scalekit Devin connector and its full tool library, or read the Devin MCP connector docs to wire it up. See how the connector fits the wider platform on the AgentKit page and the connector catalog, and check pricing when you are ready to scale.
Building a Devin agent and want a second set of eyes on the auth model? Join the Scalekit community on Slack, or talk to us for immediate help.
