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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint=false, so safety and determinism are covered. The description adds that this is a static vocabulary listing used to validate inputs, but it does not disclose output volume (e.g. 104 groups) or whether the vocabularies can shift between server versions.

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, front-loaded with the verb and resource, then the use case. The long enumeration of vocabularies is somewhat duplicative of the enum but still earns its place by signalling scope up front.

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?

A single required parameter, fully documented in the schema, plus an output schema that carries return values. The description supplies the missing 'why' — that these vocabularies define valid inputs for the sibling tools — so an agent has everything needed to call it correctly.

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 coverage is 100% and the enum description already spells out each topic with element counts, so the schema does the heavy lifting. The description restates the same category list without adding format, sizing or selection guidance beyond it.

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 verb ('Enumerate') plus resource ('the reference vocabulary this server uses') and then enumerates exactly which vocabularies are covered. The agent can distinguish this static reference tool from the sibling feature-lookup tools without opening any schema.

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 says when to use it: 'to build valid inputs for the other tools and to see which target browsers can be evaluated.' That is a clear positive trigger, but there are no explicit exclusions or named alternatives (e.g. 'do not use for looking up a feature — use browsercompat_get_feature').

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