Overview

A tool worker policy controls what tools are available when an agent calls out to external systems. Each policy is embodied by a tool connector key — a string in tools.{id}.{secret} format.

The tools worker binary (auxot-tools) connects to Auxot using that key. On connect, the server sends the full policy back: which built-in tools are enabled, and which MCP servers to start. The worker:

1. Starts each configured MCP server as a subprocess via npx -y <package>@<version>
2. Calls tools/list on each subprocess to discover available commands
3. Reports the full tool schema back to the server
4. Routes incoming tool calls to the correct subprocess at request time

The key is the policy. Whoever holds the key gets exactly the tools defined in it — no more, no less.

Auxot supports both local npm MCP (stdio, run by the worker) and remote HTTP MCP (Streamable HTTP or SSE) when the policy and deployment use that transport. For a walkthrough of which vendors fit each model, see Recommended integrations below.

Built-in Tools

Each policy can enable or disable the following built-in tools:

Toggle individual tools on or off in the policy editor. An agent that doesn’t need web access shouldn’t have web_search enabled.

MCP Servers

MCP servers are npm packages. You configure them inside a policy by specifying the package, version, environment variables, and which commands are enabled.

Adding an MCP server

In Settings → Tool Policies, open a policy and click Add MCP Server. Fill in:

• Package — the npm package name, e.g. @modelcontextprotocol/server-github
• Version — e.g. latest or a pinned version like 1.2.0
• Env vars — one or more environment variables the MCP process needs (see Credential Sources below)
• Commands — after the worker connects, discovered commands appear here; toggle individual ones on or off

Via the admin agent:

Add a GitHub MCP server to the engineering tool policy:
- package: @modelcontextprotocol/server-github
- version: latest
- GITHUB_TOKEN from the oauth source (github)

How the model sees MCP tools

The LLM sees MCP servers as aggregate tools — one tool per MCP server slug, not individual commands. For a GitHub MCP server with slug github, the model calls:

{
  "tool": "github",
  "command": "create_issue",
  "arguments": {
    "owner": "acme",
    "repo": "backend",
    "title": "Fix null pointer in payment handler"
  }
}

This keeps the tool schema compact regardless of how many commands the MCP server exposes. Individual commands you don’t want accessible can be disabled in the policy.

Recommended integrations

When you are choosing what to connect first, you have two transport shapes: local npm (stdio) and remote HTTP (Streamable HTTP or SSE). The list below mirrors the admin app’s mcp-catalog.ts (under web/src/data/ in auxot-server) in broad strokes — use it for orientation; pin versions and auth details in the policy editor to match your org.

Local npm MCP vs remote HTTP MCP

• Local npm (stdio). The tools worker runs npx -y <package>@<version> and talks to the MCP over stdin/stdout. You supply environment variables (or the worker resolves them from org, team, user, or OAuth — see Credential Sources). Use this when the upstream ships a well-maintained package, you want everything to run on the worker without calling vendor HTTPS for every tool turn, or the vendor has no first-party HTTP endpoint yet. Egress is whatever the package opens itself (databases, vendor APIs, etc.), not a separate “MCP URL” you configure.

• Remote HTTP. You configure a single MCP endpoint URL. The worker sends JSON-RPC (often over POST, sometimes with an SSE follow-up) to that host. Authentication is usually an HTTP header (for example Authorization: Bearer …) where the value comes from the same kinds of sources you already use: OAuth (preferred when the product supports it — refreshed user tokens) or a PAT or API key via org/user secret mapped onto the header. Worker egress applies to that HTTPS origin on every list/call. Prefer HTTP when the vendor hosts the MCP, you want zero install on the worker, or OAuth is only documented for the remote endpoint.

• Practical note. Until your deployment has HTTP MCP fully enabled, treat remote rows below as “planned / requires platform support” and use the stdio option for the same product when both exist (for example Sentry, GitHub).

Version control and Git platforms

Comms

Project management and toolkits

Databases and data services

Search

Files and storage

Memory

Cloud platforms

Dev tools, observability, and browsers

Automation

CRM

Data and docs

Credential Sources

Each environment variable on an MCP server config has a source that tells the worker where to get the value at runtime:

Credentials from org_secret, team_secret, and user_secret are encrypted at rest with AES-256-GCM using AUXOT_SECRET_KEY. They are never returned in API responses, never logged, and only decrypted in memory inside the tools worker process.

OAuth-Backed MCP

The oauth source is what enables per-user MCP authentication. Instead of a shared service account token, each user’s MCP calls are made with their own OAuth access token — automatically refreshed if expired before being injected into the subprocess.

Example: GitHub MCP with per-user OAuth

Setup:

1. Configure a GitHub OAuth app in Auxot (Settings → OAuth Providers, client ID + secret).
2. In the tool policy, add the GitHub MCP server. Set GITHUB_TOKEN env var with source oauth, provider github.
3. Users connect their GitHub account in their profile (Settings → Connected Accounts).

At runtime: when a user’s agent calls the github tool, the worker resolves that user’s stored GitHub OAuth token, injects it as GITHUB_TOKEN into the MCP subprocess environment, and executes the command. If the token is expired, it’s refreshed first.

This means:

• Alice’s github calls use Alice’s token — she sees the repos she has access to
• Bob’s github calls use Bob’s token — scoped to his permissions
• No shared service account. No over-provisioned API key.

User connection required: If a user hasn’t connected their GitHub account and tries to use a tool backed by oauth source, the tool call will fail with a message prompting them to connect the account in their profile.

Managing Policies

Settings UI

Settings → Tool Policies shows all tool connector keys in your organization. Click a key to open the policy editor:

• Toggle built-in tools on/off with credential status indicators
• Add, edit, or remove MCP servers
• Configure env var sources for each MCP server
• Enable/disable individual MCP commands
• Assign the policy to teams
• Regenerate the key (old key is immediately invalidated)

Admin agent commands

Create a tool key for the engineering team with GitHub MCP and web_fetch enabled.
GITHUB_TOKEN should use the oauth source with the github provider.

Assigning to Teams

A tool connector key can be restricted to specific teams. Use this to keep sensitive integrations scoped to the right group.

This is how you give the engineering team GitHub access without exposing it to the support team — create separate policies with appropriate team assignments.

Assign the engineering-tools key to the Engineering and Platform teams.

Tool policies are the boundary for what external capabilities an agent can reach. Keep them narrow — a focused policy is easier to audit and rotate than a single key that does everything.