Smithery

Executive Summary

Smithery combines a registry for discovering MCP servers with infrastructure for connecting to them. Its Connect service handles protocol sessions and authentication, exposing tools through an HTTP API and an aggregated MCP endpoint. That makes it relevant to application developers as well as people configuring an agent client.^[1]

Ownership changed on August 5, 2026: Arcade announced its acquisition of Smithery and that co-founder Anirudh Kamath was joining the team.^[2] The current Smithery documentation still describes its own connection, token, and billing model. Buyers should evaluate those published interfaces rather than assume the acquisition has already unified every product surface.

---

Product Overview

Smithery's command-line interface can search the registry, add an MCP server to a local client, or create a managed remote connection. It also supports discovering and installing agent skills. Those operations have different consequences: adding a local client configuration is not the same as routing future requests through a hosted connection.^[3]

Key capabilities

For a product team, the value is reducing repeated connection plumbing. The remaining work is deciding which user may reach which connection, what tools the application exposes, and how it verifies a completed business action. A protocol connection alone does not establish those policies.

---

Technical Architecture

Connection and identity boundaries

A namespace is the organizational container. Its name is globally unique; connections live inside it alongside published resources. Use an explicit namespace for the intended application or environment rather than relying on an accidental default.^[4] Naming separation helps operators understand the system, but authorization still needs enforcement.

Connect documents managed OAuth for supported integrations and custom connection configuration where required. Account API keys belong on the backend. A client or agent should receive a suitably scoped service token instead of a key with broad namespace access.^[1][5] This distinction matters when the agent's input is partly controlled by an untrusted user.

Scoped token grants can match resources and connection metadata, allow particular operations, and expire. Metadata predicates within a grant combine with AND; multiple grants can widen access through OR. The preview documentation also distinguishes reading connection records from executing their tools.^[5] A permission called connections.read is therefore not a promise that every exposed business action is read-only. The application must map its trusted user identity to the allowed connections and inspect the actual tool set.

State, partial failure, and simulated tools

The connection API exposes states including connected, authentication required, input required, error, and disconnected. It also describes an optional mock configuration that enables LLM-simulated responses.^[8] A useful operational screen should distinguish an authenticated live provider from a simulated connection; both can produce plausible-looking output during development.

Aggregated tool listing returns a result envelope for each connection. One upstream failure need not fail the entire HTTP request, and connections waiting for authentication or input are skipped.^[6] Consequently, a successful aggregate response is not proof that every intended integration is available. Record per-connection failures and compare the returned tools with the expected inventory.

The TypeScript SDK's typed interface is marked preview and can change without notice. Generated types help callers use known schemas, but they do not prove that a remote service completed the user's intent.^[1] Pin dependencies and exercise the actual responses used by your application.

Local uplinks

An uplink bridges a local MCP service to Smithery over a persistent WebSocket. The CLI can connect to an HTTP service or launch a stdio subprocess. Only one active tunnel can serve a connection; forcing a replacement interrupts the previous one. When the uplink ends, server information and cached tools are cleared.^[7]

This is useful for development or a personally hosted tool, but the workstation becomes part of the availability path. Sleep, process termination, and network failure need explicit handling. “Local server” should not be translated into “offline” or “all traffic remains on the device”: the access path includes the remote tunnel.

A practical acceptance test

Start with two customer identities, each authorized to a different set of harmless test records. Create distinct connections, issue constrained service tokens, and list the available tools. Try an identifier belonging to the other customer and a token that has expired. Verify that the backend derives the authorization boundary from authenticated application state.

Next, revoke one provider connection while leaving the other healthy. Inspect both the aggregate status and the per-connection result. If using an uplink, stop its process and confirm how the client presents the disconnection. Finally, execute an approved write and check the resulting record directly at the provider. Disable any simulated-response mode for this last step. This is a proposed evaluation sequence, not a test performed for this report.

---

Strengths

• Multiple entry points. The CLI supports an individual configuring tools, while managed connections support applications that need reusable access.^[3][1]
• Explicit delegation controls. Token scoping provides a more appropriate boundary for downstream callers than sharing a broad backend key.^[5]
• Visible connection state. Per-connection status and aggregation behavior give an application information it can use to explain partial availability.^[8][6]
• A development bridge. Uplinks make a local process accessible without turning it into a separately operated public service first.^[7]

Cautions

• Preview interfaces require change management. Token scoping and the typed SDK carry preview qualifications in the reviewed documentation.^[5][1]
• Authorization remains application work. Resource metadata must be assigned from trusted state; a label supplied by a caller should not decide another customer's access.
• Partial results can look healthy. A successful aggregate response may coexist with missing integrations, so inspect its component results.^[6]
• Local availability is still local availability. Uplinks depend on a live host and tunnel. They do not by themselves provide a production hosting or redundancy plan.^[7]

---

What Developers Say

In a January 18, 2026 issue in the mcp-go project, contributor Dumbris described OAuth discovery difficulties while implementing an MCP proxy and connecting to Smithery's Google Drive service. The report identified path handling and a separate authorization domain; it linked a proposed client-side fix.^[9]

This is a specific interoperability report, not evidence that every Smithery client fails or that the current service has a general outage. It does show why a production trial should cover the complete authorization flow with the exact client library and version, including discovery, callback handling, refresh, and revocation. The reviewed public discussion did not establish a representative reliability or satisfaction rate.

---

Pricing & Licensing

Public pricing reviewed September 16, 2026:

The pricing FAQ defines RPC usage as JSON-RPC requests, including tool listing, tool execution, and resource reads. The caller pays; publishing a registry listing is free.^[10] A workflow's cost therefore depends on discovery and other protocol traffic as well as completed actions. Upstream applications and model providers can charge separately.

Licensing model: The public Smithery CLI license is AGPL-3.0.^[11] That component's license does not mean the complete managed service is available under the same deployment or commercial terms.

Budgeting approach: Measure a representative application's actual requests, reconnection behavior, and tool-discovery frequency. Avoid treating “one user task” as a fixed number of billable requests.

---

Competitive Positioning

Choose Smithery when registry discovery, managed MCP connectivity, or a local-to-remote development bridge directly reduces implementation work. Compare the exact providers, auth flows, and failure handling required by the application. Catalog size alone does not answer whether the needed action, scope, and response shape are usable.

Ideal Customer Profile

Best fit: Developers building MCP-connected applications, teams consolidating access to multiple servers, and people exposing local tools for a controlled development workflow.

Poor fit: An offline requirement, an assumption that metadata alone supplies tenant isolation, or a production design that cannot tolerate preview-interface changes without a compatibility plan.

Viability Assessment

Arcade's acquisition is a concrete ownership event, while the current docs expose a usable connection and commercial model.^[2][10] Neither proves a specific future roadmap, guaranteed product consolidation, or operational reliability. For a critical dependency, confirm support ownership, contract continuity, export needs, and migration options with the provider.

Bottom Line

Smithery deserves evaluation as connection infrastructure, beyond its registry identity. Its strongest fit is an application that benefits from reusable MCP access and can implement clear user boundaries, inspect partial failures, and test the exact clients involved.

Recommended for: Managed MCP connections and controlled local uplink workflows.

Not recommended for: Treating successful discovery as proof of complete authorization, availability, or business correctness.

Outlook: Follow the documented product and support terms as integration with Arcade develops.

---

Research by Ry Walker Research • methodology