Composio vs Smithery (2026)

Each session gives an agent tools from more than 1,500 toolkits, scoped to one of the customer's users, and Composio manages the OAuth redirects, token exchange and refresh behind them. The agent can pause in the middle of a chat, send the user a Connect Link and retry the tool once the account is connected, and the connected account persists for later sessions. Tools run on the server with the credential injected, never handed to the model.

Sourcedocs.composio.dev/docs/how-composio-worksread 2026-09-22

Through the Smithery Connect REST API, an agent gets authenticated access to MCP servers. Smithery maintains OAuth apps for popular integrations, refreshes tokens automatically and stores credentials encrypted and write only. The agent lists and calls tools on each connection, whether the server comes from the registry of thousands of published servers or from any custom MCP URL. Most listed servers are published by third parties, while the connection, auth and credential layer is Smithery's own.

Sourcesmithery.ai/docs/use/connectread 2026-09-22

The sandbox is a persistent Python environment where the agent writes code that calls tools programmatically, with helpers for tool execution, LLM calls, file uploads, direct API calls and web search, error correction on generated code, and state that persists across calls, and a MULTI_EXECUTE meta tool runs several tool calls together. There is no workflow definition, versioned flow, or sequencing and branching that combine deterministic workflow nodes with autonomous agent steps.

Sourcedocs.composio.dev/docs/sandbox/remoteread 2026-09-22

Sequencing, branching and retries live in the customer's own client or framework, such as the Vercel AI SDK that Smithery's guide uses. Smithery connects an agent to MCP servers and relays the tool calls it makes. It does not run the agent and names no workflow runtime of its own.

Sourcesmithery.ai/docs/use/connectread 2026-09-22

Triggers react to events in connected apps and deliver them to the customer's webhook as structured payloads. A trigger can be activated for a user, events arrive through an SDK subscription or in production, and trigger instances can be listed, enabled, disabled and deleted. A worked example runs an agent when an email arrives.

Sourcedocs.composio.dev/docs/triggersread 2026-09-22

Triggers, in preview, let an MCP server surface events from its upstream service. The customer lists a connection's trigger types and subscribes through the Connect API with its own webhook URL and signing secret. When the upstream event fires, the server posts it straight to the customer's endpoint, so work starts without a person asking. Smithery warns that breaking changes are possible while triggers are in preview, and a trigger exists only where the server's publisher implements it.

Sourcesmithery.ai/docs/build/triggersread 2026-09-22

There is no retrieval structure Composio maintains over the customer's own documents. Its search finds the right tools for a task, and its sandbox can extract text from files an agent is working on.

Sourcedocs.composio.dev/docs/how-composio-worksread 2026-09-22

Semantic search runs over the public registry of servers and skills, not over the customer's own content. Servers that reach a customer's documents connect the agent to those systems, with no index of Smithery's own. Smithery names no ingestion, indexing, retrieval or RAG layer.

Sourcesmithery.ai/docs/indexread 2026-09-22

A Composio session scopes execution state for the run, covering logs, tool memory, MCP state and sandbox files, with sandbox variables and runtime state persisting across calls and cleared after roughly 12 hours of inactivity, and sessions can be reused, updated and deleted. The scope (the session and its user) and the lifetime are stated. This is state carried through one task, and there is no memory layer the agent draws on across runs.

Sourcedocs.composio.dev/docs/security/data-retentionread 2026-09-22

Connections, their credentials and their MCP sessions stay alive for the customer, and Smithery says it is stateless for the customer's application. Smithery names no memory layer that keeps an agent's context across runs. Memory servers in the registry are other publishers' products.

Sourcesmithery.ai/docs/use/connectread 2026-09-22

The customer limits what an agent may do. It chooses which toolkits, tools and tags a session exposes, project API keys keep session management and tool execution as separate permissions with an IP allowlist for each key, the scopes on each connected account limit each user's reach, and the agent pauses for the user to connect an account before a tool runs. There is no step where a person reviews, approves or validates an agent action before it commits.

Sourcedocs.composio.dev/docs/security/overviewread 2026-09-22

A connection stays in an auth_required or input_required state, and its tools are not called, until the user completes OAuth or supplies the missing configuration. Service tokens, from the Token Scoping feature in preview, limit an agent to named namespaces, resources and operations, such as read without execute. They are matched to a user's metadata and expire on a TTL. Smithery names no step where a person approves a specific agent action before it commits.

Sourcesmithery.ai/docs/use/token-scopingread 2026-09-22

SOC 2 Type II compliance is stated, with the report and sub processor list in the Trust Center at trust.composio.dev. Access controls are specific, with organization and project isolation, scoped project API keys that keep session management apart from tool execution with an IP allowlist for each key, MFA an organization admin can enforce, credentials encrypted at rest with AES-256-GCM and redacted by default in API responses, and signed webhook deliveries. Enterprise adds SAML or OIDC SSO with SCIM provisioning and customer managed keys.

Sourcedocs.composio.dev/docs/security/overviewread 2026-09-22

Credentials are stored encrypted and write only, so they can be used but never read back. Organizations issue team API keys that only an admin role can create, list or revoke, and namespace ownership gates writes to servers and connections. Browser or mobile clients get short lived service tokens instead of the API key. No attestation or certification is published. Smithery offers documentation, a privacy policy and a status page, but no trust center, and it names no SSO or audit trail.

Sourcesmithery.ai/docs/use/connectread 2026-09-22

Every tool execution and trigger event is logged with the toolkit and action, status, connection and auth-config IDs, the supplied user ID, timing and source, and by default the request arguments and response data, kept for up to one year. A Logs API and both SDKs offer search filtered by user, tool and status, cursor pagination and retrieval of single records, and Composio explains how to pull those records into a SIEM or observability platform.

Sourcedocs.composio.dev/docs/poc-to-prod/stream-logs-to-a-siemread 2026-09-22

Activity is recorded on the server side. A publisher gets analytics on the tool calls made to its server, runtime logs grouped by invocation and release pipeline logs through the API. For a customer connecting an agent through Connect, Smithery names no step by step record of that agent's session, and no audit log, export or retention by plan.

Sourcesmithery.ai/docs/api-reference/servers/list-runtime-logsread 2026-09-22

Customers choose among four deployment options, each with its own credential boundary. Besides Composio Cloud there is a private VPC deployment inside the customer's network boundary, a self hosted deployment in the customer's environment with Helm support, and a deployment with customer managed keys, where a proxy in the customer's cloud holds credential plaintext under keys in its own KMS (AWS KMS, Google Cloud KMS or HashiCorp Vault Transit).

Sourcedocs.composio.dev/docs/security/token-custodyread 2026-09-22

Tools can run where the customer chooses. Smithery hosts uploaded servers and proxies servers the customer hosts elsewhere by URL. The CLI or an MCPB bundle adds servers straight into a local client such as Claude Desktop or Cursor, so they run on the user's machine. Uplink exposes a server running locally as a Smithery connection without deploying it. No region selection is published for Smithery's own connection and credential service.

Sourcesmithery.ai/docs/use/uplinkread 2026-09-22

There is no agent or workflow a customer adopts whole. Composio ships toolkits and meta tools that let an agent find and run actions, plus examples showing how to build applications, but a tool catalog is a set of integrations, not ready made workflows, templates or agents for particular roles.

Sourcedocs.composio.dev/docs/how-composio-worksread 2026-09-22

The Skills Registry, which Smithery runs, holds reusable prompt based skills that can be searched by text and semantic query and browsed as a catalog. One CLI command, smithery skill add, adds a skill to an agent such as Claude Code, so a customer adopts a ready made workflow instead of writing it.

Sourcesmithery.ai/docs/concepts/cliread 2026-09-22

The agent and its model stay entirely the customer's. Composio never proxies the customer's LLM or runs an agent on its behalf, and its provider adapters serve tools to whatever framework and model the customer runs, so the model is the customer's choice throughout.

Sourcedocs.composio.dev/docs/sandbox/remoteread 2026-09-22

Whatever model and client the customer runs can use the tools. Smithery connections plug into any MCP client, the Vercel AI SDK and the MCP TypeScript SDK. The customer chooses the model and supplies its key, and Smithery names no model of its own.

Sourcesmithery.ai/docs/integrations/vercel_ai_sdkread 2026-09-22

Developers get Python and TypeScript SDKs, a CLI, a current REST API (v3.1) with a published reference, provider adapters for the major agent frameworks, sessions exposed over MCP, single-toolkit MCP servers and an agent skill for wiring Composio into a coding agent.

Sourcedocs.composio.dev/llms.txtread 2026-09-22

A REST API at api.smithery.ai, with a published OpenAPI specification, covers servers, releases, connections, tools, triggers, skills, namespaces and tokens. A TypeScript SDK and a CLI sit alongside it. Smithery serves MCP as addressed endpoints for every connection, and publishers ship their own servers by URL, uploaded module or MCPB bundle.

Sourcesmithery.ai/docs/use/connectread 2026-09-22

There is no evaluation harness, scored test cases, quality gate or optimization loop after deployment for the customer's agent. Composio's guidance covers building, authenticating and running tools, with advice on production readiness and rate limits, but no gate or debugging path for agent behavior.

Sourcedocs.composio.dev/llms.txtread 2026-09-22

When a server is published, Smithery scans it to extract its tools and metadata, shows a security status and runs a release pipeline with logs. These checks cover the server, not the customer's agent. Smithery names no way to test an agent against fixtures or datasets, score its output or gate a release on quality.

Sourcesmithery.ai/docs/build/publishread 2026-09-22

Composio drives no browser, desktop or remote computer session for an agent. It acts through authenticated APIs, and its sandbox runs code, which is code execution, not computer use. It has no headless fetch or browser engine of its own.

Sourcedocs.composio.dev/docs/sandbox/remoteread 2026-09-22

Agents can control browsers through Smithery by using the Browserbase server, which another company publishes in the registry. The capability and its documentation belong to that publisher. Smithery names no browser, desktop or computer control of its own.

Sourcesmithery.ai/docs/indexread 2026-09-22