List block templates

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the read-only safety profile is known. The description adds valuable context: that classic themes yield an empty result and that template parts are included, which conditions agent expectations about output. 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?

Two sentences with zero fluff. The primary action is front-loaded, followed by the critical limitation and alternative. Every word contributes to understanding, making it highly efficient for an agent to parse.

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 simple read-only list tool with two optional parameters, the description covers what it does, when to use it, and a key edge case (classic themes). It lacks details about the return format (e.g., a list of names/objects), but no output schema is provided and the tool is straightforward, so this is a minor gap. Overall, an agent can correctly decide whether to invoke it.

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 already fully describes both parameters (kind enum and site_id usage) with 100% coverage, so the description has little to add. It does not elaborate on parameter values beyond the schema, though the examples (front-page, single, archive) are illustrative rather than parameter definitions. This meets the baseline for fully documented parameters.

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 clearly states the tool lists block theme templates or template parts, with specific examples. It distinguishes itself from related tools like get_template (which retrieves a single template) and list_theme_files (which handles theme files for classic themes). The verb 'list' and resource 'block theme's templates' are precise and unambiguous.

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 states when to use (block themes) and when not to (classic themes), and points to the alternative ('use the theme file tools instead'). This gives an agent clear routing guidance and prevents misuse on classic themes where the tool would return nothing.

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