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.

Remote servers (added by URL)

A server can also be a remote https endpoint. Nothing runs on ToolGlue's side: we call the endpoint directly and attach the credential you store, either fixed headers (an API key) or an OAuth sign-in you complete in your browser. Everything else is the same, the namespaced tool names, the Playground, bundles and billing included. The sandbox limits above do not apply, because there is no sandboxed process; what applies instead is that the endpoint must be https, cannot point at a private or internal address, and every call goes out through the same egress guard as your connections.

What the isolation means

A package 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 remote server is different, and worth understanding before you add one. There is no container, because there is no process: ToolGlue calls the endpoint you named and sends it the credential you stored. That endpoint sees every argument every call carries, and what it sends back becomes the tool result your agents act on. It still cannot reach ToolGlue's internal systems, keys, or your other credentials. Point it only at a service you would give this data to directly. A platform administrator can disable external servers entirely, or allow only the sandboxed kind.

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.