Connect third-party tools to Sasha

Connect a service to Sasha when you want Sasha to use capabilities that the service publishes through an MCP server. You need an administrator account in Sasha and the service provider's MCP setup instructions. Open Settings, then Tools, and choose the service's connector or add a custom MCP server.

This connection brings a service into Sasha. To reach Sasha's knowledge from Claude, follow Connect Claude to your Sasha. For how your organisation's knowledge and access work, see What Sasha is and what Sasha holds.

Choose the setup mode

Use the transport and authentication method specified by the provider. An ordinary website address or general API address may not be an MCP endpoint.

Provider's setup Choose in Sasha What to enter
A program that starts the server stdio Separate Command, Arguments and Environment variables. The program runs on the Sasha server, so it must be available there.
A remote MCP endpoint with an API key or token in headers HTTP or SSE, as specified by the provider The MCP URL and the provider's required header names and values in the header fields.
A remote MCP endpoint with browser sign-in HTTP, then Sign in with the service The MCP URL, then complete the service's sign-in and consent pages. Do not add a token to Arguments or the URL.

For the built-in Stripe connector, enter a restricted key in its credential field, save it, then register and test it using the connector's controls. If Sasha reports a compatible custom registration, test that existing connection. Ask an administrator before replacing a working registration; do not rename or delete it merely to match a name in an example.

Keep the stdio fields separate

A stdio setup has three fields. Do not paste a complete command line into Command.

Field Shape of an entry
Command Only the executable, for example npx or node.
Arguments One argument per line. For a provider that uses npx, this might be -y on one line and the provider's package name on the next.
Environment variables One KEY=value entry per line, using the exact variable name required by the provider. KEY and value here are placeholders, not credentials to copy.

Use the provider's actual package name and required flags. Environment variable names use letters, digits and underscores, beginning with a letter or underscore. Put the actual credential value only in the appropriate Settings field. When editing a connector, leave a stored masked credential unchanged unless you intend to replace it.

Never put API keys, tokens or other secrets in Arguments or chat. Do not paste a command, screenshot, provider response or log that contains credentials into chat. For remote HTTP or SSE servers, use the dedicated header fields for header credentials, not the URL.

Save, test, then discover

  1. Save the configuration. Saved means Sasha stored the setup; it does not prove that the server connects. For HTTP sign-in, finish the browser authorization before testing.
  2. Test connection using the server's test control, or the built-in connector's smoke test. A successful test means the connection works.
  3. Discover capabilities to see what the server makes available. Connected does not mean the provider exposes the action you need.
  4. Start a new chat after adding, editing or reconnecting a server. Chats already open keep their previous tool list.

If saving, sign-in or testing fails, read the inline notice and follow its action. Keep the diagnostic code and the stage that failed; you can share those without sharing credentials.

Follow the diagnostic action

These are the setup codes Sasha currently shows. The action text matches the Settings diagnostics.

Diagnostic code Safe next action
MCP_SERVER_NAME_MISSING Use a short, unique name that identifies the service.
MCP_REMOTE_URL_INVALID Use the complete HTTP or HTTPS address supplied by the service.
MCP_STDIO_COMMAND_MISSING Put only the executable in Command, for example npx or node.
MCP_STDIO_ENV_INVALID Use letters, digits and underscores, beginning with a letter or underscore.
MCP_STDIO_REGISTRATION_FAILED Check the command, arguments and environment variables, then retry.
MCP_STRIPE_REMOVE_FAILED Test the existing registration, then retry registration.
MCP_STRIPE_REGISTRATION_FAILED Check the restricted key and retry.
MCP_OAUTH_RESOURCE_MISMATCH Check the MCP URL with the service provider.
MCP_OAUTH_METADATA_INVALID Check that this is the provider's MCP URL, then retry.
MCP_OAUTH_REGISTRATION_UNSUPPORTED Use another connection method documented by the provider, or ask whether dynamic MCP registration is supported.
MCP_OAUTH_REGISTRATION_FAILED Retry once. If it fails again, ask your Sasha administrator to check the provider's client-name and redirect-URL rules.

For a missing server name, missing command or invalid environment name, correct the indicated field before saving again. For a resource mismatch, verify the endpoint with the provider before proceeding; do not bypass the sign-in checks. If dynamic registration is unsupported, the provider or your administrator needs to identify a supported connection method. If registration is supported but rejected, the provider may enforce stricter rules for Sasha's client name or callback address; your administrator can check those without sharing credentials.

Make one careful retry after the relevant correction, when the notice permits retrying. If the same failure returns, stop changing configuration and ask your Sasha administrator or the service provider. Share only the code, transport type, failed stage, and whether you corrected the indicated field. Do not share keys, tokens, header values, authorization codes, full URLs containing credentials, or raw provider output.

A working connection can still lack a capability

If the connection test fails, repair the connection using its diagnostic. If the test succeeds but discovery does not list the action you need, check the provider's supported capabilities and your account's permissions. The provider may publish only some of its product features through MCP. Ask whether the missing action is supported and what access it requires. Repeated registration changes cannot create a capability the provider does not expose.

Questions

Where should I put an API key or token?

Use the connector's credential field in Settings. For stdio, use Environment variables; for HTTP or SSE with headers, use the provider's required header field. Never put a secret in Arguments or chat.

Why can my existing chat not see a tool I recently connected?

Each chat keeps the tool list it started with. After saving or reconnecting a server, start a new chat to use the updated list.

The connection works, but the action I need is missing. What should I do?

Discover capabilities and check what the provider exposes for your account. If the required capability is absent, ask the provider whether it is supported; reconnecting cannot add it.

made with bernard

Cookie settings