Smithery

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, and the agent lists and calls tools on each connection, from the registry of thousands of published servers or any custom MCP URL. Most listed servers are published by third parties, and the connection, auth and credential layer is Smithery's own.

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

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

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

There is no retrieval structure over the customer's own content: Smithery's semantic search runs over the public registry of servers and skills, and servers that reach a customer's documents are routes to those systems rather than an index. No ingestion, indexing, retrieval or RAG layer is documented.

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

What an agent may do is constrained: 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, and service tokens (Token Scoping, in preview) limit an agent to named namespaces, resources and operations such as read without execute, matched to a user's metadata and expiring on a TTL. These are consent and policy constraints; no approval step a person acts on before a specific agent action commits is documented.

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

Access controls are documented: 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; namespace ownership gates server and connection writes; and browser or mobile clients get short-lived service tokens instead of the API key. No attestation or certification is published, and the site footer links documentation, a privacy policy and a status page with no trust center. No SSO or audit trail is documented either.

Sourcesmithery.ai/docs/use/connectread 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. A customer connecting an agent through Connect has no documented step-by-step record of that agent's session, and no audit log, export or retention by plan is described.

Sourcesmithery.ai/docs/api-reference/servers/list-runtime-logsread 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, but no memory layer that keeps an agent's context across runs is documented; memory servers in the registry are other publishers' products.

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

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

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

A Skills Registry run by Smithery holds reusable prompt-based skills, searchable by text and semantic query and added to an agent such as Claude Code with one CLI command (smithery skill add), so a buyer adopts a ready-made workflow rather than writing it. It is a browsable catalog of ready made workflows that cut time to value.

Sourcesmithery.ai/docs/concepts/cliread 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 with its own webhook URL and signing secret through the Connect API, and when the upstream event fires the server posts it straight to the customer's endpoint. Smithery labels triggers preview with breaking changes possible, and a trigger exists only where the server's publisher implements it. Such an event starts work without a person asking.

Sourcesmithery.ai/docs/build/triggersread 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, with the model chosen and keyed by the customer, and Smithery names no model of its own. Model choice is the customer's throughout.

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

A documented REST API at api.smithery.ai, with a published OpenAPI specification, covers servers, releases, connections, tools, triggers, skills, namespaces and tokens, alongside a TypeScript SDK and a CLI. 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

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

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

Smithery's introduction names controlling browsers among the things agents can do, through the Browserbase server another company publishes in the registry; the capability and its documentation belong to that publisher, and a route to someone else's product is not Smithery's own. No browser, desktop or computer control of Smithery's own is documented.

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