External MCP servers

Bring an existing MCP server into your workspace: an npm package run with npx, a Python package run with uvx, or a pasted mcpServers JSON entry. ToolGlue hosts it, discovers its tools, and puts them on your MCP surface.

Adding a server

On the MCP servers page, pick from the curated known-servers list or enter a package yourself. Only npx and uvx commands are accepted; a pasted entry that tries to run anything else is rejected. Version pins are allowed, and environment values the server needs (an API token, say) are stored encrypted under your workspace key.

After a discovery pass, the server's tools appear under a namespaced name like github__create_issue (server slug, two underscores, tool name). They are callable by agents, testable in the Playground, and assignable to bundles. Every call is billed like any other run.

Sandbox limits

• Each call has a hard 30 second wall clock; server startup gets 60 seconds.
• Responses and logs are capped at 1 MB.
• Idle servers are shut down after 5 minutes and restarted on demand.
• A limited number of server processes run concurrently; excess calls get a clear busy error.

What the isolation means

The server runs in an isolated container away from your ToolGlue data: it can never reach ToolGlue's internal systems, encryption keys, or your stored credentials, and its environment is built from scratch rather than inherited. Be aware of the honest limit: the server can reach the internet (that is how it calls its own vendor's API) and it sees the environment values you give it. Only run packages you trust with those values. A platform administrator can also disable external servers entirely.

Prefer native tools when you can

A community package is third-party code, the classic supply-chain risk, which is why the sandbox above exists. When the same capability is a plain HTTP API, the lower-risk path is to build it natively: connect the API (or let AI draft the connector), then have create_action build the tool. Native tools run in ToolGlue's zero-egress sandbox where credentials are injected server-side and the code can only ever reach the one granted connection: no package install, no third-party code at all. Treat community servers as a great reference for what an integration should do, and reach for them directly when the capability genuinely needs their code.