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

Even beyond the readOnly, openWorld, idempotent, and destructive annotations, the description discloses deduplication behavior, the exact/semantic/keyword match categories, inclusion of generated-only disabled tools, safety-flag provenance, and compact-by-default responses. This is substantial behavioral transparency and does not conflict with any annotation.

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?

The description is front-loaded with the most important instructions ('Call this first'), followed by the dispatch contract, match behavior, filters, and parameter documentation. Despite its length, the content is dense with useful detail and parallel in structure, making it well organized for an 8-parameter discovery tool.

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 tool with 8 parameters, multiple filter dimensions, sibling routing, and a rich output schema, the description is complete: it covers when to call it, what the results contain, how matches are labeled, how to control schema verbosity, and how to dispatch the selected tool. Nothing critical is left to inference.

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 0%, but the Args section fully compensates. It defines all 8 parameters, giving query example usage, top_k range and default, include_schema trade-offs, platform/server examples, capability values, origin values, and operation_id meaning. The description therefore adds crucial semantics that the schema alone entirely lacks.

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 begins with a specific action ('Find tools by query') and explains the search mechanism ('semantic search + tool-name keyword match'). It distinguishes itself from the sibling invoke tools by stating that the returned `name` is the value to pass to invoke_read_tool or invoke_tool, so the purpose is unmistakably a discovery tool.

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?

The description is prescriptive: 'Call this first when you need an action.' It also tells the agent when to use include_schema ('only when you need the full JSON schema'), when to keep responses compact, and how to route a discovered tool to the correct sibling. It also explains the conditions under which filters should be applied.

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

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

The description adds significant behavioral detail beyond the annotations: it refuses non-read-only tools, and thoroughly explains cursor semantics including process-locality, integrity protection, time-limits, binding to tool name/arguments, and error behavior for invalid cursors. This goes well beyond the readOnlyHint/idempotentHint annotations.

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?

The description is front-loaded with the main purpose and usage guidance, followed by a structured 'Args' section that details cursor behavior. The cursor explanation is long but necessary and well-organized. Overall, it is appropriately concise without being under-specified.

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 dispatcher tool with no output schema, the description covers the primary use case, restrictions, and error behavior for cursors. It could mention how arguments should be structured or what the return format looks like, but these are somewhat incidental given the tool's nature. It is sufficiently complete for an agent to invoke it correctly.

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?

The cursor parameter is explained in great detail, which is crucial for its opaque nature. However, the 'arguments' parameter is not described at all beyond the schema, and 'name' is only implied as coming from find_tool. With 0% schema description coverage, the description partially compensates but leaves gaps for the arguments parameter.

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 clearly states it calls a read-only Aruba tool by name, which is a specific verb-resource pairing. It distinguishes itself from the sibling invoke_tool by explicitly limiting to read-only tools.

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 explicitly says to use this tool for read-only tools and to use invoke_tool for write/destructive tools after explicit user intent. This provides clear when-to-use and alternative guidance.

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

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

Beyond annotations, the description reveals that arguments go through MCPServer validation/coercion, the router's request Context is forwarded, and destructive tools reach confirmation elicitation. This is rich behavioral detail that significantly helps an agent anticipate side effects and prerequisites.

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?

The description is front-loaded with purpose, followed by an example and then technical details. It is slightly dense but every sentence contributes value; the example and the explanation of ctx injection are both necessary for correct use.

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?

Given the tool's generic nature and absence of an output schema, the description covers purpose, usage, and behavior thoroughly. It does not mention return values or error handling, but for a dynamic dispatcher these may be tool-specific and not appropriate to detail. Overall, it is sufficiently complete for selection and invocation.

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 coverage is 0%, but the description compensates by explaining 'Arguments is a kwargs dict' and providing a working example. It clarifies that name comes from find_tool and that only name + arguments are passed. This adds meaningful semantics beyond the raw schema.

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 states a clear, specific action: 'Call an Aruba tool by name (from find_tool).' It provides a concrete example (invoke_tool("create_vlan", {...})) and distinguishes itself from siblings by mentioning its role in dispatching destructive ops tools, which is not true of invoke_read_tool.

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?

The description gives clear context: use this after find_tool to call any tool, and it explains how the dispatch works. However, it does not explicitly mention when to prefer invoke_read_tool or provide exclusion criteria, so it stops short of full guidelines.

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