Caowijs

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the description doesn't need to restate safety. It adds real value by disclosing the return content shape (Kern, Details, Historie, Open vragen, Bronnen), which no output schema exists to convey. It says nothing about size limits or whether the page label must come from 'onderwerpen', but for a safe read the coverage 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?

Two tight sentences: the first describes output, the second gives usage conditions. No filler, and the purpose leads.

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 no output schema, the description usefully enumerates the page sections, which is exactly the missing return-value information. Combined with the explicit usage trigger, an agent has enough to call it correctly; only the linkage to the 'onderwerpen' label source is left implicit.

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 there is a single required parameter, so the schema carries the semantic load. The phrase 'één hele pagina' signals that one page is returned per call, but adds no format or provenance detail beyond what the schema already states.

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+resource ('Geeft één hele pagina van de kennisbank') and enumerates the page's internal structure, which tells the agent exactly what it retrieves. It implicitly contrasts with the zoek sibling by mentioning search results, but does not name or distinguish the onderwerpen sibling.

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 positive selection criteria: use it when you need the coherence/context, or when a search result supplies too little context. This effectively routes the agent away from 'zoek', though the 'onderwerpen' alternative is never mentioned.

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 openWorldHint=false, so the safety profile is covered. The description adds value beyond that by disclosing what each entry returns (name, coverage, applicable period, last-updated timestamp), which is meaningful given there is no output schema, but it says nothing about result size or how listing interacts with the 'per pagina' framing given there are no pagination parameters.

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 dense but front-loaded sentence: the action leads, the returned fields follow, and the usage condition closes it. No filler or redundant restatement of the title.

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 listing with no output schema, the description covers what the tool does, what each entry contains, and when to reach for it. The only soft spot is the slightly ambiguous 'per pagina' phrasing (implies pagination that the empty schema does not expose), which an agent may briefly puzzle over.

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 takes no parameters, so per the rubric the baseline is 4. Nothing in the description needs to compensate for undocumented inputs.

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 ('Geeft de lijst met onderwerpen in de kennisbank') scoped to the Cao voor Uitzendkrachten, and contrasts with searching by noting it is the fallback 'als zoeken niets oplevert'. It is clearly distinct from lees_onderwerp (single topic) and zoek (search), though it never names those siblings explicitly.

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 two explicit trigger conditions: browsing what the knowledge base contains, or recovering when a search returns nothing. That effectively communicates the alternative to zoek, but gives no negative guidance (e.g. when lees_onderwerp is the better call once you already know the topic name).

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 openWorldHint=false, so safety is covered. The description adds valuable behavioral detail beyond that: results are labeled as 'geldt nu', 'historie', or 'open vraag' and include page and source link, telling the agent how to interpret result validity. No rate limits or auth requirements are mentioned, but those are not crucial 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?

Two tightly written sentences: the first front-loads purpose and return format, the second gives usage and examples. No filler, and the most important information (what is searched and what comes back) leads.

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 no output schema, the description must explain returns, and it does: matching text passages with labels, page, and source link. It does not elaborate on the meaning of the labels or result ranking, and the default result count is left to the schema. Adequate for a 3-parameter read-only search tool, with minor 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?

Schema description coverage is 100%, so baseline is 3. The description adds meaning for the main parameter by instructing to phrase the vraag in ordinary Dutch words and giving concrete examples. It also adds guidance for onderwerp ('Laat weg om overal te zoeken'), which goes beyond the schema's description of that field.

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: searches by keyword in the knowledge base about the Cao voor Uitzendkrachten and returns best-matching text passages. The return shape (text pieces with labels, page, source link) is specified, and it implicitly contrasts with siblings lees_onderwerp and onderwerpen by referencing the latter for page scoping. An agent can distinguish this keyword-search tool from the topic-listing and topic-reading 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?

Provides useful usage context: ask in plain Dutch, with examples like "wachtdagen bij ziekte", and the onderwerp parameter can restrict to one page or be omitted to search everywhere. However, it never explicitly says when to use this tool versus lees_onderwerp or onderwerpen, nor when not to use it. Usage is implied rather than routed.

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