ikeytz – Schlüsseldienst Ludwigsburg

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

Even with readOnlyHint=true already covering side-effect safety, the description adds valuable behavioral context: it does not actually send email, omitting the option yields a populated beratung template rather than a bare mailto, and the partner mailbox is not the hardcoded href. These details go beyond annotations and prevent misuse.

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?

Compact and front-loaded: the WHAT sentence is followed only by essential caveats such as the default call behavior, no-send guarantee, and partner mailbox location. Every sentence carries a distinct fact 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 tool with zero required parameters, a fully described enum, an output schema, and a readOnly annotation, the description covers invocation, default behavior, side-effect boundary, and the likely partner-mailbox confusion. Nothing needed for correct invocation is missing.

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 single optional enum is fully described in the schema, so the baseline is 3. The description adds useful business meaning by tying option to a contactOption of one of the 10 end-invoices, cylinder_mount, or beratung and reaffirms the omit-default. However, the mapping leaves three enum values (zugefallen, abgeschlossen, zylinder) unmentioned, so it is not exhaustive.

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 WHAT: it produces a mailto:info@ikeytz.com link using the same subject+body prefab as compose_whatsapp. This names the exact target resource and output channel, and clearly distinguishes it from the compose_tel_* and compose_whatsapp siblings.

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 concrete call guidance ({} maps to the beratung template, not an empty mailbox), states that email is not sent, and redirects partner-mailbox needs to get_partner_info.partnerEmail. It does not explicitly spell out when to choose this over the WhatsApp or phone compose tools, but the exclusions and references make selection fairly clear.

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 readOnlyHint annotation already establishes that this is a safe read-only operation. The description adds the no-argument calling convention and the output type (tel: href), but it does not go beyond that with edge cases, determinism, or side-effect details. That is acceptable for a simple no-arg tool, but not richly transparent.

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 extremely concise and front-loaded: it states the output, the calling convention, and the key alternative in one compact line. Every element earns its place, and there is no redundant prose.

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 zero-parameter, read-only tool with an output schema, this description is complete. It explains what the tool returns, how to call it, and when to choose a sibling instead. No critical information needed by an agent to invoke it correctly is missing.

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?

There are zero parameters, and the schema description already fully covers the calling convention. The description reinforces this with 'Call with {}', which is helpful but does not add much beyond the schema. The zero-parameter baseline of 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 clearly states that the tool produces a tel: href for the landline (Festnetz), which is a specific output and resource. It also distinguishes itself from compose_tel_mobile by explicitly naming that sibling, so an agent can separate the two without inspecting schemas.

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 an explicit routing rule: mobile and 24h emergency use compose_tel_mobile instead. This tells the agent when not to use this tool and which alternative to select, which is exactly the kind of usage guidance needed.

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 declare readOnlyHint=true, and the description goes further by explaining that the tool only returns href and canonicalUrl values and does not actually place a call. The instruction 'do not pretend the call happened' adds practical behavioral transparency beyond the annotation.

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 structured with clear WHAT/RETURNS labels, making it easy to parse. Every sentence adds value: the purpose, the output, the behavioral caution, and the sibling distinction are all included without fluff.

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?

Given the zero-parameter signature, presence of an output schema, and readOnly annotation, the description covers everything needed: it names the output fields, explains the result is a link to display, and identifies the related landline tool. There are no significant gaps.

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 tool has zero parameters and the schema description already documents that no arguments are needed and extra keys are ignored. The description reinforces this by saying 'Call with {}', so no additional parameter explanation is required.

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 clearly states the tool composes a tel: href for the 24/7 mobile (Handy), specifying both the verb and the resource. It differentiates from the landline sibling by explicitly naming compose_tel_landline as the alternative for landline.

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 explicit context: use this tool to generate the mobile/Handy tel: link, and use compose_tel_landline for landline. It also instructs the agent to show the result to the user rather than pretending a call happened, providing clear behavioral guidance.

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 readOnlyHint=true, the description reveals key behaviors: building a URL does not send a message, omitted/unknown option defaults to beratung, and deprecated aliases set ambiguous=true. It also disambiguates the 49 € value as cylinder mount rather than a night invoice. No contradiction with 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 description is compact and front-loads the core function in the first sentence, then packs defaults and deprecations efficiently. The pipe-delimited option list is dense but every sentence earns its place, though some phrasing is telegraphic.

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 one optional parameter, enum schema, output schema, and readOnly annotation, the description covers default behavior, deprecated values, source of options, and the non-sending behavior. Nothing essential for correct invocation is missing; it even references list_whatsapp_options for additional options.

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 schema already documents the option enum and its description at 100% coverage. The description adds value by explaining the default fallback for omitted/unknown values and the deprecated alias mapping, which the schema does not state. Base 3 plus one for extra semantics.

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?

States a specific verb and resource: 'Build a https://wa.me/… URL'. Explicitly narrows scope with 'Does not send WhatsApp' and names the list tool alternative, distinguishing it from compose_mailto/compose_tel siblings.

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?

Tells the agent where valid option values come from ('contactOption from get_prices.composition.endInvoices or get_invoice_line_items.contactOption'), warns against deprecated aliases ('do not use them'), and points to list_whatsapp_options for listing. It does not explicitly contrast with the other compose_* tools, but the channel-specific name plus these instructions provide adequate guidance.

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 only provide readOnlyHint=true, so the description carries the behavioral burden. It discloses case-insensitive matching, the exact data source URL, default and maximum limits, empty-q behavior, the raw TSV-like return rows, and the important caveat that locale does not filter the file. This is far more than the annotation alone provides.

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 tightly packed with labeled sections (WHAT, REQUIRED, DEFAULT, RETURNS, USE, NEXT) and no filler. Every sentence contributes either to selection, invocation, or follow-up. The front-loaded WHAT and REQUIRED statements make the core purpose immediately visible.

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 source is fully identified, required and optional parameters are covered, locale limitations are clarified, return shape is mentioned, an output schema exists, and the natural next-step tool is provided. For a read-only search tool, no essential decision or invocation information is missing.

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%, which sets the baseline at 3, but the description adds meaningful semantics beyond the schema: case-insensitive matching, the fact that q matches against the whole keyword line, empty-q handling, and the explicit note that locale does not filter the file. These details help an agent understand the parameters in context.

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 operation: substring search over a named keyword file (llms-keywords.txt) mapping phrases to URLs. It also gives the intended use ('map a user phrase to URLs') and names the follow-up sibling (get_ai_page), making it easy for an agent to distinguish from the adjacent get/list tools.

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 explicitly says when to use the tool ('USE to map a user phrase to URLs') and provides a clear next step ('NEXT: get_ai_page on a returned www path'). It does not explicitly state when not to use it or list alternative tools, so it falls just short of full routing guidance.

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, and the description adds behavioral context by calling this a 'pointer' rather than a content endpoint, implying the tool returns a reference/location rather than the full page. This is useful beyond the annotation and does not contradict it, though it could be slightly more explicit about output behavior. Given the low bar set by the readOnlyHint annotation, this is strong.

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 extremely compact, using labeled 'WHAT' and 'NEXT' segments to front-load the core purpose and follow-up action. Every sentence contributes either purpose, routing, or workflow guidance 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 simple, read-only pointer tool with one optional parameter and a full schema description plus an output schema, the description covers the essential aspects: what it points to, which sibling to use for alternative data, and what to call next. Nothing critical is missing 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?

Schema description coverage is 100%, and the locale parameter is thoroughly documented in the input schema, including defaults, URL behavior, and non-applicability to German legal names. The tool description adds no additional parameter-level detail, but none is needed because the schema already carries that weight.

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: it is a 'Pointer to /ueber-uns' for about/owner information. It also explicitly differentiates itself from get_business_identity, which is the tool for NAP facts, making its purpose distinct among many similar get_* siblings.

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 an explicit alternative condition: 'For NAP facts prefer get_business_identity.' It also suggests a next step, get_ai_page, which clarifies the intended workflow and when this tool should be used as a pointer rather than a content fetcher.

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 goes well beyond the readOnlyHint annotation, disclosing URL construction ('path=/ → index.txt; else path without leading slash + .txt'), response truncation ('summary = first 4000 chars; truncated=true if longer'), error mapping ('HTTP errors → ok=false'), and a content limitation for /review. This is exactly the behavioral context the annotation does not provide.

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 telegraphic but every clause carries a distinct fact: URL pattern, path mapping, truncation, error behavior, use case, caveat, and sibling routing. The WHAT/USE/NEXT labels make it easy for an agent to parse quickly. No filler or redundancy.

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 an output schema present and readOnlyHint=true, return values and safety are already covered, and the description handles the rest: URL construction, truncation, error semantics, and a content caveat. The one residual gap is the unaddressed relationship to the similarly named sibling get_ai_txt, which an agent could easily confuse with this 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?

Schema coverage is 100%, so the baseline is 3, and the schema already documents both parameters with examples. The description adds value by explaining how path maps to the fetched file ('path=/ → index.txt; else path without leading slash + .txt') and how locale prefixes shape URLs, which is not stated in the schema.

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 ('Fetches public https://www.ikeytz.com/ai-pages/{locale}/{file}.txt (HTML-parity fulltext)') and states what the tool is for ('USE for page content'). It also distinguishes itself from a sibling ('NEXT: get_serp_snippet for title/description only'). The only minor gap is that it never differentiates itself from the nearly identically named sibling get_ai_txt.

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?

Explicit guidance is present: 'USE for page content' states when to invoke it, and 'NEXT: get_serp_snippet for title/description only' names the alternative and the condition that selects it. The '/review has no HTML-parity footer' caveat further helps an agent avoid a wrong call.

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 mark it read-only, and the description adds meaningful behavioral context: the content is a crawl/training policy with specific terms (attribution required, ai-train=no), and the agent must respect it when quoting site text. No contradiction with the readOnlyHint annotation.

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 that conveys the resource, its purpose, and an important compliance instruction. Every phrase earns its place with no redundancy or 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 simple read-only fetch tool, the description plus fully documented schema and output schema provide everything needed. The policy context and respect obligation are the key non-structural facts, and they are present.

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%, so the description does not need to explain limit or offset semantics. The tool description itself adds no parameter-level detail, which is acceptable because the schema already documents both parameters thoroughly.

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?

States the specific verb 'Fetch' with the exact resource '/.well-known/ai.txt' and explains what the file contains. The resource path and policy focus distinguish it clearly from siblings like get_llms_txt or get_ai_page.

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?

Gives clear usage context: the policy 'Must be respected when quoting site text,' which tells an agent when the fetched content is relevant. It does not explicitly name alternatives or exclusion conditions, but the unique well-known path makes selection straightforward.

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, and the description adds useful behavioral context by stating that it returns only slug + canonicalUrl, not fulltext content. It also sets expectations by directing the agent to get_ai_page for fulltext, which clarifies the tool's limited scope beyond what annotations convey.

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 highly concise and well-structured: WHAT, REQUIRED, RETURNS, USE, NEXT. Every sentence delivers distinct value, and the most important prerequisite is front-loaded.

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 read-only tool with an output schema and fully described parameters, the description covers purpose, prerequisite, use case, and follow-up actions. Nothing critical is missing for an agent to correctly select and invoke 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?

Schema description coverage is 100%, with detailed parameter descriptions including examples and a 'Not an Ort slug' note. The description adds marginal reinforcement ('REQUIRED slug from list_auswahl') but doesn't substantially expand beyond what the schema already provides, so the baseline of 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 resource ('One Auswahl situation page') and the exact return value ('slug + canonicalUrl'), making it clear what the tool does. It is distinguishable from sibling tools by requiring a slug from list_auswahl and focusing on lockout/key situations, which is unique among the listed siblings.

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 explicitly says 'USE after the user described a lockout/key situation' and instructs that the slug must come from list_auswahl. It also provides concrete next steps (get_ai_page for fulltext, get_invoice_line_items for euro), giving the agent clear routing guidance versus 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?

Annotations only provide readOnlyHint=true; the description adds substantial behavioral context: no updates accepted, walkIn is always false, canonicalUrl value, and the limitation that it cannot prove licenses. These are exactly the non-obvious traits an agent needs before invoking.

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 dense but highly structured with WHO/RETURNS/USE/DOES NOT/NEXT markers. Every segment earns its place, and critical facts are front-loaded.

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-parameter read-only tool with a rich schema and output schema, this description is complete: it covers purpose, return highlights, use cases, exclusions, and sibling routing. Nothing essential is missing.

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 coverage is 100% and the sole parameter (locale) is thoroughly described in the schema, so the description is not required to add parameter meaning. It does not meaningfully enhance the locale semantics; baseline 3 is appropriate.

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 exactly what the tool returns — legal/trade identity and NAP facts — and anchors it with concrete use cases ('impressum-grade facts', schema.org LocalBusiness fields). It also distinguishes itself from siblings by naming get_legal, get_contact, and get_geo_office as related tools.

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?

Explicit USE guidance tells the agent when to call this tool, and DOES NOT states limitations (cannot prove licenses, does not accept updates, walkIn is always false — do not send customers to the office). It also provides NEXT tool pointers, which is ideal routing behavior.

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 readOnlyHint annotation already signals read-only behavior, and the description adds meaningful context: the data is public, the tool has no form-submission side effect, and the agent must not claim it did. This prevents both misuse and hallucinated success.

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 WHAT/USE/NEXT structure is compact, scannable, and every clause carries value: the returned object, the exclusion, the intended use, and follow-up tools. There is no filler or redundancy.

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 one-optional-parameter read-only tool with an output schema, the description covers the essential context: what is returned, what is not done, when to use it, and what to do next. Nothing needed to call it correctly is missing.

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 coverage is 100%, and the single optional locale parameter is already fully documented in the schema with defaults, URL-prefix behavior, and scope limitations. The description does not add parameter-level detail, but it does not need to because the schema is complete.

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 exactly what is returned: a public contact object containing phones, fax, email, and office address. It also distinguishes the tool from the website contact form and from the compose/list siblings, so an agent can tell it apart without inspecting schemas.

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 use case ('USE to give the user a number'), an explicit non-use ('DOES NOT submit the website contact form and must not claim it did'), and lists relevant NEXT alternatives. This is clear routing guidance rather than a generic 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, and the description does not contradict this. It adds substantial behavioral context beyond annotations: the response is a line window, paging uses offset/limit plus nextOffset, byte caps apply, unknown IDs return unknown_discovery, and policy files may indicate ai-train=no.

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 dense but well-structured with clear labels (WHAT, REQUIRED, summary, etc.). The alias list is long but necessary for correct selection, and every sentence contributes operational guidance without 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?

Given the tool has an output schema, the description does not need to explain return values in detail. It covers required input, paging behavior, edge cases, alternatives, and policy caveats, making it complete enough for an agent to invoke the tool correctly in nearly any scenario.

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%, so the baseline is 3. The description adds extra value by explaining alias folding ('llms_full → llms-full'), prefix/suffix stripping, concrete usage guidance for large files like llms-keywords.txt, and when to omit limit for sitemap.txt. This goes beyond the schema descriptions.

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+resource: 'Fetch one public discovery file from www and return a line window.' It lists the known discovery IDs and explicitly distinguishes itself from dedicated siblings like get_llms_txt, get_sitemap_txt, and get_llms_mcp_server, so an agent can select it correctly.

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 explicitly says 'Prefer dedicated get_llms_txt / get_sitemap_txt / get_llms_mcp_server when you know the file,' giving agents a clear routing rule. It also defines the unknown-which behavior ('Unknown which → unknown_discovery'), so there is no ambiguity about when and how to use this tool.

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 readOnlyHint annotation, the description discloses that this is only a pointer with no side effects, that the summary includes the mobile number, and that canonicalUrl is locale-prefixed. This is exactly the behavioral boundary an agent needs for an emergency contact tool.

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 tightly organized with WHAT, DOES NOT, and NEXT sections, front-loading the core purpose and decision-relevant boundaries. Every clause earns its place; the telegraphic style is efficient without sacrificing meaning.

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-parameter, read-only tool with an output schema, the description covers purpose, output highlights, negative behavior, and downstream contact actions. Nothing needed to invoke it correctly is missing, and the output schema handles return-structure details.

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 coverage is 100% and the locale parameter description already explains defaults, URL prefixes, and behavior across locales. The description's only parameter-related addition is 'locale-prefixed' for canonicalUrl, which is largely implied by the schema, so it adds minimal semantic value beyond what is already structured.

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 identifies a specific resource, the 24h Notfall-Türöffnung page, and clearly differentiates it from booking or dispatching actions. However, it uses the noun phrase 'Pointer to' rather than an explicit operational verb such as 'returns' or 'fetches', relying partly on the tool name for the action.

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 explicitly states what the tool does not do ('DOES NOT dispatch a technician or take a booking') and provides a direct next-step workflow to compose_tel_mobile or list_whatsapp_options then compose_whatsapp. It gives clear usage context and exclusions, though it doesn't compare against sibling retrieval tools like get_contact or get_page_summary.

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?

Discloses lookup precedence, fallback matching behavior, and the missing-result signal faq_not_found. With readOnlyHint already set, the description adds useful behavioral context rather than repeating the annotation.

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?

Very compact and front-loaded with WHAT and lookup rules. Every sentence carries routing or behavior information, 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?

Complete for a read-only FAQ lookup: lookup strategy, error behavior, alternative tool routing, and id source are all covered. The input schema handles parameter details and the output schema handles return shape.

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 coverage is 100% and the schema already explains q, id, and locale in detail. The description mostly reinforces the id-before-q priority already stated in the schema, so it adds little new 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?

States the exact resource and operation: retrieving one FAQ Q+A entry, with examples of topics. It also distinguishes itself from siblings by saying it is not a calculator and pointing to get_invoice_line_items and list_faq.

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?

Gives explicit lookup behavior: exact id first, else substring search on q. It also names the alternative tool for euro amounts and tells the agent to prefer ids from list_faq, making when-to-use and when-not-to-use clear.

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?

With readOnlyHint=true already in annotations, the description adds useful behavioral context: walkIn=false, the office is not a service location, and service takes place on site in the 52-place area. This helps prevent an agent from sending users to the wrong destination. No contradiction with 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 definition uses compact labeled segments—WHAT, NOT, USE, NEXT—front-loading the core purpose and keeping every sentence informative. There is no filler or redundancy.

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?

Given one optional parameter, a complete parameter description, a read-only annotation, and an output schema, the description supplies the remaining judgment context: citation use, non-walk-in status, service location, and next tools. Nothing essential is missing.

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%—the locale parameter's enum, default, and URL-prefix behavior are fully documented in the schema. The description does not add parameter-specific guidance beyond that, so the 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 starts with a specific WHAT: office coordinates (SITE.geo), street/postal/city, and walkIn=false, making the resource and fields clear. It also clarifies it is not a customer shop, but it does not explicitly contrast itself against the sibling tools get_contact or list_service_areas—they are merely listed as NEXT.

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 explicitly says USE for NAP/geo citations and provides a clear when-not: do not navigate users to the office for service. It names get_contact and list_service_areas as related next steps, but does not state the specific conditions under which an agent should choose those instead.

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?

With readOnlyHint=true already present, the description still adds substantial behavioral context: exact classification logic, alias mapping, breakdown behavior, and return shape (totalEur + composition + contactOption). It also clarifies that it is not a booking or PDF and does not include VAT, going well beyond the annotation.

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 dense but every clause carries a domain rule necessary for correct invocation. It is front-loaded with WHAT and exclusions, then flows through the classification, timing, special cases, output, and next steps. The structured labels keep it scannable despite its length.

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?

Given the intricate pricing logic and 100% schema coverage, the description covers the full decision tree, edge cases, aliases, and downstream tools. The presence of an output schema handles return-value specification, so nothing an agent needs to call this correctly is missing.

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 coverage is 100%, but the description adds crucial meaning not inferable from the schema: situationKey aliases (zugefallen→opening_slam), the special rule that night is not +49 (49 only for cylinder_mount), and the exact effect of breakdown=true. This enriches the bare parameter definitions.

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 'Computes ONE of the 10 end-invoices (or the 49 € mount add-on)' and immediately excludes misconceptions with 'NOT a booking, NOT a PDF.' This gives a specific verb and resource and differentiates it from sibling tools like compose_whatsapp and get_prices.

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 provides an explicit decision procedure: classify via get_prices.composition.routes, get whenKey from get_ort_datetime, handle aliases, and then proceed to compose_whatsapp or compose_mailto. It also states exclusions like 'Night/WE/holiday is NOT +49' and 'Do not add 49 on top of pkg_key_*', leaving no ambiguity about when and how to use it.

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 mark the operation readOnlyHint=true, and the description adds meaningful behavioral context: www /mcp never calls maps /mcp, proxy=false, and /it is not Italian. These details go beyond the structured fields and help the agent avoid misconceptions.

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 WHAT/RETURNS/USE structure front-loads the core purpose and keeps the description dense. A few phrases are cryptic or use ellipses ('maps={...}'), and some details are niche, but overall every sentence carries distinct information.

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?

Given the simple single-optional-parameter schema and presence of an output schema, the description is complete enough. It covers the page's role, the two endpoints, the distinction from the hub tool, and the non-HTTP CLI channel, so an agent has sufficient context 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 only parameter, locale, is fully documented in the input schema with an enum, default value, and detailed explanation of URL prefix behavior. Schema coverage is 100%, so the description does not need to add parameter semantics; the 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 names a specific resource ('HTML page /it') and explains it documents two MCP machines (website/www and maps). It also distinguishes itself from the sibling get_mcp_hub by explicitly pointing to '/mcp-hub (get_mcp_hub)', so an agent can tell this tool apart.

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 explicitly says 'USE to tell an agent there are TWO endpoints (www vs maps)' and clarifies the hub HTML belongs to get_mcp_hub, not this tool. It also rules out the CLI npm channel as a separate third channel, giving clear selection guidance.

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 mark the operation read-only. The description adds valuable behavior beyond that: unknown docs produce ok=false and a hint, the return includes doc + canonicalUrl rather than full content, and language precedence is stated. It could go further on details like auth or rate limits, but those are not critical here.

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, telegraphic, and front-loaded. Every clause earns its place: scope, required parameter, edge-case response, return value, alternatives, and language caveat are packed into a few short lines 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 pointer tool with a full schema and output schema, the description covers the essential selection and invocation information: what it returns, what it does not return, how to get full text, and how invalid input behaves. Nothing critical is missing.

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%, so the baseline is 3. The description reinforces that doc is required and used as a path slug, and it adds error-behavior context for invalid docs, but it does not add much semantic value beyond what the schema already documents.

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?

Description states a specific verb and resource: 'Pointer to one legal HTML page.' It explicitly distinguishes itself from full-text tools by directing callers to get_ai_page and get_discovery, so the tool's scope is immediately clear to an agent.

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?

Provides explicit when-to-use guidance: this tool returns the pointer/canonical URL, while full text requires get_ai_page, and the copyright corpus requires get_discovery. It also specifies the unknown-doc error shape and the language/binding caveat, leaving little ambiguity about selection.

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 readOnlyHint annotation already signals a safe read operation. The description adds useful boundary context by stating what is not included, but it does not describe the actual behavior or return shape beyond implying a pointer to /links. This is acceptable given the annotation coverage but not strongly enriching.

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 extremely compact, front-loaded with the WHAT, and every sentence adds value. The sibling distinction is included without padding.

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 only one optional parameter, a complete schema, an output schema present, and a readOnlyHint annotation, the description covers the essential guidance. The main ambiguity is the exact nature of 'Pointer to /links', but it is not a critical gap for this low-complexity 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?

Schema description coverage is 100%, and the locale parameter is thoroughly documented with defaults, URL-prefix behavior, and exclusions. The tool description adds no parameter-level meaning, but it does not need to because the schema carries the full 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 identifies the resource (/links) and the categories covered (directories, city sites, HWK, Webmail shortcut), and explicitly separates it from get_mcp_hub for external MCP catalogs. It is clear enough to distinguish from siblings, though 'Pointer to' is slightly less explicit than a verb like 'retrieves' or 'lists'.

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 a clear exclusion: external MCP catalogs belong to get_mcp_hub.publicLinks, not this tool. This routes the agent to the correct sibling for one overlapping scenario, though it does not elaborate on broader when-to-use cases.

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 readOnlyHint annotation is consistent and the description adds meaningful context beyond it: the endpoint path, 'no login', and the fact that the content is a prose catalog of 45 Read/Link tools. It also signals that the result is server-specific rather than general documentation. No contradiction.

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 'WHAT:', and each segment (resource, content, no-login, equivalence, exclusions) earns its place. No filler or redundant restatement of the tool name.

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?

Given the rich parameter schema, output schema, and readOnly annotation, the description covers purpose, target resource, authentication context, and relationship to alternatives. Nothing an agent needs to invoke the tool correctly is missing.

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 coverage is 100%; the limit and offset parameters are already well documented in the input schema with clamping, paging, and line-index semantics. The description itself adds no parameter-level detail, so the baseline 3 is appropriate.

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 ('Fetch /llms-mcp-server.txt') and immediately frames it as a prose catalog of this HTTP server with no login. It explicitly differentiates itself from the npm CLI README and maps, and notes equivalence to get_discovery(which=llms-mcp-server), so an agent can tell exactly what this tool is for.

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 states what the tool returns and the no-login condition, and explicitly names a sibling-equivalent (get_discovery) plus exclusions ('Not the npm CLI README. Not maps.'). It does not fully spell out when to prefer this over nearby siblings like get_llms_txt or get_llms_mcp_web, but the relevant routing is clear.

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, and the description adds useful context: it fetches a specific file through a different transport while sharing the same executeMcpTool handlers. This goes beyond the annotation without contradicting it.

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 with a WHAT label. Each sentence adds transport or scope information; the only minor issue is the deictic phrase 'Not this streamable-http endpoint,' which is slightly ambiguous but not wasteful.

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?

Given rich parameter schema, a read-only annotation, and an output schema, the description supplies the remaining key context: the resource path and transport mechanism. It does not name sibling alternatives, but that gap is covered under usage guidelines.

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 contains no parameter guidance, but the input schema covers 100% of parameters with detailed limit/offset semantics, including clamping, offset meaning, and nextOffset paging. With full schema coverage, the baseline of 3 is appropriate.

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 (/llms-mcp-web.txt) and action ('Fetch'), and clarifies its scope as the 'browser WebMCP catalog (early bootstrap tools + full list)'. It does not explicitly distinguish itself from sibling tools like get_llms_mcp_server or get_llms_txt, so it falls short of a full 5.

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?

There is no guidance on when to use this tool versus alternatives. The description notes that it uses document.modelContext rather than HTTP and says 'Not this streamable-http endpoint,' but this does not help an agent choose among the many sibling get_* tools.

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, so the safety profile is covered. The description adds useful behavioral context: the exact URL fetched, that it is a 'short AI landmap', that it works like get_discovery(which=llms), and that it returns a file window/summary. This goes beyond the structured 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 description is compact and front-loaded: it states the WHAT first, then the USE, then the relevant alternatives. Every sentence adds value, and there is no redundant prose.

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?

Given that annotations establish read-only safety, the schema fully documents parameters, and an output schema exists, the description covers the remaining essentials: the source URL, its role as the first discovery read, and the sibling tools to use for full dumps or MCP catalogs. Nothing critical is missing.

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%, so the limit and offset parameters are already fully documented in the input schema. The description adds only a general 'summary = file window' hint and does not need to repeat parameter details; the baseline of 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 opens with 'WHAT: Fetch https://www.ikeytz.com/llms.txt (short AI landmap)', giving a specific verb, resource, and scope. It also differentiates itself from siblings by naming get_discovery(which=llms), get_discovery(which=llms-full), and get_llms_mcp_server, so an agent can select it without opening schemas.

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 explicitly says 'USE as the first discovery read' and then points to alternatives: 'Full dump: get_discovery(which=llms-full)' and 'MCP catalog: get_llms_mcp_server'. This gives clear when-to-use and when-to-choose-a-different-tool guidance.

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 set readOnlyHint=true, and the description does not contradict that. It adds valuable context by clarifying that this is an HTML hub endpoint rather than the protocol endpoint, and describes the returned data structure (publicLinks, itPage, emails). This goes beyond the annotation's simple read-only flag, though it does not discuss side effects or permissions.

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 well-structured with clear demarcations (WHAT, NOT, RETURNS, USE). It packs extensive disambiguation into a few lines without redundancy, and the critical purpose is front-loaded. Every sentence contributes to correcting potential misuse or clarifying scope.

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?

Given the tool's complexity—distinguishing from protocol endpoints, locale variations, and output structure—the description is thorough. It covers what it does, what it is not, what it returns, and how to use it. The existence of an output schema reduces the need to detail return values, yet the description still mentions key fields, making it complete for an agent to invoke 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 schema fully documents the single 'locale' parameter (100% coverage), including its enum, default, and detailed behavior. The description itself does not mention parameters, so it adds no additional semantic value. Baseline 3 is appropriate because the schema already handles parameter semantics.

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 immediately states 'WHAT: HTML hub /mcp-hub' and clarifies that it is not the protocol endpoint, explicitly distinguishing it from the POST endpoint. It also mentions it returns the same machines as get_it plus additional fields, giving a clear, specific purpose that differentiates it from sibling tools.

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 says 'USE to cite discovery URLs,' which is a concrete usage scenario. It also provides exclusions like 'Not Italian, NOT the protocol endpoint' and warns about the Smithery listings and GitHub, helping the agent avoid misapplication. However, it does not explicitly state when to prefer this tool over get_it or mention alternatives, so it lacks a complete when-not-to-use section.

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 only declare readOnly, but the description discloses the exact day/night rule, holiday dependence, Baden-Württemberg holiday nuance, Berlin timezone, and the returned fields. This makes the tool's behavior predictable beyond what readOnlyHint conveys.

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 dense but cleanly structured with WHAT/THIS/RULE/RETURNS/USE/NEXT prefixes, and each fragment carries decision-relevant information. The core purpose is front-loaded, and the rule is stated precisely before workflow guidance.

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 clock/time tool with two optional params and an output schema, the description fully covers the operational rule, timezone, holiday edge case, disambiguation from a sibling, and downstream pricing/invoicing usage. An agent has everything needed to call and apply the result 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?

Schema coverrage is 100%, so the two optional parameters are already fully documented. The description adds contextual framing (clock, prices, before invoicing) but no new syntax or parameter-level detail, so baseline 3 is appropriate.

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 WHAT, stating it is a Europe/Berlin wall clock to the second plus a day/night price key, and explicitly disambiguishes it from a maps.ikeytz.com geo-clock and from place lookup. An agent can identify the tool's exact role without opening the 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 USE-before-invoicing instruction and a NEXT step calling get_invoice_line_items, and it says the maps tool is a different clock. It also states what the tool does NOT do (no slug/plz lookup), which prevents misuse for geo queries.

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 readOnlyHint annotation, the description discloses that the tool is only a stub, does not return page body content, and returns a path with the locale prefix stripped. This is meaningful behavioral context. Error conditions and exact output format are not discussed, but the output schema likely covers return structure.

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 very short and front-loaded with 'WHAT', but several fragments are cryptic, such as 'summary says to use ai-pages or HTML' and the trailing 'Required path.' These add confusion rather than clarity, even though the overall length is appropriate.

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 zero-parameter, read-only tool with an output schema, the description covers the tool's purpose, return value, and alternatives. The 'Required path' note is ambiguous, but it does not prevent correct use because there are no input parameters.

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 schema has zero parameters and 100% coverage, so there is no parameter information for the description to add. A score of 4 is appropriate for a zero-parameter tool where parameter semantics are not applicable.

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 exactly what the tool does: it is a stub pointer that returns a path, not the page body. It explicitly contrasts itself with get_ai_page and get_serp_snippet, making its distinct role among siblings clear despite the possibly misleading title.

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 explicitly directs agents to use get_ai_page or get_serp_snippet when real text is needed, which establishes the main alternative. It does not fully articulate every scenario for using this stub pointer, but 'stub pointer only' and 'RETURNS path' make the intended use reasonably clear.

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 behavior beyond readOnlyHint=true by warning that formSubmit=false and instructing agents not to claim they submitted the form. It also clarifies the main output (partnerEmail) and the expected next action, which is valuable operational context.

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 highly concise and uses clear labels (WHAT, RETURNS, NEXT) to front-load the essential information. Every segment serves a distinct purpose and there is no redundant wording.

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-parameter read-only tool with an output schema, the description provides the key behavioral warning, return value, and recommended follow-up. It is slightly thin on when the tool should be chosen over siblings, but overall it gives an agent enough to call and use the tool 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 only parameter, locale, has 100% schema description coverage with detailed explanation of defaults, URL prefixes, and non-locale behavior. The description adds no parameter-specific information, but with complete schema coverage the baseline of 3 is appropriate.

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 the tool returns partner-werden info and specifically RETURNS partnerEmail for a mailto, so an agent can tell what the tool produces. It does not explicitly differentiate itself from sibling get_* tools, but the partner-werden context and next-step hint make the resource clear.

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 intended use is implied by the name and 'Partner-werden info' rather than explicitly stated. There is no comparison to alternative tools or a clear 'use when the user asks about becoming a partner' condition, though the NEXT instruction gives useful follow-up context.

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 goes far beyond the readOnlyHint annotation by disclosing exact composition rules, pitfalls like 'never add 49 again,' exclusions for night/weekend/holiday, and the return structure: composition, opening, packages, surcharges, note. It also states 'No VAT (§ 19),' which is useful behavioral context not present in the annotation.

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 dense and every sentence adds a constraint, return detail, or routing hint. It is front-loaded with the core purpose and avoids fluff, though the all-caps style and high information density make it slightly harder to parse.

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 pricing-composition tool with an output schema and one optional locale parameter, the description is unusually complete. It covers the tool's purpose, return shape, associated pitfalls, contact paths, and relationship to the sibling that computes totals. No critical calling information is missing.

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 schema description coverage is 100% and fully documents the single optional 'locale' parameter, including default behavior and URL prefix effects. The description adds no parameter-specific detail, but the baseline of 3 applies because the schema already 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 'Official Festpreis matrix + composition SYSTEM' and immediately states the tool's purpose: 'USE to understand how to assemble a price.' It also distinguishes itself from a sibling by saying 'DOES NOT compute one customer total — that is get_invoice_line_items(situationKey, whenKey).' This gives a specific verb, resource, and differentiation from other tools.

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 explicitly says when to use the tool ('USE to understand how to assemble a price') and when not to ('DOES NOT compute one customer total'), naming the exact alternative: get_invoice_line_items. It also gives routing hints to related tools like compose_whatsapp/compose_mailto and get_ort_datetime.

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 readOnlyHint annotation, it discloses that the tool returns a pointer rather than content, signals the next step (get_ai_page), and specifies unknown_ratgeber behavior for invalid slugs. This is useful additional behavioral context for a 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?

Compact and structured with WHAT/REQUIRED/Unknown/NEXT labels; no filler. Every sentence contributes to call correctness or workflow.

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 two-parameter read-only tool with an output schema and a detailed schema description, the definition covers the prerequisite, invalid-input result, and follow-up call. It could explicitly contrast list_ratgeber vs. get_ratgeber, but the source requirement already implies 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 coverage is 100%, so the schema already documents slug and locale in detail. The description adds a source constraint for slug but does not materially extend parameter meaning beyond the schema.

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?

States with a specific verb ('get') and resource ('one Ratgeber'), explicitly contrasting with list_ratgeber by requiring a single slug. The description's 'pointer' role makes it clear this is not a content fetch and differentiates it from sibling tools.

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?

Explicitly requires a slug obtained from list_ratgeber and defines the unknown-slug behavior, which gives an agent clear call prerequisites. It does not enumerate exclusions or compare alternatives, but the workflow context is concrete.

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 annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds that this is a redirect and enumerates the return fields (googleReviewUrl and canonicalUrl), plus the exclusion of rating lists. This is adequate behavioral context for a simple read-only URL getter.

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?

Every clause earns its place: WHAT, RETURNS, USE, and the not-a-list exclusion. The label-prefixed structure front-loads the key behavior and avoids filler. It is short but information-dense.

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 one optional parameter, a fully documented schema, an output schema, and readOnlyHint, all information needed to invoke the tool correctly is present. The description also prevents the natural confusion with aggregate review data. Nothing important is missing.

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 documents locale with an enum, default, and a detailed explanation of path-prefix behavior, so 100% of parameter semantics are already in the schema. The tool description itself adds no parameter-level detail, but the schema makes that unnecessary. 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 opens with 'WHAT: Short /review redirect to the Google review URL,' naming the exact resource and behavior. It closes with 'Not a list of existing ratings,' which disambiguates it from rating/snippet tools. This is a specific verb-and-resource description that clearly separates it from siblings.

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?

'USE when the user wants to leave a review' is an explicit condition for invoking the tool. The negative clause 'Not a list of existing ratings' tells the agent when it is not appropriate. This is clear when/when-not guidance even though no sibling alternative is named.

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, and the description adds valuable behavioral detail: it searches the first occurrence, returns matchContext with approximate character counts, returns serp_not_found on no match, and describes path-to-www conversion. This goes well beyond the annotation and is not contradicted.

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 WHAT, and uses clear labels such as RETURNS and 'Not a Google API.' Every clause earns its place, with no filler or repetition.

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?

Given the read-only annotation, full schema coverage, and presence of an output schema, the description covers the essential invocation details: required parameter combination, locale behavior, failure return, and output format. An agent has enough context to call 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?

Schema description coverage is 100%, so the baseline is 3. The description adds extra meaning by stating that path or url is required in practice, explaining how non-http(s) paths are turned into www(locale, path), and clarifying that url can serve as the search needle. This is useful beyond the schema.

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: it returns a slice of /llms-serp.txt around the first occurrence of a target URL, including title/description/URL rows. It also explicitly disambiguates from a Google API, making the tool's scope clear.

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 practical guidance like 'path or url required in practice' and a negative exclusion ('Not a Google API'), so usage is partly implied. However, it never names alternative sibling tools or explains when to prefer this over related tools like get_llms_txt or get_sitemap_txt.

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 readOnlyHint annotation, the description discloses the exact lookup precedence (slug before plz before substring), case-insensitive matching, the absence of a silent fallback, and the exact unknown-place error shape including ok=false, error=unknown_place, and hint=/einsatzgebiet.

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 dense but well-labeled with WHAT, RETURNS, USE, NOT, and NEXT sections. Every segment carries operational meaning, though some implementation jargon like 'getOrt' and 'ORTE' makes it slightly less crisp than it could be.

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?

Given the rich input schema, readOnlyHint annotation, and presence of an output schema, the description covers everything needed to invoke correctly: lookup rules, error behavior, return fields, use-case trigger, and a suggested next step. No critical operational gap remains.

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 schema already covers all four parameters at 100% coverage, so the baseline is 3. The description adds value above the schema by explaining how the parameters interact in the lookup order and by warning about the concrete 'plz 71638 → pattonville' first-match behavior.

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 starts with 'WHAT: One service-area place', which states a specific verb, resource, and singular scope. It distinguishes itself from sibling list_service_areas by emphasizing it returns one place, and it explicitly warns against nonexistent verify_zip_code/verify_coordinates tools.

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?

'USE when the user names a town or PLZ' gives a clear trigger condition. The 'NOT verify_zip_code / verify_coordinates' warning and 'maps MCP is a second machine' note help prevent misrouting, though the description does not explicitly contrast with list_service_areas or other related 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?

With readOnlyHint=true already covering the safety profile, the description adds rich behavioral context: the file is ~807 HTTP lines of known composition ('marketing ×7 + discovery/media'), contains zero maps URLs by deliberate design, and paginates via a nextOffset protocol. Disclosing the intentional absence prevents a common wrong expectation.

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 compact, front-loaded 'WHAT:' label introduces the fetch target, then delivers size, composition, intentional exclusions, and paging in five short sentences with zero filler. Every clause 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?

An output schema exists and both parameters are fully documented in the input schema, so the description only needs to cover resource identity, content, and paging behavior — which it does thoroughly. Nothing an agent needs to select or invoke this tool correctly is missing.

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 coverage is 100% with both parameters well documented in the schema, so the baseline is 3. The description earns the extra point by stating the file is ~807 lines — telling the agent it can safely omit limit to fetch the whole list — and by showing how offset/limit combine with nextOffset for paging.

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?

Opens with a 'WHAT:' statement naming the exact resource ('Fetch /sitemap.txt') and anchors it against a known format ('same URL set as sitemap.xml'). The content composition, approximate size, and the explicit note that it contains no maps.ikeytz.com URLs leave no doubt about what this tool returns.

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?

Tells the agent when not to use this tool ('Contains 0× maps.ikeytz.com (intentional)… Dedicated maps list is on maps.ikeytz.com, not here') and how to page through results ('Use offset/limit + totalUrls + nextOffset to page'). It stops short of naming a specific sibling alternative to switch to, so it earns a 4 rather than a 5.

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?

Discloses behavioral specifics beyond the readOnlyHint annotation: summary truncation to 500 chars, structuredContent excluding full body, and the wissen_not_found error. These shape agent expectations about response content and failure modes, which is exactly the kind of additive transparency needed.

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?

Compact label-based structure (WHAT, REQUIRED, summary, structuredContent, NEXT) makes it scannable and front-loaded. Each section earns its place; slightly dense, but efficient for an agent parsing it at runtime.

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?

Complete for a read-only single-item fetch: output schema covers return structure, annotations cover safety, and description covers truncation, error, and next steps. Minor omission is explaining whether locale affects content language or only URLs, but overall adequate.

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?

Adds value by stating id must be an exact list_wissen item id, and clarifies locale prefix/default behavior. Schema coverage is 100%, so the description reinforces rather than compensates, but the error-case and content-shape details are useful semantic additions.

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?

States the exact resource ('One Wissen article'), the required parameter (id), and the key behavioral aspects upfront. The WHAT/NEXT structure makes it clear this is a single-item retrieval tool, distinguishing it from list_wissen and other get_* siblings.

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?

Explicitly says id is required and must come from list_wissen.items[].id, and documents the unknown-id error case. It doesn't explicitly contrast with list_wissen or other content getters, but the NEXT fallback (get_ai_page) gives some routing guidance. Slightly more explicit alternative guidance would push this higher.

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?

With readOnlyHint=true already covering the safety profile, the description adds valuable context beyond the annotation: the return shape (groups[] with id/hash/hubUrl/slugs/urls) and the cross-tool behavioral contract where an unknown slug produces ok=false unknown_auswahl in get_auswahl_item. It does not describe pagination or ordering, but those are minor for a hub listing.

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 WHAT/RETURNS/USE format is front-loaded and zero-waste: the core purpose comes first, followed by the return contract and the usage routing. Every clause earns its place, and the structure makes scanning trivial for an agent.

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 low-complexity tool (one optional param, readOnly annotation, output schema present), the description is complete: it states what it does, what it returns, when to use it, and the downstream failure mode. Nothing an agent needs to invoke it correctly is missing.

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 locale parameter's schema description is exceptionally detailed (defaults, URL prefix behavior, what it does not change, maps-locale exclusion). The tool description adds nothing about locale, so the baseline 3 applies — the schema does the heavy lifting, which is acceptable.

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 (list) and resource ('Auswahl hub groups'), anchors it to a concrete endpoint (/auswahl), and differentiates it from the sibling get_auswahl_item by framing this as the slug-discovery counterpart. An agent can tell exactly what this tool does without opening the 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?

The description gives an explicit use case ('USE to discover valid slugs for get_auswahl_item') and names the sibling it feeds into, plus the downstream failure contract for unknown slugs. It lacks explicit when-not-to-use exclusions versus other listing/search siblings, but the primary routing logic is unambiguous.

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 readOnlyHint annotation, the description adds meaningful behavioral detail: the list contains only id and question, no answers, and is 'Policy/text only'. The warning that euro amounts in answers are SSOT tokens rather than live invoice data provides useful extra context even though answers are not returned by this tool.

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 'WHAT', and uses 'USE' to signal alternatives. The sentence about euro amounts in answers and the customer-total chain is slightly noisy for a list tool, but it does serve as a routing warning without bloating the description.

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 read-only list tool with one optional, fully documented parameter and an output schema available, the description covers the key points: what is returned, what is excluded, and which sibling tool to use for details. It does not describe ordering or pagination, but these are not essential given the output schema and simple nature of 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?

Schema description coverage is 100%, and the locale parameter is thoroughly documented in the schema with defaults, URL prefix behavior, and exclusions. The tool description itself adds no additional parameter-level semantics, so the baseline score of 3 is appropriate.

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 'WHAT: FAQ question list (id + question, no answers)', which names a specific verb, resource, and scope. It also differentiates the tool from get_faq by explicitly stating that this returns only IDs and questions while get_faq is for individual entries.

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 explicitly names get_faq({id}) or get_faq({q}) as the alternative when a user needs answers, giving clear routing guidance. It also points to a specific chain (get_prices.composition → get_ort_datetime → get_invoice_line_items) for a customer total, effectively saying when not to use this tool.

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, and the description adds genuinely useful behavioral context: the result list is curated rather than exhaustive, it is not a pixel-perfect scrape, and external directory URLs are excluded. This goes beyond the structured annotation and helps an agent set correct expectations about the returned data.

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, well-organized with WHAT/RETURNS/NOT/USE/NEXT labels, and every sentence contributes routing or scoping information. It front-loads the core purpose and return shape before clarifying boundaries and next steps.

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 one optional parameter, a complete schema description, read-only annotations, an output schema, and explicit sibling routing, nothing essential is missing for an agent to select and invoke this tool correctly. The description covers purpose, scope, alternatives, and follow-up tools.

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 has a single optional locale parameter with 100% description coverage, including defaults, path-prefix behavior, and a note that maps.ikeytz.com locales are not applicable. The tool description adds no additional parameter meaning, but none is needed because the schema already fully documents the parameter.

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 clear WHAT statement: curated internal footer paths including legal, /it, /mcp-hub, /angebot, and /ankuendigungen, and specifies the return shape as items[] {path,url}. It also explicitly contrasts itself with get_links and get_mcp_hub, so an agent can distinguish it from relevant siblings.

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 explicit usage direction: use this tool to discover legal slugs before calling get_legal. It also states what this tool is not for, namely pixel-perfect HTML scraping and external directory URLs, and names alternatives (get_links, MCP_PUBLIC_LINKS, get_mcp_hub). This is strong when-to-use and when-not-to-use guidance.

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 readOnlyHint annotation already signals safety, and the description adds valuable behavioral context beyond it: the result is always the same, host behavior is fixed, and maps subdomain returns 404s. This goes beyond the minimal read-only declaration.

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 densely informative, using clear labels like WHAT, RETURNS, and USE. Every sentence contributes either return semantics, host rules, or usage guidance, 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?

With zero parameters and an output schema available, the description fully covers what the agent needs: return fields, prefix formatting, host constraints, a caveat about maps.ikeytz.com, and when to call it. Nothing essential is missing.

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 tool has zero parameters, so the baseline is 4. The description reinforces the expected invocation with 'Call with {}', and the schema confirms no arguments are required, so nothing is left ambiguous.

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 clearly states a specific operation and resource: listing the seven public HTML locales, and specifies the exact return shape locales[] with id, name, and prefix. It also includes concrete details like the prefix values and host, which distinguishes it from the many sibling list_* tools.

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 explicitly says 'USE before resolve_locale_url', giving a direct ordering instruction relative to a sibling. It also provides exclusion context by noting that maps.ikeytz.com has no locales and that the apex host redirects, helping the agent decide when this tool applies.

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, so the safety profile is covered. The description adds meaningful behavioral context beyond the annotation: the list is curated rather than exhaustive, it deliberately excludes certain routes and the locale switcher, and each item carries a path, locale URL, and label. This helps set expectations about scope and output shape.

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 dense yet scannable, using clear labels (WHAT, RETURNS, DOES NOT, USE, NEXT). Every clause adds value: scope, output shape, exclusions, and follow-up actions. There is no filler or duplication of schema information.

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 list tool with a full output schema and a self-documenting locale parameter, the description covers the essential decisions: what is returned, what is excluded, how to use the result, and what to call next. The exclusions also prevent an agent from incorrectly using this tool for /it or /mcp-hub content.

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 schema already documents the only parameter (locale) with a detailed description, enum values, defaults, and URL-prefix behavior, so the description does not need to repeat it. The description adds no parameter-specific semantics, but schema coverage is 100%, which meets the baseline.

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 a specific resource ('main-header hubs') and explicitly distinguishes itself from a raw dump of every <a> in the header. It enumerates the exact returned items and clearly separates itself from sibling get_* tools by stating which URLs it does not include.

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 states direct usage ('USE to pick a hub URL') and gives a concrete next step ('NEXT: get_ai_page(path) or get_page_summary(path) for body text'). It does not explicitly contrast with sibling list_* tools or say when NOT to use it, but the exclusions and next-step guidance are sufficient for routing.

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