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

No annotations are provided, so the description carries the full burden. It discloses the grouping behavior and the enumeration of type categories, but says nothing about permissions, pagination, ordering, or result size. The return shape is covered by the output schema, which offsets some of the gap.

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 compact sentences, front-loaded with a category tag and verb. Every clause carries information (grouping axis, valid types, intended usage). No filler.

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-required-parameter list tool with an output schema, the description provides the grouping model, the type vocabulary, and the intended discovery workflow. Remaining gaps (ordering, pagination, omitted-filter behavior) are minor rather than blocking.

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 0% and the schema defines no enum for `type`, so the description's enumeration ('concept, workflow, interface, troubleshooting, decision') is genuinely additive meaning. However, it doesn't state filter matching semantics or the behavior when `type` is omitted (absence of filter vs error).

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 (List) and resource (EMEP topics) and specifies the grouping axis (type) with the exact enum values. It names the sibling ep_search, giving an agent a clear anchor to distinguish it, though it doesn't contrast with other retrieval siblings like ep_graph_traverse or get_guidance.

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 discover what guidance exists before ep_search, or to browse the pack.' This positions it as a precursor/discovery call. It lacks any when-not guidance or alternatives when a topic is already known.

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