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

Annotations already provide readOnlyHint=true, covering the safety profile. The description adds useful behavioral context about what the tool returns, especially valuable because there is no output schema: a dated chronology with beats linked to source records, significance, watch-outs, and evidence. It does not discuss auth or rate limits, but those are less critical for a simple read-only lookup.

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?

A single front-loaded sentence uses a colon to organize five distinct output components with no filler or repetition. Every phrase carries informational weight, making it easy for an agent to quickly understand what the tool provides.

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 read-only tool with one parameter and no output schema, the description adequately communicates the main return components and single-theme scope. It could have explicitly referenced list_themes as the source of theme_id, but that relationship is already documented in the input schema, so the overall definition is sufficiently complete.

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 covers theme_id fully, including the note that it comes from list_themes and may optionally include the hs:theme: prefix. The description itself adds no parameter-level meaning, so it does not exceed the baseline set by the schema's 100% parameter 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 names the resource ('one theme'), implies the retrieval operation through 'in full', and specifies the returned contents: setup, dated chronology with source-record links, importance, watch-items, and evidence. It clearly suggests the distinction from list_themes by emphasizing a single theme, though it does not name a sibling or use an explicit verb.

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 implies use when needing a complete chronology for one theme rather than a list of themes or other entity-specific details. However, it never explicitly states when to choose this tool over list_themes or other siblings, nor does it give any 'not for' guidance.

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