Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations supplied, the description carries the full burden, and it does substantial work: arguments are validated against the tool's native schema, the identical handler runs with identical permissions, and it explicitly frames itself as 'dispatch, not a bypass'. What it omits is failure behavior — what happens with an unknown or misspelled tool name — and any warning that dispatched tools may be destructive or mutating. Given this wrapper can reach write tools, that gap keeps it at 4 rather than 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, front-loaded with the core action, with every clause earning its place — the permissions assurance and the describe_tools pointer are both load-bearing. No redundancy with the title 'Run Tool' and no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a two-parameter dispatch tool with a nested free-form args object, no annotations, and no output schema, the description covers validation, permission equivalence, and name discovery — the elements an agent needs to call it correctly. It could go further on how results are returned (passed through verbatim from the native handler?) and on error handling, which matters for a generic wrapper.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents both parameters, establishing a baseline of 3. The description reinforces the relationship between them (name comes from describe_tools, args must match that tool's input_schema), but it does not add format details, examples, or edge cases beyond what the schema states.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description gives a specific verb (invoke/dispatch) and resource (any BlackOps catalog tool not on the default surface) and explicitly names the lookup sibling, describe_tools. An agent can distinguish use_tool from describe_tools and from the directly-exposed siblings without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It states the selection condition (a catalog tool that is not on the default surface) and prescribes the prerequisite workflow: look up names and input schemas with describe_tools first. The converse — prefer calling a directly-exposed sibling directly instead of going through dispatch — is only implied by 'not on the default surface', so it falls short of the explicit when-not-to-use clause that would earn a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.