Add an MCP server

Connect an MCP (Model Context Protocol) server to a tool policy and give your agents access to a new set of tools — GitHub, Slack, Notion, or your own internal APIs.

Plus: three pasted Admin-Agent probes — prioritized catalog picks against the agents you already have, decoded Validate errors, and a map of policy attachments so orphaned MCP servers stop cluttering audits.

Audience Admins · Developers
Time ~10 min
Prerequisites Admin permissions on your Auxot account. At least one tool policy created ([Define a tool policy](/tutorials/define-a-tool-policy)). The MCP server you want to add — its npm package name, or a remote URL with auth credentials.
You'll end up with One MCP attachment validates inside a tool policy so every agent wired to that policy inherits fresh tools — creds routed through secrets ([Manage your Credentials](/tutorials/manage-your-credentials)), not brittle static fields.

When a tutorial shows italic text in quotation marks, it usually mirrors a label or helper string inside Auxot. Product copy changes between releases — if something reads differently in your workspace, trust what you see on screen.

Callouts with a Worth knowing gold accent are meant as must-read context before you move on. Blockquotes that open with Tip are lighter, optional depth.

Why this matters

MCP (Model Context Protocol) is how your agents reach beyond Auxot: to GitHub repos, Slack channels, your CRM, your internal databases, anywhere a tool lives. An MCP server is the connector. You add the server to a tool policy; the policy is attached to an agent; the agent can now use those tools. Auxot ships a curated catalog of 30+ MCP servers (GitHub, GitLab, Slack, Notion, Google Drive, Sentry, Supabase, more), and you can add custom ones via npm package or HTTPS URL.

Today, add one MCP server and watch your agent’s capabilities grow. By the end, your agent has new tools it didn’t have ten minutes ago.

MCP servers advertise tools through a connector you attach to a Tool Policy. Agents inherit whatever that policy validates, and credentials stay injected from Settings → Credentials, not echoed into chat.


Quick start

  1. Sign in: open Auxot in your browser and log in.
  2. Open Tool Connector Keys: click Settings in the left menu, then Tool Connector Keys (same page as “tool policies” in docs, URL /app/settings/tool-policies).
  3. Open the policy you want to extend: click the row for an existing tool policy. (No tool policies yet? Define a tool policy and come back here after.)
  4. Click Add MCP Server: the modal opens with two tabs: Browse (Auxot’s curated catalog) and Manual (your own package or URL).
  5. Pick or paste, then validate and save: choose from the catalog OR paste an npm package name or HTTPS URL. Click Validate to confirm Auxot can reach the server. Click Save.

Done? Your tool policy now has the MCP server attached. Any agent using that policy can call the tools it exposes.


The agent can do that?

Infrastructure decisions deserve a second pass: paste constraints first; replies reference agents and workloads already inventoried while Validate stays your ground truth inside Tool Policies.

1. Prioritize catalog servers

Chat → Admin Agent:

My team uses Auxot for [brief description — e.g., "small dev team, mostly working in GitHub, Slack, and Linear"]. Looking at the agents I've already built, which MCP servers from Auxot's catalog would be most useful to add first? Recommend up to three, and tell me what each one would let my agents do.

Why it’s non-obvious: Catalog breadth invites either safe defaults or distractions nobody will maintain. Naming your stack in the paste forces ranked picks tied to prompts you already run daily.

2. Decode a failed Validate

When Validate returns an error, paste the verbatim error and the transport you picked:

I'm trying to add the [package name or URL] MCP server to my tool policy. When I click Validate, I get this error: [paste exact error]. What's likely wrong, and what should I check first?

Why it’s non-obvious: The same symptom (timeout, auth failure, or transport mismatch) has different fixes. Ranking hypotheses from the actual error text beats randomly toggling scopes until one of them works.

3. Flag unused MCP baggage

Once multiple servers stack up, paste:

Looking at my tool policies and which agents have them attached, which MCP servers are actually being used by an active agent — and which are connected but unused? If any are unused, tell me whether to remove them or if there's an obvious agent that should be using them.

Why it’s non-obvious: MCP rows that nobody uses still run their nightly validation and still show up in audits as available surface. Comparing orphaned servers to live agent attachments lets you keep each tool policy narrow on purpose.


Go deeper

What an MCP server actually is

MCP is Anthropic’s open protocol for connecting AI agents to external tools and data sources. An MCP server is a small program (or a hosted endpoint) that speaks the MCP protocol: it advertises a list of tools, and when an agent calls one, the server runs it and returns the result. The agent never directly accesses your GitHub repo or your Slack workspace; it always goes through the MCP server, which handles authentication, rate limiting, and the actual API calls.

Two transport types:

  • stdio (npm packages): you specify a package name like @modelcontextprotocol/server-github, and Auxot runs it locally inside its tool worker process. Fast, isolated, requires Node.
  • HTTP (remote): you specify a URL, and Auxot reaches the MCP server over the network. Used for hosted MCPs (GitHub Copilot’s MCP, Vercel’s MCP, etc.). Either streamable-http or sse transport.

How MCP servers connect to your agents

The chain is MCP server → Tool policy → Agent. You add an MCP server to a tool policy; you attach the tool policy to an agent (Define a tool policy); the agent now has access to the MCP server’s tools. One MCP server can sit on multiple tool policies. One agent can attach multiple tool policies: it sees the union of tools from all of them.

Auxot’s curated MCP catalog

The Browse tab in the Add MCP Server modal shows a curated catalog organized by category: version control (GitHub, GitLab), comms (Slack), project management, databases, search, files, cloud platforms, dev tools, and more. Each entry has metadata about which transport it uses, what auth it needs, and what tools it exposes. The catalog is editorial: it’s hand-picked MCP servers that work well, not auto-pulled from npm.

Environment variables, secrets, and OAuth

Most MCP servers need credentials: a GitHub token, a Slack OAuth app, or an API key for your CRM. Auxot supports these as:

  • Static: value typed directly in the form. Stored encrypted, but visible to anyone who can edit the tool policy. Use only for non-sensitive values.
  • Org secret / Team secret / User secret: value pulled from a Credential (Manage your Credentials) at the right scope.
  • OAuth provider: value pulled from your configured OAuth provider for that service.

Troubleshooting

  • Validate fails with “connection timeout”: the MCP server isn’t reachable. For stdio (npm) servers, this usually means the npm package failed to install in the tool worker. For HTTP servers, check the URL and any required auth headers.
  • Validate succeeds, but the agent never uses any of the tools: the tool policy isn’t attached to the agent, OR the agent’s prompt isn’t structured to recognize when those tools should be used. Check the agent’s tool-policy attachment in Settings → Agents.
  • MCP server keeps disconnecting: credential expired, or the underlying service revoked the token. Re-authenticate via the Credentials page (Manage your Credentials).

Variations & edge cases

  • Custom (non-catalog) MCP servers: use the Manual tab. Paste the npm package name or HTTPS URL. Auxot doesn’t curate or vet manual MCPs; you’re responsible for trusting the source.
  • Disabling vs deleting: disabled MCPs stay attached to the policy but aren’t loaded into the tool worker. Useful for temporary deactivation. Delete removes the attachment entirely.
  • Per-team scoping: MCP servers attached to a team-scoped tool policy only affect agents in that team. On Business tier and above, this lets different teams have different tool surfaces.
  • Tier behavior: confirm with your tier’s feature list (View and manage your License) whether MCP server addition is enabled at your tier.

Walkthrough

Step 1: Open Tool Connector Keys

Click Settings in the left menu, then Tool Connector Keys. You’ll see a list of your existing keys (each is a tool policy that authenticates a worker and grants it specific tools).

If you have no tool policies yet, head to Define a tool policy first: you need at least one tool policy before you can attach an MCP server to it.

Step 2: Open the policy you want to extend

Click the row for the tool policy you want to add an MCP server to. The detail page opens with two main areas: the policy’s metadata at the top, and the MCP server list below.

Step 3: Click Add MCP Server

The Add MCP Server button is above the MCP server list. A modal opens with two tabs:

  • Browse: Auxot’s curated catalog of MCP servers, organized by category.
  • Manual: paste your own npm package name or HTTPS URL.

Step 4a: Add a server from the catalog (Browse tab)

Click a category, then click an MCP server entry. The form fills in:

  • Name: the display name (you can rename it).
  • Package or URL: pre-filled from the catalog.
  • Transport: stdio for npm, streamable-http or sse for remote.
  • Environment variables: fields the MCP server needs to authenticate. Each var has:
    • A name (e.g., GITHUB_TOKEN).
    • A source: Static, Org secret, Team secret, User secret, or OAuth.
    • A value or reference depending on source.

Fill in the credentials. Use secrets references (Manage your Credentials) for anything sensitive.

Step 4b: Add a custom server (Manual tab)

Switch to Manual if you’re adding an MCP server not in the catalog.

  • Package: npm package name (e.g., @your-org/your-mcp-server).
  • Version: defaults to latest.
  • OR URL: for remote HTTP MCP servers.
  • Transport: pick the right one for your server.
  • Environment variables: same as Browse path.
  • HTTP headers (only for remote): name, value, source, and oauth_provider for each.

Step 5: Validate and save

Click Validate. Auxot connects to the MCP server, fetches its tool list, and confirms it speaks the protocol correctly. You’ll see the tool list it returned: that’s what your agents will be able to call.

If validation fails, fix the error (usually a credential or URL issue) and try again. Don’t save unvalidated.

Click Save. The MCP server is added to the tool policy. Any agent using this tool policy now has access to the tools the MCP server exposes.

Tip: After saving, open chat with an agent that uses this tool policy and try a prompt that would use the new tools. If the agent calls a tool from the MCP server in its response, you’ve wired everything correctly.

Step 6: (Optional) Edit, disable, or delete

From the tool policy detail page, each MCP server in the list has actions:

  • Edit: change the name, credentials, and env vars.
  • Enable/disable: toggle without deleting (useful for temporary deactivation).
  • Delete: remove the MCP server from this tool policy entirely.

What’s next

Reference