Tutorial 18

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, your own internal APIs.

Plus: three prompts that have the Admin Agent recommend which MCP servers to add first, debug a connection that won't validate, and audit which MCP servers your agents are actually using.

Audience Admins · Developers
Time ~10 min
Prerequisites Admin permissions on your Auxot account. At least one tool policy created (Tutorial 08). 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 server connected to a tool policy — and the tools it exposes are now available to any agent that uses that policy.

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.


Quick start

  1. Sign in — open Auxot in your browser and log in.
  2. Open Tool Policies — click Settings in the left menu, then Tool Policies.
  3. Open the policy you want to extend — click the row for an existing tool policy. (No tool policies yet? Tutorial 08 covers creating one — 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?

MCP servers are infrastructure decisions — they shape what your agents can do at the deepest level. The Admin Agent helps you decide what to add and figure out what’s wrong when something doesn’t work.

1. Have the Admin Agent recommend which MCP servers to add first

Open chat with the Admin Agent and try this:

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: The catalog has 30+ servers — most users get analysis paralysis or pick the obvious ones (GitHub, Slack) and miss the ones that’d actually transform their workflow. The Admin Agent reads your existing agents and your work context, and recommends the servers that fit. You go from “browse catalog” to “here’s the three to add and why” without having to evaluate them yourself.

2. Have the Admin Agent debug an MCP server that won’t validate

When Validate fails, the error is often cryptic. Paste it to the Admin Agent:

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: MCP server validation failures usually come down to one of: missing env vars, wrong auth credentials, network reachability, or a transport mismatch (stdio vs HTTP). The Admin Agent reads the error and suggests the most likely cause first — saving you the “try everything until it works” debug loop.

3. Have the Admin Agent audit which MCP servers your agents are actually using

Inverted-usage move. Once you have several MCP servers attached to policies, ask:

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 servers accumulate. You add a few, then a few more, then forget which ones any agent is actually using. Unused servers add validation noise, complicate audits, and bloat your tool surface. The Admin Agent traces the policy → agent connections and tells you which are dead weight.


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 (Tutorial 08); the agent now has access to the MCP server’s tools. One MCP server can be in multiple tool policies. One agent uses one tool policy at a time.

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, 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 (Tutorial 17) 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 (Tutorial 17).

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 (Tutorial 22) whether MCP server addition is enabled at your tier.

Walkthrough

Step 1: Open Tool Policies

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

If you have no tool policies yet, head to Tutorial 08 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 (Tutorial 17) 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, 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, 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

  • Pages in Auxot: Settings → Tool Policies → [policy] → Add MCP Server
  • Catalog categories: vcs, comms, pm, database, search, files, memory, cloud, devtools, automation, crm, data, docs
  • Transport types: stdio (npm) | streamable-http | sse
  • Env var sources: static, org_secret, team_secret, user_secret, oauth
  • Validate: confirms Auxot can reach the server and get its tool list before saving
  • See also: Tutorial 08: Define a tool policy, Tutorial 17: Manage your Credentials, Tutorial 19: Create a Skill