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

Annotations already mark readOnlyHint=true, so the safe, read-only nature is covered. The description adds that the tool returns registered endpoints and is meant for pre-scraper discovery, but it does not disclose pagination, filtering behavior, or output shape. It does not contradict 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 main clause is concise and front-loaded, stating the action and resource immediately. However, the trailing 'norm.' is a meaningless fragment that violates the standard that every sentence earns its place, and no parameter or return guidance is included.

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?

With six undocumented parameters, no output schema, and no description of the return format, the tool is under-specified for confident invocation. The usage cue 'use before building a scraper' helps but does not explain how to use the filters or interpret the response. More description is needed to make it 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?

Schema description coverage is 0%, and the description mentions none of the six parameters (lang, page, limit, publisher, access_rights, registration_status). The description does nothing to compensate for the schema's silence, leaving agents to guess the meaning and expected formats of the filters.

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 clear action (List) and a specific resource: registered machine interfaces of Swiss public bodies with their endpoints. The parenthetical '(API, Schnittstelle, Datendienst)' clarifies what counts as a machine interface, and the phrase 'use before building a scraper' reinforces its discovery role. It does not explicitly name sibling alternatives, so differentiation relies mostly on the 'machine interfaces' wording.

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 instruction 'use before building a scraper' provides concrete when-to-use guidance. However, it does not state when not to use this tool or mention relevant alternatives such as i14y.get_data_service or i14y.search_catalog. It is clear context without exclusions.

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