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

No annotations exist, so the description carries the disclosure burden. It conveys the key mechanic (arbitrary tool invocation with opaque JSON args) but never warns that it can trigger mutation/destructive underlying tools, nor how errors from the wrapped tool surface. That's a meaningful gap for a proxy that can invoke anything.

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 short sentences, front-loaded with the action, then the calling convention, then the prerequisite. The example JSON is concrete and earns its space.

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?

With no output schema, the description should explain what a call returns, but it never says the response is the wrapped tool's output or how failures are reported. For a two-required-param dispatcher this is adequate but leaves the agent guessing on result handling.

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 100% and the schema already documents both parameters, including that 'name' comes from rea_search. The inline example of args_json is a small value-add but adds no syntax rules, quoting caveats, or nesting guidance beyond the 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?

States a specific verb and resource ('Run any REA tool by name') and immediately clarifies the calling convention, which distinguishes it from the lookup siblings rea_search and rea_describe. An agent knows this is the generic dispatcher without opening the 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?

Explicitly prescribes the workflow: fetch the schema via rea_describe first, and the schema names rea_search as the source of valid tool names. It doesn't say when NOT to use this (e.g. prefer a direct tool if available), so it falls short of 5.

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?

No annotations are provided, so the description carries the full burden. It discloses that the output is markdown containing a full input schema and example, which implies a read-only retrieval, but it does not explicitly state read-only behavior, error handling, or any other operational traits.

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?

Two sentences, front-loaded with the action and output, followed by precise workflow placement. Every sentence earns its place with no redundancy.

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?

With one fully documented parameter and no output schema, the description adequately explains what is returned: the full input schema and example as markdown text. Minor gaps include failure behavior when the tool name is not found, but the core context is complete.

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%, and the single parameter is already documented as 'Exact REA tool name from rea_search.' The description adds no parameter-specific meaning beyond the schema, so the baseline 3 applies.

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 specific verb and resource: 'Get one REA tool's full input schema and example as markdown text.' It clearly distinguishes the deliverable from search or call operations, though it does not explicitly differentiate from rea_investigate.

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 gives explicit sequencing: 'Use after rea_search, before rea_call.' This tells the agent exactly where the tool fits in the workflow and when to invoke it.

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?

No annotations are provided, so the description carries the burden. It does disclose the return shape (markdown summary with evidence ids) and that the tool autonomously picks an inspection routine, but it says nothing about side effects of "opens the target" (does it launch/execute a binary?), cost or latency of the depth levels, or whether any state is written. Those gaps matter for a tool whose input is a local executable.

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 short sentences, front-loaded with the action and ending with the selection rule. The inline question example duplicates the schema's example, a small redundancy, but there is no padding.

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?

With no annotations and no output schema, the description does the right work: it explains the return value (markdown plus evidence ids) and the first-contact positioning. Remaining gaps around side effects of opening a target and depth tradeoffs are the only things an agent might still need.

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 target, question, and depth (including its enum and default). The description only reinforces the single-question framing; it adds no guidance on choosing quick vs standard vs deep in terms of cost or output depth, so it sits at the baseline.

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?

States a specific verb and resource ("Investigate a target with one question") and then spells out the mechanism: opens the target, runs the appropriate REA inspection, returns a markdown summary with evidence ids. It explicitly distinguishes itself from the sibling rea_search, so an agent can tell them apart without opening schemas.

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?

"Prefer this over manual rea_search for first contact" gives an explicit alternative and the condition that selects it. It does not cover when to prefer rea_describe or rea_call instead, so the routing guidance is clear but incomplete across the full sibling set.

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?

With no annotations, the description carries the full burden. It does disclose the important behavioral trait that results are summary-level only ("no full schemas"), which prevents an agent from assuming it can invoke directly from search output. However, it says nothing about result ordering, truncation, or what happens when nothing matches.

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 short sentences, each doing distinct work: what it searches, what it returns (and notably what it does not), and where to go next. Purpose is front-loaded and there is 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?

There is no output schema, so the description must explain returns, and it does so concisely. Combined with full schema coverage on the three parameters and the stated follow-up path, an agent has what it needs to call this correctly; only empty-result behavior is unaddressed.

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 100%: query, limit (1-10, default 5) and the six-value domain enum are all documented in the schema itself. The description adds no extra meaning about query syntax or domain semantics beyond the schema's own examples, so baseline 3 applies.

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?

States a specific verb and resource ("Search REA capabilities by keyword") and immediately defines the return shape: tool names plus one-line descriptions, explicitly without full schemas. That return-shape clause separates it cleanly from rea_describe and rea_call without the agent needing to open 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?

"Call rea_describe for one tool, then rea_call to run it" makes this the entry point of an explicit discovery chain and names both alternatives. It stops short of stating a negative condition (e.g., skip this if you already know the exact tool name), which keeps it from a 5.

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