MCPStore.nl

Published:

Smithery shuts down its MCP proxy: what organisations need to check

In short: Smithery, a well-known MCP hosting platform, shut down its proxy and connection services on 31 October 2026. Server URLs on run.tools and server.smithery.ai, the Smithery API, accounts and API keys no longer work. Smithery continues as a public directory, run by Arcade.dev since its acquisition in August. Users need to switch to each vendor's official MCP URL.

Smithery started as a registry where you could find and launch an MCP server in one click. Much of that simplicity came from its proxy: instead of connecting directly to a vendor's server, traffic went through a Smithery address such as linear.run.tools, and Smithery also handled the credentials ("managed identity"). That is the part that has now gone.

What exactly has been shut down?

According to Smithery's own announcement ("The future of Smithery", signed by co-founder Anirudh Kamath), the following stopped on 31 October 2026:

What remains: smithery.ai as a public directory of MCP servers, "now powered by Arcade.dev", plus a curated set of verified servers whose pages show the vendor's direct address. Smithery's own example is mcp.linear.app/mcp instead of linear.run.tools. Paying customers are refunded every charge since 5 August and their subscriptions are cancelled.

That date is no coincidence. On 5 August 2026 Arcade.dev announced it had acquired Smithery. Arcade describes itself as "the actions runtime for enterprise AI agents" and sells its own platform for agent tool calling. Terms were not disclosed; according to tech outlet RuntimeWire, the deal came six weeks after a 60 million dollar Series A for Arcade.

Who is affected?

Three groups, each with a different problem.

Individual users who configured a server in Claude Desktop, Cursor or VS Code through a Smithery URL. Their connection no longer works, and Smithery's fix is simple: look up the vendor's official address and sign in there. Migration service API Tracker stresses that credentials do not carry over; you have to authenticate with each vendor again.

Teams running Smithery packages locally, for example using the Smithery CLI as a wrapper around a server. That CLI is no longer maintained. It is not an immediate outage, but it is a maintenance risk: software without updates also gets no security fixes.

Organisations that managed MCP connections for their own customers through Smithery. A new URL is not enough for them. Smithery wrote that they needed a replacement before 31 October, and API Tracker points out that this covers the whole authentication and session-management layer. If you built that layer into your product, you now face an architecture decision rather than a configuration change.

Why does this matter beyond one shutdown?

Our analysis: this is the first major example of an MCP intermediary disappearing within a few months. A proxy like Smithery's is convenient, but it adds a party that sees all your traffic and often holds your tokens. That was already a security question: in October 2025 a platform bug at Smithery leaked a token with access to thousands of servers, as described on our MCP security page. It now turns out to be a continuity question too. For financial institutions under DORA, such a service belongs in the register of ICT third-party providers, with an exit plan. A move with a few months' notice is exactly the scenario that exit plan exists for.

The shift fits a broader trend. More vendors now run their own remote MCP server with their own sign-in; Linear, the example Smithery itself gives, does so at mcp.linear.app/mcp. That shrinks the original case for a generic proxy. What remains is the question of who governs agents' access to all those servers, which is where Arcade and similar companies are now focusing, as a paid enterprise service.

Our advice

(1) Search every MCP configuration in your organisation (Claude Desktop, Cursor, VS Code, internal agents, CI) for run.tools, server.smithery.ai and @smithery/ packages. (2) Replace each connection with the address from the vendor's own documentation, not from another directory: a similar name does not prove the server belongs to that vendor. (3) Sign in again, test with a read-only action first and only then grant write access. (4) Revoke, at each vendor, OAuth grants you once gave via Smithery and no longer use. (5) For every MCP intermediary you keep, whether gateway, proxy or registry, write down what you will do if it stops. See also trusted MCP sources and MCP and EU regulation.

Sources

Frequently asked questions

Do my MCP servers still work through Smithery?

Not if you connected them via Smithery. According to Smithery, all server URLs on run.tools and server.smithery.ai, the Smithery API, accounts and API keys stopped on 31 October 2026. Use the official MCP address from the vendor's documentation instead and sign in there again.

Does smithery.ai still exist?

Yes, as a public directory of MCP servers, run by Arcade.dev since the acquisition on 5 August 2026. For verified servers the page shows the vendor's direct address. Connecting through Smithery itself is no longer possible.

Do I need to act if I only used Smithery locally via the CLI?

Yes. The Smithery CLI and SDKs are being marked as deprecated, so they will get no more updates or security fixes. Preferably install the server directly following the publisher's instructions and pin a version.

Last updated: