ColFin

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

Annotations already declare readOnly, idempotent and closed-world behavior, so the bar is lower. The description still adds real behavioral context: which fields are returned and the caveat that pension is 'alleen redactioneel gecontroleerd', warning the agent that pension data may be incomplete or missing for some records.

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 sentence that front-loads the action and field list. Efficient with no wasted words, though the parenthetical caveat at the end is slightly buried.

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 carries the burden of describing returns and does so by enumerating the key fields and flagging the pension caveat. Adequate for a single-parameter lookup 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 single UUID parameter is fully documented in the schema with format and pattern. The description adds nothing beyond the schema about the id, 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?

States a specific verb ('Geeft volledige metadata') and resource ('van één cao'), and enumerates the returned fields (looptijd, vakantiedagen, IKB, bron-URL, pensioen). The singular 'één cao' implicitly contrasts with the search sibling cao_zoeken, though that sibling is not named.

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?

Usage is only implied: the schema note that the UUID comes 'bijv. uit cao_zoeken' hints at the lookup-after-search workflow, but there is no explicit when-to-use statement or named alternative.

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, idempotentHint=true and openWorldHint=false, so the safety profile is covered structurally. The description adds that output includes an effective date, weekly hours and a data-quality indicator, which is useful since no output schema exists. However, it says nothing about authorization needs, lookups that fail, or how ambiguous cao names are resolved.

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 leads with the returned value and then enumerates the supporting fields. No filler, though it is terse enough that it forgoes any routing or usage 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?

With no output schema, the description usefully enumerates what the call returns (salary, effective date, weekly hours, data quality), which compensates for the missing return documentation. The lack of when-to-use guidance against three plausible siblings is the main remaining gap.

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 name, scale and step are already documented in the schema, including the default-step behavior. The description only restates that scale and step are inputs, adding no format or matching details beyond the schema, 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?

States a specific verb and resource: 'Geeft het bruto maandsalaris voor een schaal en trede binnen een Nederlandse cao'. It also names what comes back (ingangsdatum, werkweekuren, datakwaliteit). It does not explicitly distinguish itself from siblings like cao_details or cao_zoeken, so it stays at 4 rather than 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 statement of when to use this tool versus cao_details, cao_zoeken, cbs_loontrends, or financiele_parameters, and no prerequisites or exclusions. Usage must be inferred from the purpose alone.

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, idempotentHint=true and openWorldHint=false, so the safety and idempotency profile is covered. The description adds that results carry a reliability score, data quality indicator and status, which is real context beyond the annotations, but it says nothing about result limits, matching behavior or ordering.

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?

One compact sentence with the core action front-loaded and the optional sector qualifier placed after it. Nothing is wasted, though the return-value clause makes the sentence slightly 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?

For a read-only lookup with fully documented parameters and no output schema, the description covers what is searched and what the results contain. Adding a note on how it differs from cao_details would make it complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so both parameters (query and sector) are already documented in the schema; the description only restates that the search targets the cao name and that sector is optional. Baseline 3 applies since the schema does the heavy lifting.

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 ('Zoekt Nederlandse cao's op naam') plus the optional sector scope, and hints at the returned metadata (betrouwbaarheidsscore, datakwaliteit, status). It does not distinguish itself from the sibling cao_details or cao_salaris_trede, so the agent must infer the difference.

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

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

No when-to-use or when-not-to-use guidance, and no mention of the alternatives (cao_details, cao_salaris_trede, financiele_parameters) that share this domain. The 'optioneel per sector' note describes a parameter rather than a selection condition.

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

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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint=false, covering the safety and idempotency profile. The description adds useful domain context: the exact CBS table, the index base year, and that the result includes a year-over-year change. However, it does not describe the return format, pagination, or what happens when the optional sector parameter is omitted, leaving meaningful behavioral 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 a single, front-loaded sentence that states the core output without any filler. Every clause earns its place by specifying the sector scope, the source table, the index base, and the comparison period. It is appropriately sized for a one-parameter read-only tool.

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

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

Given the low complexity (one optional parameter, no nested objects) and the rich annotations covering safety and idempotency, the description is largely complete: it tells the agent what data is returned and how it is derived. The main missing piece is behavior when the sector parameter is omitted, and there is no output schema to fall back on for return structure. These are minor gaps against an otherwise sufficient definition.

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 fully documents the single optional sector parameter, including examples of sector names and SBI codes, giving 100% schema description coverage. The tool description does not add any further semantics about the parameter, such as how sector values are matched or what occurs when it is omitted. With schema coverage this high, a 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?

States a specific verb and resource: it gives the most recent CBS collective labour agreement wage index per sector, plus the year-over-year change, including the precise table ID (85663NED) and index base (2020=100). This is clear and specific enough that an agent can tell it apart from sibling tools like cao_zoeken or cao_details by content. However, it does not explicitly name or contrast with any sibling tool, so it falls short of a 5 on this dimension.

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 says what the tool returns but provides no explicit guidance on when to use it versus alternatives, nor any when-not conditions. Usage is only implied by the content. Like the calibration example update_drive, which received a 2 for lacking when-to-use guidance, this description offers no routing or selection advice.

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 cover readOnly, idempotent and openWorld=false, so safety is not the loader. The description adds real behavioral value beyond them: the response fields (bronlink, letterlijk bronfragment, ingangsdatum, datakwaliteit) and an explicit anti-hallucination constraint ('Geef nooit bedragen die niet in het antwoord staan'), which is important for an authoritative-amounts 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?

Front-loaded with purpose, then the module enumeration, then the search-fallback rule and the accuracy guard. The module list is long but each item is field-relevant, and every sentence earns its place with no filler.

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

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

There is no output schema, so the description correctly compensates by naming the returned fields. An agent has enough to call the tool and interpret results; the only missing piece is cross-tool routing versus the CAO/CBS siblings.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3, but the description goes further by naming the valid module values (minimumloon, inkomstenbelasting, toeslagen, etc.) in a schema that has zero enums, and by explaining the intended use of 'zoek' versus 'key'. That materially reduces the risk of an invalid module string.

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 officiële Nederlandse financiële bedragen') plus the returned metadata and an enumerated module list, so the agent knows exactly what domain this covers. However, it never distinguishes itself from the sibling tools (cao_zoeken, cbs_loontrends, cao_details), which an agent must disambiguate on its own.

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 one concrete routing rule — use 'zoek' when the exact key is unknown — which is genuinely useful parameter-selection guidance. But it provides no when-to-use / when-not-to-use guidance relative to the sibling CAO and CBS tools, leaving tool selection to inference.

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