Tutorial 08

Define a tool policy

Give your agents real-world capabilities — web search, GitHub access, Slack messaging, anything — by bundling tools into a reusable toolbelt and handing it to whichever agents should have it.

Plus: three prompts that turn the Admin Agent into your tool-policy advisor — recommending what each agent should have, auditing what they shouldn't, and building new policies from scratch in one conversation.

Audience	Admins · Developers
Time	~10 min
Prerequisites	An Auxot account on any tier. You're an org admin (tool policies are admin-managed). At least one custom agent exists (Tutorial 07). Helpful: a rough sense of what tools you want your agents to have — web search? GitHub? Slack? An internal API?
You'll end up with	One tool policy created, tools added to it, and at least one agent given access to it — so that agent can now actually do work in the outside world.

Why this matters

Up to this point, your agents have read context files and answered questions. That’s leverage, but it’s reading-only.

A tool policy is what gives an agent the ability to actually do things in the world — search the web, read your GitHub repos, post to Slack, query your internal API. Without a tool policy, an agent is a thoughtful colleague with no hands. With one, it’s a thoughtful colleague who can finish the work without coming back to ask you to look something up.

Think of a tool policy as a toolbelt you build once and hand to whichever agents should wear it. You decide what’s clipped to the belt — web search here, GitHub access there, your CRM lookup over here — and the agent uses any of those tools whenever a question calls for it. One toolbelt can be reused across many agents. Different agents can wear different belts. The same agent can wear more than one.

Auxot calls these toolbelts “Tool Connector Keys” in the UI. The conceptual term is “tool policy.” Both refer to the same thing — the bundle of tools, and the rules about how they’re used.

Today, build one. Tomorrow, your agents stop saying “I don’t have access to that” and start handing you the answer.

You build a toolbelt — a tool policy — once. You decide what tools clip onto it (web search, MCP servers, internal APIs). Then you hand the toolbelt to as many agents as should have it. Each agent uses any tool on its belt whenever the work calls for it.

Quick start

Sign in — open Auxot in your browser and log in.
Open Tool Policies — click Settings in the left menu, then Tool Connector Keys (or Tool Policies, depending on your version).
Create a new key — click + Add Key, give it a clear name (something like “Research toolkit” or “GitHub access”), and save. A raw key is shown once — copy it if you’ll use it externally; otherwise you don’t need it.
Configure the policy — click the key’s row to open its detail page. Toggle on the built-in tools you want (web_search, web_fetch, etc.). Optionally add MCP servers for custom integrations.
Attach it to an agent — open Settings → Agents, click the agent, scroll to the Tool Policies card, click Add Tool Policy, and pick the key you just made.

Done? That agent now has the tools you bundled. Test it by asking the agent something that requires one of those tools.

The agent can do that?

You don’t always have to figure out tool policies yourself. The Admin Agent can recommend, audit, and even build them for you. Three prompts that turn the Admin Agent into your tool-policy advisor.

Open chat with the Admin Agent and ask:

I have an agent called [name and one-line job — e.g., "Customer Support Agent: drafts replies in our brand voice"]. What tools should this agent have access to, and what tools should it never have? Recommend a tool policy by name and contents — and tell me what to leave out, with reasons.

Why it’s non-obvious: The Admin Agent can see every tool Auxot ships with and every MCP server you’ve configured. Asked the right way, it’ll match your agent’s job description against the available tools and tell you what’s missing — and what’s a security or scope risk to include. Most people pick tools by feel and end up giving every agent web_search “just in case.” This prompt produces an actually-considered answer in fifteen seconds.

2. Audit which tools your agents already have (and shouldn’t)

Same chat, follow-up:

Look at all the tool policies attached to all my custom agents. Where am I overscoping — agents with tools they don't need for their job? Where am I underscoping — agents whose job descriptions imply tools they don't have access to? Be specific by agent name.

Why it’s non-obvious: Tool policies drift. You add a tool to a toolbelt for one agent and forget that five other agents share that toolbelt. Or you give an agent a job description that implies web access without actually attaching web_search. The Admin Agent can read your whole agents-and-policies graph and call out the mismatches. This is the kind of audit you’d otherwise schedule a meeting for.

3. Build a tool policy from scratch by describing the goal

Build me a tool policy called "[name]" that gives an agent everything it needs to [describe the goal — e.g., "research a B2B prospect: read their website, find their LinkedIn, look up recent press mentions, and summarize what they do"]. Pick the right built-in tools and MCP servers, name the policy, create it, and tell me which agents I should attach it to.

Why it’s non-obvious: This is the Admin Agent’s specialty turned outward. You don’t think in terms of “which tools” — you think in terms of “what work I want done.” The Admin Agent translates your goal-language into a tool policy, creates it, and tells you which existing agents would benefit. You’re delegating the decision of what tools the work needs, which is the part most people get wrong by underestimating.

Go deeper

Tools vs. tool policies vs. credentials — three different things

These three terms get confused, so the short version:

A tool is a single capability — web_search, send_slack_message, list_github_issues. Tools come from two places: built into Auxot (web_search, web_fetch) or installed via MCP servers (GitHub, Slack, your internal APIs).
A tool policy is a named bundle of tools — your toolbelt. “Research toolkit” is a tool policy that bundles web_search and web_fetch. “Customer support tools” is a different policy that bundles a different set.
A credential is the secret an individual tool needs to actually work — your GitHub API token, your Slack OAuth, your CRM API key. Credentials live separately in Settings → Credentials and are attached to MCP servers within a tool policy. The agent never sees the raw credential; Auxot injects it server-side when the tool runs.

When something doesn’t work, the question to ask in order: does the agent have the tool policy attached? Does the policy have the tool turned on? Does the tool have the credential it needs? Three layers, each with its own UI page, each independently fixable.

What MCP servers actually are

MCP (Model Context Protocol) is the standard Auxot uses to plug custom tools into agents. If you’ve ever used a Slack bot, a Zapier integration, or a Jira plugin, the mental model is similar: a small piece of software that exposes a specific set of capabilities (read issues, send messages, query a database) and the agent can call those capabilities like functions.

Two kinds of MCP servers Auxot supports:

npm packages — installable from the npm registry, run as a local process. Example: @modelcontextprotocol/server-github exposes GitHub-specific tools.
HTTP endpoints — running somewhere reachable over HTTP. Useful for your own internal services that you want to expose to agents.

Setting up an MCP server is a more developer-leaning task — it requires picking the package or URL, configuring environment variables (often credentials), and validating that the server actually advertises the tools you expect. The page walks you through this when you click Add MCP Server on a tool policy detail page. If you’re not the developer on your team, this is usually a “ask the developer to set it up once, then everyone uses it” situation.

Per-agent overrides — disabled tools and aliases

When you attach a tool policy to an agent, you can override two things on a per-agent basis:

Disabled tools. A toolbelt has six tools clipped to it, but for this specific agent you only want it to use four. Click Edit Policy Overrides on the attachment and disable the two you don’t want. The toolbelt itself stays unchanged for every other agent.
Tool aliases. Some tools have generic names that the agent finds confusing in its specific role (“send_message” could mean Slack, email, or something else). Aliases let you rename a tool for this agent only — e.g., expose send_message as send_to_customer_support_slack. The underlying tool is the same; the agent just sees a name that fits its job.

Both are optional. Most attachments don’t need overrides. They exist for the cases where you want one toolbelt across many agents but a few of them need slightly different behavior.

Troubleshooting

The agent says “I don’t have access to that tool.” The tool policy isn’t attached, or the specific tool is turned off in the policy, or the tool is disabled via per-agent override. Check in that order.
The MCP server says it’s added but the agent can’t find its tools. MCP servers have to be validated before their tools become available. On the tool policy detail page, find the MCP server, click Validate. Auxot will discover the tools it advertises and let you toggle them on.
You get an HTTP 422 error when configuring fallback chains. You’re trying to set up a tool worker chain that loops back on itself (A falls back to B falls back to A). The server rejects cycles. Re-check the chain and remove the loop.
A tool policy disappeared from your list. It may have been deleted by another admin. Check your audit logs (when Tutorial 12 ships) or ask whoever else admins the account.
The agent is using the wrong tool. Sometimes the LLM picks tool A when you’d prefer tool B for a given question. Update the agent’s description (Tutorial 05) with rules like “Use web_fetch when given a specific URL; use web_search only when you don’t have one.” The agent will follow the rule.

Variations & edge cases

Free and Team tier: Tool policies work the same way. The only difference is no per-team scoping (Free is single-team, Team has one shared team).
Business and Enterprise tier: Tool policies can be scoped to specific teams. Useful when “Sales tools” should only be available to Sales agents, “Engineering tools” only to Engineering agents, etc. Configure team scope on the tool policy’s detail page.
Multiple tool policies on one agent. Stack as many as you need. The agent has access to the union of all attached policies. Conflicting per-agent overrides are resolved most-specific-first (overrides on the attachment win over the policy itself).
Rotating a key. Tool policy detail pages have a Regenerate Key option in the Danger Zone. Use this if a tool worker key has been exposed. Old workers using the old key will stop working immediately.
Deleting a tool policy. Settings → Tool Connector Keys → row → Delete Key. Deleting a policy detaches it from every agent that uses it. The agents stay; they just lose those tools. (No cascade deletion of the agents.)
Read-only for non-admins. Org admins create and edit tool policies. Other roles can see what’s attached to an agent but can’t change it.

Walkthrough

Open Auxot in your browser and sign in.

Step 2: Open Tool Policies (Tool Connector Keys)

Click Settings in the left menu, then Tool Connector Keys.

The page’s own helper text is the right way to think about this section: “Each key authenticates a tool worker and limits which tools that worker can offer your agents.” In plain English: each key is a named toolbelt with rules about which tools clip onto it.

Step 3: Create a new key

Click + Add Key at the top right of the keys card. A modal appears: “Create a new key with a scoped tool policy for external consumers.” All you need is a Name.

Pick a name that says what the toolbelt is for, not what’s on it:

“Research toolkit” — better than “web_search and web_fetch.”
“GitHub access” — better than “three GitHub MCP servers.”
“Customer support tools” — better than “web search plus FAQ lookup plus Slack.”

The reason for outcome-named keys is the same reason you give agents outcome-named jobs: you’ll attach this toolbelt to multiple agents over time, and a name like “Customer support tools” makes obvious which agents should have it.

Click Create. Auxot generates a raw key value and shows it to you once. Copy it if you’ll be using it from outside Auxot (e.g., from a tool worker running on another machine). If you’re just attaching it to agents inside Auxot, you don’t need to save the raw key — close the modal.

Tip: The “raw key” is the kind of thing a worker process running on a separate machine would need to authenticate. If you’re not running tool workers yourself, you don’t need to think about this — Auxot handles the wiring internally when you attach the policy to an agent.

Step 4: Configure the policy

The new key now appears in your Tool Connector Keys list. Click the row to open its detail page. This is where you decide what’s actually on the toolbelt.

Two sections:

a. Built-in tools

These are the tools Auxot ships with — web search, fetching the contents of a web page, etc. Toggle on the ones you want this policy to grant. The page shows them as checkboxes with short descriptions.

Common picks:

web_search — the agent can search the web for current information.
web_fetch — the agent can read the contents of a specific URL you (or it) provide.

Toggle on whichever fit the toolbelt’s purpose. “Research toolkit” probably wants both. “Customer support tools” probably wants web_fetch (to read documentation pages) but not web_search (to keep the agent focused).

b. MCP servers (advanced — skip on your first key)

MCP stands for Model Context Protocol. In plain terms: it’s how Auxot plugs custom tools into agents. If your team has built (or installed) a way to give agents access to your GitHub, your Stripe data, your internal API, your Notion workspace — those plug into Auxot as MCP servers.

This is the more developer-leaning part of tool policies. If you’re setting up your first toolbelt, skip this section — start with built-in tools and come back to MCP servers when you have a specific integration in mind. (Adding an MCP server requires running a tool worker process and configuring credentials; the page walks you through it when you click Add MCP Server.)

c. Team assignment (Business and Enterprise only)

Below the tools section is a Team Assignment area. By default, the toolbelt is available org-wide. If you’re on Business or Enterprise and want to restrict this toolbelt to specific teams, check the boxes for those teams here. (On Free or Team tier, this section doesn’t appear — your account has one team and the toolbelt is automatically available to it.)

Auto-save means there’s no Save button. Your changes are persisted as you make them.

Step 5: Attach the toolbelt to an agent

Open Settings → Agents and click on the agent you want to give the toolbelt to. (If you don’t have any custom agents yet, head back to Tutorial 07: Create an agent from scratch first.)

Scroll down to the Tool Policies card. Its helper text reads: “Link connector keys so this agent knows which external tools and built-in actions it may use.” Click Add Tool Policy (or Add Connector Key).

A picker appears: “Select a tool key to connect to this agent. You can configure disabled tools and aliases after attaching.” Pick the key you just created. Save.

The agent now has access to every tool clipped to that toolbelt. Test it — open chat with the agent and ask it something that requires one of the tools. “Search the web for the latest Auxot release notes and summarize them” is a good test for a key with web_search on it.

Tip: A single agent can have multiple toolbelts. “Customer support agent” might have both “Customer support tools” (for FAQ lookups) and “Research toolkit” (for general web search) attached. You’re not limited to one per agent.

Tip: If a particular agent should have access to most of a toolbelt but not one specific tool on it, click Edit Policy Overrides on the attachment to disable that tool for this agent only. The toolbelt itself stays unchanged for every other agent that uses it.

What’s next

→ Tutorial 07: Create an agent from scratch — if you don’t have a custom agent yet, build one first; tool policies are useless without an agent to attach them to.
→ Tutorial 09: Connect a cloud AI model — tools are how agents do work in the world; connecting an AI model is what lets them think about it. Both layers matter.
→ Tutorial 11: Create a shared Team API Key — for automations the whole team relies on. Different concept from a tool worker key, but related (both are bearer tokens that authenticate something to your Auxot).

Reference

Pages in Auxot: Settings → Tool Connector Keys (a.k.a. Tool Policies), Settings → Agents, Settings → Credentials
A tool policy contains: built-in tools (toggled on/off) + MCP servers (added and validated)
A tool policy is attached to: one or more agents (many-to-many)
Per-agent overrides: disabled tools, tool aliases
Team scoping: Business and Enterprise only
Permissions: org admins create/edit; all roles can see what’s attached
See also: Tutorial 07: Create an agent from scratch, Tutorial 09: Connect a cloud AI model