Get review summary (deprecated)

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

With no annotations, the description carries the full burden, and it does disclose the key behavioral trait: this tool is a passthrough/delegation with identical behavior to get_feedback. That said, it offers zero transparency about side effects (likely none), error behavior, rate limits, or what the return structure looks like—acceptable for an alias, but the burden of behavioral disclosure is otherwise completely unaddressed beyond the 't' statement.

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?

Six words: 'Compatibility alias for article_review_get_feedback.' Zero filler, no redundancy with the schema, front-loaded, and the deprecation context is reinforced in the title. Every element carries meaning, and the trailing period is about the only thing that could have been cut—it's a model of telegraphic precision.

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 deprecated compatibility shim with one obvious parameter and no output schema defined, this is remarkably complete—an agent can determine everything it needs by following the alias pointer to get_feedback. It's missing a note about return format or behavior, but given the tool's design (valid reasons for creating an alias are virtually nil) and the stated deprecation, adding more text could easily do more harm than good. A brief 'returns the same as get_feedback' would have made it a 5.

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%, and the description does nothing to document sessionId—despite the fact that it's a trivially self-explanatory, required string with no enums or nested objects. Since coverage is 0%, the description was supposed to compensate, which it completely fails to do. A strong scorer would have at least mentioned 'the session whose review summary is returned.' Still, the sole parameter name is so self-evident and there are no hidden gotchas (no enums, no nested objects), so the damage is minimal.

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 title 'Get review summary (deprecated)' combines a clear verb+resource with a deprecation flag, and the description states it's a 'Compatibility alias for article_review_get_feedback,' which precisely positions it relative to the rest of the family. It's clear and distinguishes itself by pointing to the canonical implementation, though it never says what a review summary actually is (delegating that responsibility to get_feedback). It falls short of a 5 because the purpose of the underlying operation is only inferred from the sibling name.

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 names the exact alternative (article_review_get_feedback), which is the single most important piece of usage guidance for a deprecated alias—an agent reading this knows precisely where to route the call. The deprecation signal in the title further implies 'use the other one for new code.' However, it never explicitly states 'for new code, use get_feedback instead' or explains when the alias itself should be used (legacy callers only), leaving the when-to-use guidance slightly implicit.

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