humanizer_assess_pair

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

With no annotations, the description carries full disclosure burden. It usefully reveals the blinding mechanism ('the assessor is not told which version is the rewrite') and that the faithfulness check enumerates invented, lost, or changed details — real behavioral value. It omits scoring scale/range, determinism, latency/cost, and whether results are persisted.

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?

Four short sentences, front-loaded with the outcome (blind scores + faithfulness check), followed by placement guidance and two clarifying facts. Every sentence adds information; only mild compactness ('blind before and after scores') slightly obscures the mapping to original/rewrite.

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?

No output schema exists, and the description only loosely sketches the return shape (scores plus a list of invented/lost/changed details) without indicating score range or structure. For a stateless three-parameter evaluation tool this is workable but leaves the response format and the undocumented backend param unresolved.

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%, so the description must define all three parameters. It clarifies the roles of original and rewritten (the latter being the caller's own rewrite), but the 'backend' parameter is given no meaning at all, and no format or size expectations are stated for the text inputs.

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 action: blind before/after scoring of an original vs. a user-supplied rewrite, plus a faithfulness check. This clearly separates it from the generation tools (humanize_text) and from single-text assessment, though it never names the closest siblings (assess_text, compare) explicitly.

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?

'Use this after rewriting text yourself' gives a clear triggering condition — the rewrite must already exist and be produced by the caller, not the server. It stops short of saying when to prefer assess_text or compare instead, so alternate routing is left implicit.

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