Skip to main content

Toolsets

Concepts

A Toolset is a named, curated set of MCP tools — drawn from one or more servers — that you attach to Access Bindings by name. It's AIControls' answer to a "virtual MCP server": a reusable grantable unit, without a second endpoint to operate or a separate access-control system to reconcile.

What a Toolset is​

Where an Access Binding answers who may use what, a Toolset packages the what so it can be reused:

kind: MCPToolset
metadata:
  name: github-read
spec:
  description: "Read-only GitHub surface for analytics teams"
  selectors:
    - servers: ["github-mcp"]
      tools: ["get_issue", "list_pull_requests"]
    - servers: ["*"]
      tools: ["read_*"]

A binding references toolsets by name; at enforcement time the binding's own tool selectors and every referenced toolset's selectors are combined. Editing a toolset updates every binding that references it — curate once, grant everywhere.

Compiled away, not a second engine​

A Toolset is data, not policy. When a binding references one, the compiler inlines the toolset's selectors into the same mcpaccessbinding:<binding>:tools policy it would produce for inline selectors — there is no separate routing or ACL layer. This is the distinction from other vendors' "virtual MCP servers", which run as a parallel gateway: a Toolset grant is provably the same audited CEL the rest of your governance runs on.

  • Deny works too. A deny-mode binding referencing a destructive-ops toolset blocks that whole surface for its subjects; deny still wins over any allow.
  • Dangling references are safe. If a referenced toolset is deleted or disabled, it contributes nothing — a binding never fails open into "all tools". Deleting a toolset that any binding still references — enabled or disabled — is refused; disabling the binding is not enough, the reference must be removed.

Description overrides​

A Toolset can override the description a tool advertises in tools/list. This is presentation only — the tool's canonical name, routing, policy evaluation, and audit records are unchanged; only the text shown to the model is replaced. Two uses:

  • Normalize inconsistent or verbose upstream descriptions.
  • Sanitize a description that has drifted, masking it with operator-controlled text while the change is under review — a companion to tool-definition pinning.

Building Toolsets from usage​

Because AIControls sees every tool call, it can propose a Toolset containing exactly the tools an agent or team actually used recently. That is the least-privilege on-ramp: observe real usage, bundle it into a Toolset, attach it to a binding, then switch the server to a default-deny posture. What was never used is never granted.

See also​

Last updated on