invariance_eval_scorer_list

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

Annotations already declare readOnlyHint=true and openWorldHint=true, covering side-effect safety and mutability. The description adds useful context beyond these: it specifies that the list is scoped to 'visible to the calling agent' and that results are 'paginated'. These details inform the agent about scoping and response structure, which the annotations do not. No contradictions with 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 a single, concise sentence with no filler. It front-loads the core action ('List scorers') and adds the key modifiers ('visible to the calling agent' and 'paginated') efficiently. Every word contributes meaning, and it is appropriately brief for a simple list operation.

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?

The tool is simple (no output schema, no nested objects, only 2 optional params), and the description covers the essential action. However, it does not clarify the difference from the sibling 'invariance_eval_scorers_list_builtin', nor does it specify default pagination behavior or whether it includes built-in scorers. Given the existence of a very similar sibling, this ambiguity makes the description somewhat incomplete for correct tool selection.

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 50%: only 'cursor' has a description, while 'limit' does not. The description mentions 'paginated', which indirectly relates to both parameters, but does not explain the semantics of 'limit' (e.g., page size) beyond the schema's numeric constraints. The cursor parameter is already well-defined in the schema, so the description adds little value for that. Given moderate coverage, the description provides minimal compensation.

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 action ('List') and resource ('scorers') with a scope ('visible to the calling agent') and a key behavior (paginated). It distinguishes from the sibling 'invariance_eval_scorers_list_builtin' by implying it lists non-builtin or agent-specific scorers, though not explicitly. This is clear enough for an agent to understand the core purpose, but could be more explicit about what 'scorers' include.

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?

No guidance is provided on when to use this tool versus alternatives like 'invariance_eval_scorers_list_builtin' or other listing tools. The description only states what it does, not when to prefer it. There is no mention of conditions, timing, or relationship to sibling tools, leaving the agent to infer usage.

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