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

Annotations already cover readOnly/idempotent/non-destructive, and the description reinforces this with 'Read-only' plus ordering behaviour ('newest first') that the annotations do not express. It also discloses the returned fields (type, Stichtag, financial_year, document_ref, format, parsed flag) and the added country/prefixed company_id. It does not mention any result cap or pagination, which is the main remaining 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?

Content is front-loaded with purpose first, then Parameters and Returns blocks, so an agent can scan it quickly. The German sample query is useful as a trigger phrase but is the one element that could be trimmed; nothing else is redundant.

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-parameter read tool this is complete: input format, geographic scope, alternative routing, and return shape are all covered. An output schema exists, yet the summary of returned fields is short enough to add value without bloat.

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 0%, so the description carries the burden and does so: it marks company_id as required, specifies the 'AT:{fnr}' format, notes a bare FNR is accepted, and explains that the returned company_id is prefixed. That compensates well for the empty schema, though it does not validate edge cases such as an unknown FNR.

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 resource and verb: 'Chronology of a company's filing documents (metadata, newest first)'. It immediately scopes the tool to the AT register and names the sibling it is not (get_document for the German abstract, get_document_text for extracted text), so an agent can distinguish it from those tools 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 explicit when-to-use context via the example query about Urkunden/Jahresabschlüsse, an explicit exclusion ('Austria only; Germany serves no filing chronology'), and names the alternative call to make instead. It also explains the downstream step: feed a document_ref to get_document or get_document_text.

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