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

Annotations already establish readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered structurally. The description adds genuine context beyond that: the return format is structured markdown, and omitting the topic yields an index of all topics rather than an error. Nothing contradicts the 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 purpose and return format are front-loaded in the first two sentences, and the topic routing follows. The long list of topic examples partially duplicates the enum, costing a little space, but the structure remains efficient and scannable.

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 single optional enum parameter with no output schema, the description supplies everything needed: what it returns (markdown), how to address a topic, and the zero-argument fallback. There is no gap an agent would hit when invoking 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?

Schema description coverage is 100% and the enum already lists all twelve topics plus the omit-to-get-index behavior, so the description's topic enumeration largely restates structured data. It adds no syntax or selection nuance beyond what the schema documents; baseline 3 applies.

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 verb and resource: retrieve guidance as structured markdown for a requested topic. It is unmistakably a meta/help tool, so an agent can tell it apart from every data-fetching sibling such as nevent_list_campaigns or nevent_analytics_query without opening a 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?

It gives an explicit trigger condition — call it when unsure which tool to use or how to handle an error — and maps topics to intents (workflows for patterns, errors for error codes, tenants for multi-tenancy). It does not state when NOT to use it (e.g. once you have identified the right sibling), which is the only missing piece.

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