Tools are not neutral in an agent system.

An agent chooses tools based on names, descriptions, schemas, parameter hints, and previous results. A tool registry is therefore not just a list of callable functions. It shapes the agent’s action path.

That is why a tool registry is a control surface.

Tool descriptions change behavior

When a human reads a tool list, they bring context and risk judgment. When an agent reads a tool list, it mostly relies on descriptions, surrounding context, and model inference.

If a tool describes its capability too broadly, the agent may misuse it.
If a tool hides side effects, the agent may treat a dangerous action as a query.
If an MCP server exposes file, network, credential, or account capabilities, the agent may trigger it at the wrong time.
If a tool description is polluted, the agent can be steered toward the wrong workflow.

The tool description is not a documentation detail. It is part of the execution boundary.

The supply-chain boundary has expanded

Traditional software supply-chain governance focuses on packages, dependencies, build scripts, CI access credentials, and deployment permissions. AI agents expand that boundary.

The governed surface now includes:

  • MCP servers;
  • plugins and connectors;
  • local shell scripts;
  • auto-downloaded binaries;
  • IDE extensions;
  • package installation and postinstall behavior;
  • model providers, access configuration, and proxy layers;
  • skills, AGENTS.md, hooks, and daemons;
  • descriptions exposed to the model through the tool registry.

Together, these objects decide what the agent can see, what it can call, what it will trust, and how far an action can advance.

A minimal tool registry contract

A mature project does not need a heavy tool platform on day one. But it should define a registry contract for agent-visible tools.

Each tool entry should answer:

  • What problem does it solve?
  • Who owns it?
  • Which paths, networks, or services can it read?
  • Can it write files, send requests, post content, deploy, delete, or mutate external state?
  • Does it need credentials?
  • Can its output be used as evidence?
  • After failure, should the system retry, roll back, ask, or halt?
  • Does the tool run under allow, ask, block, or read-only mode?
  • When should the tool not be used?

The last question matters. Agents need to know capability, but they also need boundaries.

MCP is not a security boundary by itself

MCP is useful because it standardizes tool integration. A standardized interface is not the same thing as a security boundary.

One MCP server may be a read-only search tool. Another may operate on the filesystem, call external APIs, modify project state, or trigger business actions. To the agent, both may appear simply as tools.

The governance questions are:

  • What capabilities does this MCP server expose?
  • Are those capabilities described accurately?
  • Which parameters have side effects?
  • Are there path, domain, method, or credential limits?
  • Does the call enter the execution trace?
  • Do high-risk calls pass through an autonomy gate?

Plugins, hooks, CLI tools, and local scripts should enter the same view.

What this means for open-source agent engineering

If issue-driven, autorun, or project-specific harness work becomes reusable infrastructure, tool governance cannot be a late add-on.

The smallest useful version does three things:

  • define a machine-readable tool registry manifest;
  • label each tool with side effects, risk level, and evidence value;
  • make the scheduler or worker read those fields before execution.

That is more stable than a prompt that says “please use tools carefully.”

Core judgment

An agent’s tool surface is its power surface.

When tools, MCP servers, plugins, local scripts, and dependencies can be invoked by the model or influence model judgment, the tool registry is no longer a developer convenience. It is part of operational governance and part of the AI software supply chain.