list criterion templates

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

Beyond the readOnlyHint/idempotentHint annotations, the description discloses that the endpoint is static and free, requires only authentication, and returns a fixed set of 11 templates. It also explains important semantic behaviors: universal templates are safe unscoped, non-universal ones should be scoped, and trace-unit templates need trace-scoped labels. This is rich behavioral context.

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 long but every sentence earns its place: purpose, endpoint, auth scope, full return shape, template count, and behavioral notes. The most decision-relevant information is front-loaded, and the detailed notes are justified because no output schema exists to carry that burden.

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 zero-parameter read-only list tool, the description covers everything an agent needs: the exact endpoint, auth requirement, response object shape with field semantics, example slugs, and usage caveats about universal/trace templates. There is no output schema, so the inline return specification is essential and is present.

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 input schema is empty with 100% coverage, so no parameter documentation is needed. The description adds value by specifying the output record shape and field meanings, which matters more here since there is no output schema. The score reflects the baseline for a zero-parameter tool with complete schema coverage.

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 action and resource: listing shipped judge-criterion templates, and explicitly gives the HTTP route GET /v1/criteria/templates. It clearly distinguishes these read-only template entities from sibling tools like list_criteria or list_dedicated_templates by framing them as starting-point judge prompts for later instantiation.

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 explains when this tool is useful: to obtain a starting-point judge prompt and instantiate it via POST /v1/criteria with an edited judge_prompt. It also adds practical usage warnings, such as templates needing alignment against workspace labels and task-specific templates needing traffic scoping. It does not explicitly name alternatives, but the instantiation workflow makes the intended context clear.

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