Composio MCP Gateway: Inside a Managed Tool-Router

Short answer: A Composio-style MCP gateway is a vendor-hosted tool-router: it keeps the connection to each third-party app, holds and refreshes the credential, and authorizes each call as a specific one of your users, then exposes the whole thing to an agent as one MCP endpoint. Adopting it removes a large block of per-app work — registering OAuth apps, storing and rotating tokens, packaging tool schemas, tracking which user connected which account — and in exchange the tool catalog, the credential custody and much of the access decision live with the vendor. This page describes that shape precisely: the parts you stop writing, the parts that move, and the questions to ask before the split is the wrong one for a given team.

Key takeaways

• A managed tool-router is defined by three things it hosts for you — the app connection, the credential, and the per-user authorization decision — not by the number of apps it lists.
• The developer work it deletes is concrete: one OAuth app registration and token store per integration, refresh and revocation handling, tool-schema packaging, and per-user connection bookkeeping.
• The control it takes is equally concrete: credential custody, the version of each tool's definition, the identity and authorization model, and the tool-call telemetry that records who reached which action.
• The self-hosted route (an open-source gateway you run) keeps custody of credentials and the record, and leaves the OAuth registration, token lifecycle and per-user store as your work.
• Decide by asking where the credential is allowed to live and who must be able to read the audit row; those two answers pick the shape before any feature comparison does.

---

composio mcp gateway: what a managed tool-router actually owns

The phrase names a specific architecture rather than a product tier. In a managed tool-router the agent never holds the app credential and never speaks to the app directly; it speaks to one endpoint that represents one user, and that endpoint does the discovery, the authentication and the execution on the agent's behalf. Composio's own session model is the clearest public description of the pattern: the entry point is a session scoped to a user you name (composio.create(user_id=...)), the session exposes a hosted MCP URL plus the headers needed to reach it, and the developer connects a generic MCP client to that URL rather than wiring each app. The official documentation states this directly — a session "handles tool discovery, authentication, context, and versioning" for the agent, and connections are stored under the user identifier you supply. Read the current contract at docs.composio.dev/docs/how-composio-works.

Three objects are being hosted for you, and naming them is the whole point of this page. The first is the connection: the OAuth grant or service account between a user and one app. The second is the credential: the access and refresh tokens that grant continues to produce, kept in the vendor's store and refreshed on your behalf. The third is the authorization decision: which of your users may reach which tool, expressed per user rather than per API key. A product that does only the first is a connector library; a product that does all three is a tool-router, and that is the difference the rest of this page is about. The general category it belongs to — the layer between agents and MCP servers — is defined on what an MCP gateway is; here the subject is the managed variant of it.

The reason this matters to a developer is arithmetic, not taste. Connecting an agent to ten business apps the manual way is ten OAuth applications to register, ten token stores to build, ten refresh jobs to monitor, ten schema packages to version, and one per-user table that ties a person to an account in each of the ten. A managed tool-router collapses those ten parallel problems into one integration with the router, and that is the trade it is selling.

llm gateway open source: the self-hosted route and what it leaves with you

The opposite pole is a gateway you run yourself, and the open-source projects in this space are the honest way to see what the managed route is doing for you — because the self-hosted route makes you do it. When you operate your own gateway, the credential does not leave your boundary: you hold the OAuth client secret, you run the refresh, you own the store that maps a user to a connected account, and the audit row that records a tool call is a row in your database. None of that is free. It is the same block of work the managed router deletes, now maintained by your team against every API's own auth quirks — a scope change here, a token-format change there, a deprecation notice you have to act on.

The trade is exact and it cuts both ways. Self-hosting gives you custody: the token, the record and the tool catalog are yours, and a compliance requirement that says the credential may not live with a third party is satisfied by construction. It also gives you the maintenance: the per-app auth surface is now your code, and its failures are your pages. A managed router inverts both halves — someone else maintains the auth surface, and someone else holds the credential. Neither half is "better" in the abstract; they answer different constraints, and the constraints are the ones to write down first. The open-source MCP gateway shape, including how a self-run gateway handles upstream credentials, is worked through on LiteLLM's MCP gateway; this page stays on the managed side of the line so the two can be compared cleanly.

ai agent gateway: where the hosted tool layer sits in the stack

Place the managed router correctly and the rest of the architecture follows. It sits between the agent and the MCP servers, not between the agent and the model. The model call — prompt, completion, token budget — is a different concern from the tool call, and conflating them is how teams end up with two products doing one job. What the tool-router owns is the tool call: it turns a request from the agent into an authenticated request against the right app, as the right user, and returns the result. What it does not own is what the model costs, how the prompt is assembled, or how the agent decides to call the tool at all.

Two design questions separate the hosted layer from a thin proxy, and both are worth asking of any managed router. The first is discovery versus a fixed list: does the agent receive every tool the connection permits, or does it receive a search-and-invoke surface that pulls only the relevant few into context on demand? Composio's documentation describes a session that "keeps the agent's context lean" through discovery meta-tools, with an explicit option to pin a fixed tool list instead — and the choice matters, because a fixed list is reproducible and a discovery surface is smaller but adds a step the agent can get wrong. The second is scope granularity: is the unit of permission the whole app, or a single action inside it? Granting "Gmail" and granting "read messages, never send" are different security postures, and a router that can only express the first has quietly widened every grant you give it.

The pattern of a control layer in front of many downstream tools is not new; what is new is that the layer now speaks MCP and can host the credential. That is the same slot occupied by a self-hosted gateway in a team that has chosen to own the plumbing, and reading the two against each other is the point of this cluster.

ai gateway azure: the managed-cloud instance of the same shape

"Managed" is a spectrum, and the cloud vendors sit on it differently from an application-layer router. When Azure or another hyperscaler hosts the gateway, the custody question changes character: the credential may stay inside a boundary your organisation already trusts, and the authorization model may be the cloud's own identity plane (directory groups, role assignments, managed identities) rather than a vendor-specific user table. For a team already governed by that directory, the appeal is not the tool catalog but the fact that "who may call this action" is answered by the same identities and the same policy engine that answer every other access question — one review process instead of two.

The cost of that fit is weight. A cloud-hosted gateway is reached through the cloud's control plane, which means its setup, its policy model and its quota model are the cloud's, and moving a workload out of that cloud moves the gateway question with it. An application-layer router is lighter to adopt and more portable across clouds, and less aligned with an existing enterprise directory. Neither property is a defect; they are the same custody-versus-fit trade seen from the platform side. What to compare across the two, and where the boundaries actually fall, is the subject of TrueFoundry's gateway on the platform side and of the hyperscaler pages in this cluster; on this page the relevant point is only that "managed" does not have one meaning.

ai sdk gateway: what the SDK surface changes about tool access

How the router is reached determines how much of your code changes to adopt it, and there are two honest interfaces. The provider-package route imports a framework adapter and receives the tools as native objects for that framework, so the agent's tool-handling code is ordinary framework code. The MCP route imports nothing framework-specific: you connect an MCP client to a hosted URL and pass the headers the session exported. Composio's docs draw the line exactly there — a session can be exposed over MCP with no provider package required, or consumed through a framework adapter when you want the tools as objects — and a per-user hosted endpoint is what the MCP route hands you.

Two consequences follow, and they are the ones a developer should weigh. First, the MCP route makes the integration portable: any MCP-speaking client can use it, so the router is not welded to one agent framework. Second, it moves credentials into a header you must treat as a secret — the exported configuration carries the key the SDK used, so where that header lives and who can read it becomes part of your threat model, not an implementation detail. The official MCP guide spells out which exported credential reaches which scope (docs.composio.dev/docs/sessions-via-mcp), and a team adopting the MCP route should read it as a security document, not a quickstart. The same "one endpoint, many tools" surface is what a self-built gateway exposes to its own agents; the difference is again custody, not protocol.

azure mcp gateway: governance when the cloud owns the plumbing

Governance is where the managed split shows up as a line item rather than a preference. A tool router that hosts the connection also hosts the levers a reviewer will eventually ask for: access policy, the audit trail, and the identity lifecycle. Composio's MCP gateway material lists these as the managed offering's distinct features — centralized policy, managed authentication lifecycle, and a unified audit trail keyed to user, team, tool, action and outcome — and pairs them with enterprise identity controls (SAML or OIDC for sign-in, SCIM for provisioning and offboarding). Those are real capabilities and they are the reason a managed router wins in a large organisation: an offboarding that revokes a directory identity also severs the tool connections, which is not true of a hand-rolled per-app token store.

The governance question that does not go away is where the audit row lives. When the router is managed, the definitive record of who called which action is the vendor's; you read it through the vendor's surface, retain it for as long as the vendor retains it, and export it only in the shapes the vendor offers. That may be entirely acceptable — many teams would rather rent a good audit trail than operate a mediocre one — but it must be a decision, not a default. Contrast the self-run side, where the same row is a row you wrote, retained under your own policy, and joined to the rest of your telemetry without an export step. The two cloud-hosted variants of this trade are worked through on AWS MCP gateway and Microsoft's MCP gateway; here it is the pivot of the whole managed-versus-owned comparison.

kong llm gateway: a gateway you run and credential yourself

The run-it-yourself camp is best seen through a gateway whose heritage is the API gateway, because that heritage tells you what such a product is good at. An API gateway has always fronted many upstream services behind one authenticated surface, with per-consumer keys, rate limits and observability — and extending that to MCP and to model traffic is a natural next step for it. What an API gateway does not, by default, do is become the custodian of your users' third-party credentials: that is the application-layer concern the managed router specialises in, and a general gateway will tend to leave it with you or offer it as a thinner add-on. If your gateway is already the place where consumer identity and limits are enforced, adding MCP traffic there keeps one enforcement point rather than two.

That is a genuine advantage and it is also a boundary. A gateway you run keeps the record and the credential inside your perimeter, and it puts the per-app OAuth surface back on your team. A managed tool-router keeps the per-app surface off your team and puts the credential inside the vendor's perimeter. The choice between them is the same choice named in the first two sections, seen through a product whose shape predates the agent era — and its mechanics are worked through on Kong's MCP gateway.

llm api gateway: the request surface a tool-router exposes

Whatever the deployment model, the thing your code actually touches is an API surface, and its shape decides whether the integration is pleasant or fragile. A managed tool-router's surface is small: create a session for a user, receive a URL and a set of headers, call tools through the session, and query connection state. The interesting details are the operational ones. Requests are authenticated with a keyed header rather than a user login, so the header is a secret with a scope — Composio's API reference documents both a project key and an organisation-scoped key, which reach different breadths, and the wider one is the one to avoid pasting into a client (docs.composio.dev/reference). Rate limits are stated as plan-dependent on the vendor's reference; the official documentation does not give a single fixed number, so read the live reference rather than a number quoted on a blog.

Two properties decide whether a surface like this holds up in production. Per-user isolation must be structural: the router should scope a session to one user so that one user's agent cannot reach another user's connected account, which is why the identifier you pass must be stable and must never be a shared default. Header handling must be explicit: the credential the router exports has to be passed to the endpoint unchanged and must not be forwarded to any other origin. Both are stated in the vendor's own documentation, and both are the kind of requirement that is trivially satisfied on day one and quietly broken by the first refactor — which is exactly why the surface deserves a test in your own suite, not just a paragraph in a guide.

Where our MCP gateway keeps the tool catalog, read from the source of truth

This page has described a vendor-hosted tool catalog. This section is the catalog of the gateway that serves this site, and it is written so it can be checked: read on 2026-10-08 from backend/smartgate/api/mcp_tool_docs.py and backend/smartgate/api/mcp_instructions.py.

The catalog is two dictionaries and one instruction string, and they are the single source of truth for the protocol. TOOL_DESCRIPTIONS holds one entry per tool — seven of them — and each entry is written in a fixed five-part shape: purpose, when to use, when not to use, what is returned, and what it composes with. The "when not to use" line is the part most catalogs omit and the part that keeps an agent from reaching a tool for the wrong job; TOOL_TITLES carries the human-facing name beside it. Read-only access is declared the same way: a frozenset of the five tools that neither write nor spend — fetch, search, compression, deduplication and the budget check — feeds the protocol annotation, so a client learns which tools are safe to retry from the catalog rather than from prose.

The second half is what a host receives at initialize: SMARTGATE_MCP_INSTRUCTIONS, a host-neutral English string, states in its own words that the gateway is not a chat-completion service, that tenant scope comes from the bearer key rather than a tool argument, which tool answers which question, the three canonical workflows, the output contract that every tool returns a JSON string, and the anti-patterns the tools exist to prevent. Because the descriptions and the instructions are edited in one place and the documentation is synced from them, the client and the docs cannot drift apart — the catalog a client connects to is the catalog that is actually maintained.

Where SmartGate fits

SmartGate takes the opposite side of the custody split from a managed tool-router, and it is worth being plain about which side. It is an MCP-native algorithm gateway you connect an MCP-speaking client to, and it is not a vendor-hosted custodian of your users' third-party app credentials: it does not register OAuth applications for Gmail or Slack on your behalf, and it does not hold the refresh tokens for them. What it provides is the layer around the calls themselves — research and fetch, context compression and de-duplication, team memory, an enforced budget ceiling, and a pipeline primitive — behind one authenticated endpoint, with the audit row written where you can read it. In the framework this page has used throughout, that makes it a self-run gateway: you keep custody of the record and of your own keys, and you keep the work that custody implies.

For a team that does not want to own per-app credential plumbing, the managed route this page describes is the right shape and SmartGate is not a substitute for it — a tool-router hosts connections and SmartGate hosts algorithms; they solve adjacent problems and can sit next to each other. The operational limits that come with SmartGate move with the plan rather than the session: monthly token caps, requests per minute per key, audit-log retention and team-key counts, with the pricing page as the authoritative table, and a billing model that takes a share only once the platform has saved enough to clear a floor.

How to get started

Decide the shape before you shop for it, then verify the two properties that cannot be retrofitted.

1. Write down where the credential is allowed to live. If the answer is "not with a third party", a managed tool-router is out and the self-hosted route is the only option; if the answer is "wherever it is safely managed", the router is available and the question becomes its audit and identity surface.
2. Count the per-app integrations you would otherwise write. Below a handful, a self-run gateway plus a small token store is a weekend of work; at ten or more, the deleted maintenance is the router's real product.
3. Check the two non-negotiables on any managed router: per-user isolation (one session, one user, no shared default identifier) and an exported credential you can keep out of every origin except the router's own endpoint.
4. Confirm the governance answer explicitly — where the audit row lives, how long it is kept, and how it is exported — against whatever retention obligation you actually carry, rather than against what a product page lists.
5. If your decision is to own the plumbing, start with a self-run gateway, connect an MCP-speaking client to one endpoint, and read the pricing page once your real call volume tells you which tier the traffic needs.

Limitations

This page describes a shape, not a product spec or a ranking. It does not claim that any named platform is more secure, cheaper or better supported than another, and it deliberately quotes no vendor pricing, no free-tier allowance and no supported-integration count: those are operational numbers that change on the vendor's own release cadence, and the authoritative source for each is the vendor's live documentation rather than a third-party summary. Where a figure is not stated here, it is because reading it from the vendor's current page is the only honest way to report it.

The comparison between managed and self-hosted routes is drawn to separate two custody models, not to score them. A team with a regulatory constraint on where a credential may live and a team with no such constraint will reach opposite conclusions from the same table, and both will be right. The mechanics attributed to a managed router are read from public documentation; the failure modes described are the general ones of any hosted credential layer and are not claims about a specific implementation's current quality. The demand figures quoted above are our own paid measurements for the United States over a twelve-month window and are recorded in this project's measurement files; they describe how many people search, and they will age.

Because this page carries no code excerpt — the reason is recorded in the Method note below — it makes no line-numbered or implementation-level claim about any router, including any referenced here.

Sources

• Composio's session documentation — docs.composio.dev/docs/how-composio-works, for the session-scoped-to-a-user model, discovery meta-tools and the runtime connection flow.
• Composio's authentication guide — docs.composio.dev/docs/authentication, for per-user credential storage, the Connect Link flow, and the statement that credentials do not pass through your application or the model.
• Composio's MCP guide — docs.composio.dev/docs/sessions-via-mcp, for the hosted MCP URL, the exported headers, and the difference between the project key and the organisation-scoped key.
• Composio's MCP gateway overview — composio.dev/mcp-gateway, as the vendor's own description of the managed offering, including its identity and audit claims; read as a vendor statement.
• Composio's API reference — docs.composio.dev/reference, for the keyed-header authentication model and the plan-dependent statement of rate limits.
• The Model Context Protocol specification — modelcontextprotocol.io/specification, for the tool-call interface a router exposes to a client.
• NIST's AI Risk Management Framework — nist.gov/itl/ai-risk-management-framework, for the record-keeping and access-control expectations behind the governance section.
• Demand figures for this page are our own measurements: DataForSEO Google Ads, United States, 12-month window, measured 2026-10-03, recorded in this project's search_volume.json and research_brief.md.

Method note

This page carries no code excerpt, and that is a recorded finding rather than an omission. The slice run for this page recorded 0 of 8 sections pinned, 0 abstention(s) and 8 no-slice verdict(s): the matcher found no unique symbol for any section, and its remote fallback returned only scored, non-unique candidates — a generic plan-catalog constant, a generic test entry point and a generic configuration object. A pinned generic would have given the page the shape of a verified article with none of the substance, so every section above is written from public documentation instead.

The mechanics attributed to a managed tool-router were read from the vendor's public documentation at the URLs listed under Sources above; where a specific number was not stated in that documentation, no number is given here, and the page says so rather than importing a figure from a third party. The section keywords quoted above each heading come from this project's own paid measurement run, not from a third-party tool. No code, batch fingerprints, auction data or internal hosts are transcribed, so there is nothing here that has to be asserted verbatim.