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

With no annotations provided, the description carries the full burden for behavioral disclosure. It does add valuable details: deterministic ordering (alphabetical by name, nodeId tie-breaker) and the optional enrichment of counts. However, it does not mention whether the operation is read-only, any error conditions, rate limits, or the behavior of maxResults and outputFormat. This is a moderate level of transparency, leaving room for improvement.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured and concise, with the purpose stated upfront, followed by key behavior and usage guidance. Every sentence earns its place; no filler or repetition. It is appropriately sized for the tool's complexity.

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 tool has five parameters and no output schema, so the description should ideally clarify return structure and edge cases. It explains the depth behavior, ordering, and optional counts, but omits details about output formatting, maxResults limits, and what happens when a collection has no sub-collections. The description is sufficient for basic use but not fully complete for a tool with moderate complexity.

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 60%, meaning the description must compensate for undocumented parameters. Yet the description only repeats what the schema already states for depth and counts, and does not mention maxResults or outputFormat at all. While the nodeId parameter guidance ('pick a Fachportal or Themenseite') is useful, it is also present in the schema. The description adds minimal semantic value beyond the input 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 uses a specific verb ('Drill into') and resource ('sub-collection tree below a given collection'), clearly distinguishing this from sibling tools like get_collection_contents (which likely fetches items) and get_node_details (which likely gets a single node). It also specifies the return type (direct sub-collections at depth=1 or two levels at depth=2), making the purpose unmistakable.

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 explicit usage context: 'Use this for guided exploration: pick a Fachportal or Themenseite, then let the user choose a sub-area before fetching individual content items.' This clearly indicates when to use this tool and implies that a subsequent tool (e.g., get_collection_contents) should be used after. It lacks an explicit 'when not to use' statement but is otherwise 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 no annotations, the description carries the full burden of behavioral disclosure. It adds valuable context beyond the schema by explaining the WLO thematic page concept, swimlanes, and the recursive sub-tree traversal behavior. It does not cover potential error cases or permission requirements, but for a read tool with detailed parameter descriptions, the transparency is solid.

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 a single paragraph with six sentences, each adding value. It starts with the core purpose and then provides context and parameter guidance. It is not overly verbose, though it could be slightly tightened by moving the nodeId sourcing note earlier. Overall, it is well-structured and easy to scan.

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 8 parameters and no output schema, the description adequately covers the main domain context, parameter variations, and recursive traversal. It does not explain the return structure, but since there is no output schema, that is less critical. Minor gaps include not mentioning the contentFilter='files' restriction for includeSubcollections, though the schema does specify that.

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 high coverage (88%), but the description adds meaning beyond the schema by explaining contentFilter values in plain language (files = Lernmaterialien, folders = Sub-Sammlungen, both = alles) and describing includeSubcollections as traversing the full sub-tree recursively. This helps clarify the intent and usage of these parameters.

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 retrieves content items and sub-collections from a WLO Sammlung by nodeId, using the specific verb 'Retrieve' and naming the resource. It also distinguishes itself by explaining that nodeId comes from search_wlo_collections and that contentFilter controls whether files, folders, or both are returned, which 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?

The description provides clear context for when to use the tool (to fetch contents of a Themenseite) and explains the contentFilter options and includeSubcollections behavior. However, it does not explicitly mention alternatives or when not to use it, such as comparing with browse_collection_tree or get_topic_page_content, which leaves some room for ambiguity.

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 no annotations provided, the description carries the full burden. The verb 'Retrieve' clearly indicates a read-only operation, and listing the exact return fields is transparent. Yet it does not disclose potential response size from includeTextContent, error behavior for invalid node IDs, or performance characteristics. These are notable gaps for a tool that can fetch full text.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with a clear opening sentence, a field list, and bullet points for extras. It is slightly longer than necessary due to the exhaustive list of fields, but that list helps set expectations for output structure. No filler content is present.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema and no annotations, the description does a strong job explaining return structure and optional parameters. It covers the core functionality thoroughly but omits error-handling details and does not differentiate from the sibling get_nodes_details (plural), which might be relevant for batch use cases. Overall, it is complete enough 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 input schema already has 100% coverage with descriptions for all parameters. The description adds semantic context by mapping the optional outputs (textContent, parents, raw) to their use cases, such as finding a Sammlung or debugging. This goes beyond the schema's simple parameter descriptions, though it does not fully explain the outputFormat choices beyond what the schema provides.

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: 'Retrieve detailed metadata, stored full-text content, and/or parent collections for a specific WLO node.' It clearly distinguishes itself from search tools by noting it returns the 'SAME field structure as search tools' and adds optional fields. This makes the tool's unique role unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage after a search: it returns the same structure as search tools but with additional detail for a specific node. It provides a concrete use case for parents ('useful to find which Sammlung a content item is in') and mentions raw is for 'debugging / advanced use'. However, it does not explicitly state when not to use this tool or mention alternatives like get_nodes_details for batch retrieval.

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 no annotations provided, the description carries the full burden and delivers: it discloses parallel execution, the return shape keyed by nodeId, and the notable failure-handling behavior where failed lookups are returned in a `failed` array rather than causing overall errors. This goes beyond the schema and is crucial for callers to trust batch behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three sentences, front-loaded with the core purpose. Each sentence earns its place: purpose, performance benefit, and failure behavior. No wordiness or redundant restatement of 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?

This tool has one parameter, no output schema, and no annotations. The description covers the essential operational context: what it returns (same shape as get_node_details, keyed by nodeId), how errors are handled, and the parallelism. It is complete enough for an agent to invoke it correctly without further inference.

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 describes nodeIds as an array of strings with min/max items (100% coverage). The description adds only that the call is for 'multiple node IDs' and mentions 'max 50 per call' (already in schema), so it does not meaningfully enrich parameter understanding 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 opens with 'Bulk-fetch metadata for multiple node IDs in parallel,' which precisely states the action (bulk-fetch) and resource (metadata for node IDs). It distinguishes itself from the sibling tool get_node_details by explicitly saying 'Bulk' and referencing the same return shape, making the difference 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?

It gives a clear when-to-use context: 'Saves N round-trips when callers need details for many nodes (e.g. resolve cards from a search).' It also references get_node_details for shape, implying that tool for single-node calls, but does not explicitly state 'use get_node_details for a single node.' This is strong but not fully explicit about 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?

With no annotations provided, the description carries the full transparency burden. It discloses deterministic alphabetical ordering, returned fields (nodeId, name, description, optional Themenseiten-URL, disciplines/educational contexts), and the conditional presence of a Themenseite. It does not mention auth or errors, but for a read-only listing tool this is sufficient.

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 the core purpose. Each sentence adds value: scope, context, usage guidance, and return details. No filler or repetition of schema information that wouldn't add value.

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 no output schema and no annotations, the description provides enough to understand what the tool returns and when to use it. It covers ordering, fields, and the optional inclusion of content counts indirectly via the schema. It could be more complete by mentioning outputFormat behavior or pagination limits, but these are not critical for this list-style 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 67%, with two of three params described. The description adds context about the output fields but does not elaborate on the outputFormat parameter beyond the schema enum/default. The educationalContext and includeContentCounts descriptions in the schema cover their semantics; the tool description does not add significant new param meaning.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb+resource: 'Lists the WLO Fachportale — the first-level Sammlungen directly under the WLO root collection.' It clearly differentiates from siblings by emphasizing top-level subject hubs and positioning itself as the entry point for drill-downs, unlike search or collection-navigation 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 states when to use the tool: 'Use this when the user wants an overview of what subjects/topics are covered, or as the natural entry point for guided drill-downs.' It does not provide explicit exclusions or name alternative tools, but the guidance is clear and actionable.

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 no annotations provided, the description carries the burden of behavioral disclosure. It explains that JSON output is render-ready and resolves cards by executing the swimlane widget's saved query, and mentions the hasMore flag and topicPageUrl. It lacks explicit details on read-only nature or error cases, but for a content retrieval tool this is sufficient transparency, earning a 4.

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 concise, well-structured, and front-loaded with the primary purpose. The first sentence states what the tool does, followed by usage guidance and parameter clarification. Every sentence earns its place, and the line breaks improve readability. No unnecessary 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 no annotations and no output schema, the description provides comprehensive context: it explains the result structure (swimlanes, headings, nodeIds), the JSON output specifics, the maxPerSwimlane behavior, and how to resolve nodeIds with another tool. It also ties into the workflow with search_wlo_topic_pages, making it complete for a tool with 5 parameters and multiple output formats.

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 covers 100% of parameters, so the baseline is 3. The description adds value by explaining the relationship between variantId and collectionId, noting that variantId is faster, and explicitly stating that at least one is required (a constraint not captured in the schema). This goes beyond the individual parameter descriptions, meriting a 4.

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 retrieves the content structure of a Themenseite (topic page), detailing swimlanes with headings and nodeIds. It explicitly differentiates from sibling tool search_wlo_topic_pages by noting the latter only returns a URL. This is a specific verb+resource+scope with clear distinction.

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 explicit usage guidance: 'Use this AFTER search_wlo_topic_pages' and 'Resolve the returned nodeIds to human titles with get_nodes_details.' It also tells when to use variantId vs collectionId and that at least one is required, giving clear context for when to invoke this tool 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?

No annotations are provided, so the description carries the transparency burden. It implies a read-only, safe operation by saying 'look up' and 'discover', and it mentions that the output includes 'valid labels and URIs'. However, it does not disclose response format, pagination, or any potential errors, leaving some gaps.

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 three sentences with no redundancy. It front-loads the purpose, then expands on the specific vocabularies, and closes with usage context. Every sentence contributes value.

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 single-parameter lookup tool with no output schema, the description provides sufficient context: what it returns (labels and URIs), the known vocabularies, and when to use it. It could be more complete by describing the return structure or adding an example, but it is not necessary given the tool's simplicity.

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 100% coverage with a single parameter 'vocabulary' that includes an enum and a detailed description for each value. The description reinforces the same information by listing the German terms, but it does not add meaning beyond the schema's own documentation, 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 uses a specific verb 'look up' and names the resource 'available values for WLO filter parameters'. It further lists the exact vocabularies, making the tool's function unambiguous and distinct from the sibling search and retrieval 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 states 'Useful before calling search tools to find the correct filter values', clearly indicating when this tool should be used. It does not explicitly name alternatives or when not to use it, but the context of pre-search lookup is sufficiently 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 no annotations provided, the description carries the full burden. It discloses the composite return structure (separate buckets { content, collections, topicPages }) and the flexible filter format (German labels or URIs). It does not mention rate limits or authentication, but for a read-focused search tool, these are less critical; the added context goes beyond the schema.

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 two tight sentences, front-loaded with purpose and usage. It conveys the key value proposition, return structure, and filter behavior without any fluff or repetition of schema details.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (11 parameters) and lack of output schema, the description sufficiently explains the tool's combined nature and the top-level result structure. It lacks examples of return values or error handling, but these are not essential for a search tool when the schema is thorough.

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 baseline is 3. The description adds value by clarifying that all filters accept German labels or URIs, and that maxCollections applies to both collections and topic pages. This extra semantic information enriches the parameter understanding beyond individual 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 "Kombinierte WLO-Suche" and explicitly lists the three content types (Einzel-Inhalte, Sammlungen, Themenseiten) searched in one parallel call. It clearly distinguishes from sibling tools by stating "Nutze dies statt mehrere Suchtools nacheinander zu rufen," indicating this is the combined variant.

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 provides explicit when-to-use guidance: use this tool instead of calling multiple search tools sequentially. This frames the alternative and the recommended context. Though it doesn't explicitly state when to use the individual tools, the contrast is clear enough to guide 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?

No annotations are present, so the description carries the full burden. It discloses domain semantics, synonym coverage, and filter input flexibility (labels and URIs), and hints at follow-up behavior. However, it does not describe result ordering, pagination, or what happens with empty queries beyond a parameter note, leaving gaps in behavioral expectations.

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 succinct: four sentences cover purpose, domain equivalence, workflow, and filter encoding. Every sentence earns its place with no redundancy or 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 8 optional parameters and no output schema, the description gives the essential workflow (search → nodeId → get_collection_contents) and domain clarifications. It does not explain the return structure or the markdown/json outputFormat behavior, but the schema covers the parameter details. Reasonably complete for a search 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 baseline is 3. The description adds cross-cutting parameter semantics: all filters accept both German labels and full URIs, and it explains the query parameter's German focus. This is meaningful beyond the individual schema descriptions, which mostly give examples and defaults.

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 'Search WirLernenOnline (WLO) for Sammlungen (= Themenseiten)', a specific verb+resource. It clarifies that Sammlung equals Themenseite and lists synonyms ('Themenseite Algebra', 'Sammlung Klimawandel', 'Portal Mathematik'), effectively distinguishing this from content search by directing to get_collection_contents.

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 clear usage cues: when users ask for Themenseite/Sammlung/Portal, this is the tool. It also gives a workflow ('Use the returned nodeId with get_collection_contents'). However, it does not explicitly contrast with sibling search tools like search_wlo_topic_pages or search_wlo_content, missing an opportunity for exclusion 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It adds meaningful details: 'multi-query expansion and quality-based reranking' and 'filters accept both German labels and full URIs'. These provide non-obvious behavioral context. However, it does not explicitly state read-only semantics or cover pagination/result format, leaving some gaps.

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 three sentences long with no fluff. It front-loads the core purpose, then adds supporting details (content types, search behavior, filter syntax) in a logical order. Every sentence contributes valuable information, achieving high information density without being verbose.

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 moderate complexity (9 parameters, no output schema) and lack of annotations, the description covers the essential aspects: what is searched, what content looks like, how search works (expansion + reranking), and filter value flexibility. It does not mention output format or defaults, but the schema covers those. This is reasonably complete for an agent to select and invoke 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?

Schema coverage is high (89%), so the schema already handles most parameter documentation. The description adds cross-cutting semantics not present in individual param descriptions: all filters accept both German labels and full URIs. This genuinely helps an agent understand how to provide filter values, going beyond the schema's examples.

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 'Search WirLernenOnline (WLO) for individual educational content items' with specific verb and resource, and distinguishes it from sibling tools by focusing on individual items (Inhalte/Materialien) as opposed to topic pages or collections. It also gives concrete examples of content types (worksheets, videos, lesson plans), making the purpose unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage when searching for individual educational materials, but it does not explicitly state when to use this tool versus alternatives like search_wlo_topic_pages or search_wlo_collections. There is no 'when not to use' or reference to sibling tools, so the guidance is implied rather than explicit.

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 no annotations provided, the description carries the full burden and does so thoroughly. It discloses specific output behaviors: result titling falls back to the owning collection or cm:title, never a cryptic ID; multiple variants are merged; target groups are returned as readable labels; ordering is deterministic. These details go well beyond basic search behavior and fully inform the agent of what to expect.

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 lengthy but well-structured with clear sections for search modes, output behavior, and ordering. Each sentence contributes useful information without redundancy. It could be tightened slightly, but given the complexity of the tool, the length is appropriate and easily digestible.

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?

Despite having no output schema, the description fully covers what the agent needs to know: the three modes, how results are titled and merged, target group label behavior, and deterministic ordering. All 8 parameters are semantically addressed in either the schema or description, and the tool's behavior is explained comprehensively. No significant gaps remain.

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 high (88%), so the baseline is 3, but the description adds real semantic value. It explains the meaning of query ('searches collections first, then checks linked Themenseiten'), collectionId ('bypasses the search'), and the sort parameter's behavior. It also clarifies output-related nuances like variant merging, which indirectly enriches understanding of mergeVariants and targetGroup. This extra context justifies a 4.

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 searches for Themenseiten (topic pages) on WirLernenOnline, using a specific verb and resource. It further distinguishes itself from siblings by detailing three distinct search modes (by collectionId, by topic, by filters only) and emphasizing the link to collections, making it unambiguous when this tool is appropriate.

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 clear context for each mode: collectionId is for a direct check, query is for thematic search, and filters-only lists all. The collectionId parameter explicitly mentions bypassing the search and being useful when a collection is already known from search_wlo_collections. However, it does not explicitly compare against all sibling tools (e.g., search_wlo_content, get_topic_page_content) to state when to prefer this one, so a small gap remains.

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 no annotations provided, the description carries the full burden of behavioral disclosure. It transparently explains what the tool checks (reachability/responding) and what it returns (latency, root nodeId, status flag), which is sufficient for a simple health-check operation. It does not delve into error handling or auth, but for this tool type, the disclosed behavior is adequate.

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 three sentences, front-loaded with the primary purpose, followed by return-value details and a practical use case. Every sentence contributes distinct value 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?

This is a low-complexity tool with no parameters and no output schema, so the description fully covers the essentials: what it does, what it returns, and when to use it. It is complete and self-contained, with no critical missing information.

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 correctly omits parameter details, as there is nothing to document. The schema is empty and consistent, requiring no additional explanation.

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 uses a specific verb ('Probe') and resource ('WLO repository API') to clearly define the tool's purpose as a health check. This distinguishes it from sibling search and retrieval tools, which focus on querying content rather than checking service availability.

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 clear context on when to use this tool: to differentiate service outages from empty search results, citing a concrete use case ('callers e.g. chatbots'). It does not explicitly state when not to use it or name alternative tools, but the guidance is strong enough for appropriate selection.

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