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

The description explains important non-obvious behavior: an unknown MMS-ID yields an empty result with a `hint` rather than fabricated data, while HTTP failures such as 401, 404, or timeout surface as `isError` and do not indicate holdings. This goes beyond the readOnly/openWorld/idempotent annotations by clarifying result semantics.

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 description is short, front-loaded with the main action, and the second part adds essential edge-case semantics without repetition. Every sentence earns its place.

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 simple get-by-ID tool, the description covers the most important call-specific behaviors (unknown ID vs. error handling). It does not describe the shape of a successful response, but given no output schema, the natural resource-return semantics and the provided error/hint distinction are sufficient for an agent to invoke it correctly.

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 description adds value around the `mmsid` parameter's unknown-ID behavior, but it does not explain `lang` or `include_availability`. The schema already provides descriptions for those parameters, so the description's contribution beyond the schema is limited rather than compensating for a coverage gap.

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 ('Ruft ... ab') and a specific resource ('eine einzelne Ressource der ETH-Bibliothek') keyed on MMS-ID, which clearly distinguishes it from the sibling search tools. The intent to retrieve one resource by ID is unambiguous.

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 makes clear this is for fetching a single resource by known MMS-ID, which gives the agent a clear context for using it. It does not explicitly name alternatives or exclusion conditions, but the ID-based retrieval semantics imply the appropriate use case relative to the search siblings.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint, so the safety profile is clear. Description adds basic context (returns overview) but doesn't elaborate on behavior beyond 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?

Single sentence, front-loaded, no wasted words. Appropriately sized for a simple info tool.

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?

Minimal description for a tool with no params and an output schema. Sufficient but could be more informative (e.g., what the overview includes).

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?

No parameters exist, so schema description coverage is 100%. Description doesn't need to add parameter info; baseline 4 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 'Gibt eine Übersicht über den ETH Library MCP Server zurück.' clearly states the verb (returns) and resource (overview). It distinguishes from sibling search/get tools by being a general info endpoint.

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?

No guidance on when to use this tool versus siblings. Implicitly it's for server info, but no explicit when/when-not or alternatives.

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

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

Beyond the readOnly/openWorld/idempotent annotations, the description discloses meaningful behavioral details: the `hint` field on empty results, the fact that the archive acts as a filter so outside holdings are not checked, and the instruction not to substitute guessed data for missing results. This materially helps an agent interpret search results correctly.

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 description is compact and front-loaded: the core action appears in the first sentence, and the FID-003 guidance is a separate, dense, non-redundant block. Every sentence earns its place with 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 read-only archive search tool, the description covers scope, usage, and the important empty-result behavior, which is the main non-obvious case. It does not describe the successful response payload beyond the `hint` field, but given the strong annotations and detailed input schema, the description is sufficiently complete for selecting and invoking the tool.

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 description itself adds no parameter-level detail, and context reports low schema description coverage. However, the visible input schema thoroughly documents the required `archive` enum and its meanings, plus `query`, `limit`, and `offset`, so an agent can still invoke the tool correctly. The description does not compensate for the reported coverage gap, but the schema carries the burden.

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 opens with a concrete verb ('Durchsucht') and a clear resource ('ein spezifisches Archiv oder eine Sammlung der ETH-Bibliothek'), so an agent can tell this is scoped to one archive or collection. It does not explicitly differentiate itself from siblings such as eth_search_resources or eth_search_by_type, which keeps it from the top score.

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 first sentence makes the usage context clear: search within a specific archive or collection. The FID-003 note adds an important operational rule about empty results and not guessing when the archive filter returns no matches, though it does not name alternative tools or give an explicit when-not-to-use statement.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable behavior beyond those: empty results carry a `hint` field pointing to the next attempt, the type filter means unchecked items outside the filter are not evaluated, and agents must not invent a hit. This is concrete, non-obvious behavior.

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 is front-loaded in one clear sentence, and the FID-003 note is a compact, necessary behavioral warning. Every sentence earns its place with no filler or repetition of schema details.

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?

The description is adequate for selecting the tool and understanding its core type-filtering behavior, and the FID-003 note adds useful response semantics. However, there is no output schema and the description does not explain the general result structure, sorting, or pagination behavior, nor does it position the tool against its search siblings.

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 description only adds meaning for resource_type via examples; it does not explain query syntax, limit/offset pagination, or open_access_only. The schema signal reports 0% coverage, so the description was expected to compensate, but it does not. The nested schema descriptions carry nearly all parameter meaning.

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 verb and resource: 'Sucht Ressourcen eines bestimmten Typs' with examples (Karten, Bilder, Archive). This distinguishes a type-filtered search from a generic resource fetch, though it never names sibling tools to make the differentiation explicit.

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?

No guidance is given about when to choose this tool over eth_search_resources, eth_get_resource, or eth_search_archive. The FID-003 note is about empty-result behavior, not about selecting the right tool, so the usage context is essentially absent.

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

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

Annotations already declare readOnly, idempotent, and non-destructive behavior)Skip; the description adds highly valuable behavioral detail: on empty results, the hint field should suggest the next attempt, and the tool must never fabricate a bibliographic reference to fill a missing hit. This goes well beyond what annotations provide and is critical for agent behavior.

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 description is compact, front-loaded with the core purpose, and includes only essential behavioral rules. The FID-003 label is slightly jargon-heavy, but every sentence earns its place and there is no redundant 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 read-only search tool, the combination of description and schema is sufficient: it identifies scope, required topic input, result limits, filters, and key anti-hallucination behavior. No output schema is present, but for a search operation the description handles the most important edge cases.

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 description adds no direct parameter guidance, but the nested input schema contains thorough descriptions and examples for topic, limit, resource_type, and open_access_only. Thus the schema carries the parameter semantics, and the description neither improves nor harms that 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 opens with 'Kuratierte Suche nach bildungsrelevanten Ressourcen in der ETH-Bibliothek', giving a specific verb, resource, and scope. It is clear that this is an education-focused library search, but it does not explicitly differentiate itself from sibling tools such as eth_search_resources.

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 terms 'Kuratierte' and 'bildungsrelevanten' imply when this tool should be used, but there is no explicit guidance on when to prefer it vs. alternatives like eth_search_resources or eth_search_archive. The usage context is implied rather than stated with exclusions or alternative routing.

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

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

The description adds substantial behavioral guidance beyond the annotations: it explains that an empty result is a meaningful statement about the catalog, instructs the agent to follow the `hint` field before reporting absence, and forbids guessing in place of missing results. This is valuable context not present in the readOnlyHint, openWorldHint, idempotentHint, or destructiveHint annotations. No contradiction with annotations exists.

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 description is well-structured: the primary purpose is front-loaded, followed by API context and search capabilities, and the FID-003 behavioral rule is clearly separated. Every sentence carries operational value, and the section about empty results earns its place because it dictates agent behavior. No filler or redundancy is present.

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 complex search tool with no output schema, the description covers the endpoint, supported search features, and the crucial empty-result/hint protocol. It is somewhat lacking in explicit return-format details and sibling differentiation, but the referenced `hint` field and API endpoint give an agent enough orientation to proceed confidently.

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 does not compensate by explaining the parameters. It mentions supported search modes and pagination at a high level, but provides no detail on the query format, sort options, filters, or defaults. The nested schema contains rich parameter descriptions, but the tool description itself adds little semantic value for parameter understanding.

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 opens with a specific verb and resource: 'Durchsucht den Katalog der ETH-Bibliothek mit über 30 Millionen Ressourcen.' It clearly identifies the tool as a catalog search operation and distinguishes it from siblings such as eth_search_archive or eth_get_resource by focusing on the general 30M-resource catalog. The mention of free-text, field search, facets, and pagination further clarifies its scope.

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 gives clear context that this tool is for searching the ETH library catalog and names supported capabilities, so an agent can infer when to use it. However, it never explicitly contrasts it with alternatives like eth_get_resource or eth_search_by_type, nor does it state when NOT to use this tool. Usage is implied rather than directly guided.

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