Auxot
Tutorials Docs Pricing Login

Define a tool policy

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

Plus: three prompts to paste into Admin Agent chat — narrow which tools belong in a policy, find scope mismatches across agents, or describe an outcome worth automating **so you're not flipping toggles blind**.

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 ([Create an agent from scratch](/tutorials/create-an-agent-from-scratch)). 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 assembled, attached to at least one agent — so the next chat you start can end with fetched facts instead of *I'll look that up separately*.

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

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 permission to reach for capabilities that touch the outside world: search the web, read GitHub, post to Slack, or query an internal API. Without one, ask all you want in Chat: replies stay conversation-shaped. With one attached, ask in Chat. After your message, the agent may call a baked-in integration when the wording clearly needs it (you triggered the exchange; Auxot executes the tools when the assistant asks for them). That’s different from unattended background work (Run a workflow hooks if you automate the first prompt later).

Think of a tool policy as a reusable bundle you assemble once for many agents: same mental model Generate your first API key used about keys bridging into other apps, just scoped to connector keys here. You put web search in one policy, repository access in another, Slack messaging in a third; agents that share a policy inherit the same reach when someone chats them up.

Auxot calls these bundles “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. The next time an agent would have said ”I’ll have to look that up separately”, it won’t.

You build a named tool policy. You toggle which integrations belong in it. You attach that policy to whichever agents should have the same reach. Someone opens Chat, selects that agent, sends a prompt; when the wording needs it, the assistant can invoke a tool Auxot exposes for them to finish the reply.

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 Connector Keys (or Tool Policies, depending on your version).
  3. 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.
  4. 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.
  5. 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? Policy attached. Proof is still you sending a deliberate prompt in Chat: ask for something only a tool answers (for example “pull the Auxot changelog from last month and summarize the shipping notes”).

The agent can do that?

You could fiddle with tool policies quietly in Settings, or use the same prompt first rhythm as Add your first context file: paste a thoughtful ask, grab the reply, tweak. Three prompts underneath: recommend tools for one job, find overscoped policies, describe an outcome loud enough he’ll wire toggles you’d otherwise hunt manually.

1. Narrow the policy before you attach it to anyone

Admin Agent chat, fresh message:

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: Most orgs slap web_search on every policy just in case. Run the gray-box prompt once: the reply inventories what Auxot ships plus anything MCP configs advertise, squared against that job wording you pasted. Beats guessing across five tabs.

2. Audit mismatches nobody scheduled time for

Same thread, another ask:

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 expand quietly: you widen one for an agent and forget that other agents share it, or prose promises live research nobody attached web_search to. Paste the audit prompt once; mismatches spill out grouped by agent so you aren’t rebuilding the spreadsheet from memory after a stray Friday deploy.

3. Talk in outcomes: Admin Agent configures the connectors

Build me a tool policy called "[name]" that gives an agent everything it needs to [describe the goal — e.g., "research a business-to-business 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: Most people stall on MCP server vocabulary before they stall on approval; that’s fair. Describe the job in prose first; Admin Agent drafts the policy contents after you’ve sent this prompt. Auxot applies what he configures, but you’re still meant to skim what flipped and push back before you call it shipping-ready.

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, or 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. “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, or 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, and 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 tool policy has six tools in 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 tool policy 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 tool policy 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 View your audit logs or ask whoever else admins the account.
  • The agent is using the wrong tool. Sometimes the model picks tool A when you’d prefer tool B for a given question. Update the agent’s description (Give your agent its job description) 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

Step 1: Sign in

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 tool policy with rules about which tools belong in 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 tool policy is for, not what’s in 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 tool policy 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 in the tool policy.

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 tool policy’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, or 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 tool policy, 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 tool policy is available org-wide. If you’re on Business or Enterprise and want to restrict this tool policy 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 tool policy 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 tool policy to an agent

Open Settings → Agents and click on the agent you want to attach the tool policy to. (If you don’t have any custom agents yet, head back to 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 in that policy. 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 tool policies. “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 tool policy but not one specific tool in it, click Edit Policy Overrides on the attachment to disable that tool for this agent only. The tool policy itself stays unchanged for every other agent that uses it.

What’s next

Reference

Browse all tutorials