Connect a remote MCP server

To connect an MCP server to Toolstile, paste its remote endpoint into MCP connections → Connect an MCP. Toolstile attempts to detect the transport and authentication method. Complete the provider's sign-in or supply its bearer token, then grant access to an agent separately.

This guide covers the server side of the connection. For agent registration and access setup, use Getting started.

Find the provider's MCP endpoint

Get the endpoint from the provider's MCP documentation, integration settings, or account administrator. Copy the full URL, including the path. For example, https://mcp.example.com/mcp is a placeholder showing the shape of a remote endpoint; it is not a working server.

A provider's homepage or general API address may not accept MCP requests. Check which transport the endpoint supports and whether your account needs OAuth approval or a token.

Toolstile's managed service requires a publicly reachable HTTPS endpoint on port 443. It cannot reach localhost, private-network addresses, or a process launched over stdio. The service connects to remote MCP servers; it does not host those server processes for you.

Add the connection in the right workspace

Select the intended workspace from the dashboard's workspace menu. Open MCP connections, choose Connect an MCP, and paste the URL into MCP server URL.

Use Advanced options only where needed:

• Name sets a label instead of using the detected name.
• Bearer token accepts the provider-issued token value. Leave out the Bearer prefix.
• Transport defaults to Detect automatically. Select Streamable HTTP or Legacy HTTP + SSE only when the provider's documentation names one.
• Authentication defaults to Detect automatically. Choose Sign in with OAuth or Bearer token or none when you know the required method.

Choose Connect. Detection either fills in the settings or marks the connection Needs sign-in or Needs attention. It does not prove that the provider's sign-in flow or every capability will work, so check the provider's instructions if the result is not usable.

Personal and team catalogs have separate access grants. When you add a server from a team workspace, Toolstile also makes your connection available in your personal catalog. This does not grant agents access in either workspace. In a team workspace, a connection added without catalog-management permission needs approval before it can be used there.

Sign in to the provider with OAuth

If the detected or selected method is OAuth, Toolstile opens a sign-in dialog for that connection. Signing in can replace the connection's existing authentication, so the dialog asks you to confirm that first. Check the confirmation, then choose Continue to provider.

Sign in at the provider, confirm the intended account and requested permissions, then return to Toolstile. Provider permissions still limit what that account can do. Toolstile access rules cannot expand them.

If the provider requires a registered OAuth application, open Registered client settings (optional) and enter its Client ID and Client secret. Obtain these from the provider's application-registration process, following its instructions. They are OAuth application credentials, not a personal API token or a Toolstile agent token. Leave these fields empty when they are not required.

Use Sign in / reconnect on the connection to start again later. If a shared account's sign-in is managed by its owner, ask that owner to reconnect it. When a specifically selected account becomes unavailable, Toolstile stops instead of silently choosing another identity.

Use a provider bearer token

If the provider documents bearer-token authentication, obtain a token from that provider's account or developer settings. In Advanced options, paste only its value into Bearer token and use Bearer token or none as the authentication method when selecting it manually.

Toolstile sends the value upstream as an authorization header. For illustration, Authorization: Bearer <PROVIDER_TOKEN> contains a placeholder, not a usable credential. Do not paste that whole example into the token field.

A token is a static credential rather than an interactive OAuth sign-in. Follow the provider's guidance on scope, expiry and replacement. If the server requires no authentication, leave the bearer field empty.

Some servers require a custom header such as an API-key header. The current connection form exposes a bearer-token field, not an arbitrary-header editor. Check the provider's supported alternatives before proceeding; do not place a custom-header value in the bearer field and assume it will work. Do not put credentials into the server URL.

Authorize the agent separately

Provider authentication lets Toolstile connect to the upstream account. Agent authorization identifies the app or script connecting to Toolstile. An access grant determines what that agent may use. These are separate steps.

In Devices & agents → Connect an agent, follow the instructions for your agent app. Copy Toolstile's gateway address from that dialog or Settings → Endpoint. Use the gateway address in your client and the provider's endpoint in MCP connections.

Start the client sign-in, select the intended Workspace in the browser, and approve the named agent/device connection. The gateway address alone does not select a workspace. An authorization uses only its selected workspace's catalog and allowance; changing the dashboard workspace does not redirect an existing client authorization. Use a separately named client entry for another workspace; see Client setup.

New agents have no MCP access. Configure the agent/connection pairing through Access or guided setup's Configure access, then choose Save access. An empty allow list with full access off permits nothing. Full access includes supported future tools, resources and prompts, while explicit blocks continue to apply.

Verify before running a tool

The connection's Verify action checks the server connection. To check what an agent can discover, use guided setup's catalog check or choose Test tool, select the agent, and choose Load permitted tools. The agent-specific catalog check applies that agent's access and selected account. It does not execute a tool. Catalog checks consume the selected workspace's operation allowance.

For an optional execution test, select a permitted tool and review Tool arguments (JSON) before choosing Run test tool. This is a real call using the agent's current permissions, and it may change data. A catalog check is enough when you only want to verify discovery.

Finish agent and access setup. For access rules, read Permissions; for failed checks, use Troubleshooting. Return to the documentation index for the setup overview.