KentekenKompas Vehicle Knowledge

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds meaningful interpretive context: the relation is pre-validated and not necessarily a direct alternative, which helps the agent reason about the result. 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 a single, tightly written sentence that front-loads the action and object, followed by one focused semantic caveat. Every word earns its place.

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

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

For a simple two-parameter, read-only tool with an output schema and safety annotations, the description covers the core operation and an important interpretation warning. It does not describe behavior when no relation exists, but the presence of an output schema reduces the need for return-value detail.

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?

Input schema descriptions have 0% coverage, so the description carries the burden. It clarifies that both parameters are 'exact modelKeys', which is useful, but it does not distinguish sourceModelKey from targetModelKey or add much beyond the schema's own pattern and names. Compensation is only partial.

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 ('Return') and resource ('validated relation between two exact modelKeys'), making the tool's function immediately clear. The caveat that a relation is not automatically a direct alternative helps distinguish it from search or context tools like search_vehicle_knowledge.

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 this tool is for precise model-key comparisons, but it never explicitly states when to use it over sibling tools or what alternatives exist. The caveat about direct alternatives aids interpretation but does not provide clear usage routing or exclusions.

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 signal read-only, idempotent, non-destructive behavior. The description adds useful behavioral context beyond those hints: the term must already exist, and the tool will not fabricate or fuzzy-match terms. It does not describe failure behavior for unknown keys, but the output schema likely covers result 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 a single, front-loaded sentence that delivers the core requirement and an important behavioral constraint with no filler. Every word earns its place.

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

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

For a single-parameter tool with an output schema and safety annotations, the description covers the key invocation requirement and an important limitation. The main gap is that 'supported normalized term form' is left underspecified, and no example term key is provided, but the overall context is sufficient for basic correct invocation.

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 only provides a regex pattern and length constraints for termKey, with 0% description coverage. The tool description compensates by explaining that the key must be an exact existing term key or a supported normalized form, and warns against fuzzy generation. This adds meaningful conceptual meaning, though examples of normalized forms would strengthen it.

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 identifies the action ('Explain'), the specific resource ('one existing Dutch vehicle term'), and the exact-match constraint ('no fuzzy generation'). This distinguishes it from sibling knowledge-search tools like search_vehicle_knowledge, which likely handle broader or fuzzy retrieval.

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 the required input condition: an exact term key or a supported normalized term form. It also tells the agent not to attempt fuzzy generation. However, it does not explicitly name an alternative tool for cases where the agent lacks an exact key.

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 tool as readOnly, idempotent, and non-destructive. The description adds that it returns an existing answer and never triggers new text generation, which is a useful behavioral nuance beyond the raw hints. It does not address error cases or the semantics of 'stable', so it adds only limited additional transparency.

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 sentence that front-loads the main action (Get), names the resource, and adds the critical qualifier 'without generating new text.' There is 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?

The tool is a simple get-by-id operation with one parameter, a rich annotation set, and an output schema. The description covers the retrieval semantics and non-generation behavior, which is enough for an agent to select and invoke the tool. Minor omissions like not-found behavior or the source of answerId do not undermine completeness given the schema and annotations.

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?

With schema description coverage at 0%, the description carries the full burden of explaining the single parameter. It identifies answerId as the stable retrieval key for an existing Direct Answer, giving semantic meaning that the schema's pattern alone lacks. While it could also explain where answerId comes from, the provided meaning is sufficient for a one-parameter tool.

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 (Get), a concrete resource (KentekenKompas Direct Answer), and the retrieval key (stable answerId). It also clarifies the operation does not generate new text, which implicitly separates it from generation and search tools. It does not explicitly name a sibling, so it stops short of a perfect 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?

The description implies the appropriate use case: when an agent already has a stable answerId and needs the existing Direct Answer, without generating new text. It provides a clear prerequisite (stable answerId) and a when-not (no text generation), but it does not name alternative tools like search_vehicle_knowledge or get_source_context. This is clear context with no explicit alternatives/exclusions beyond the no-generation caveat.

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 establish read-only, idempotent, and non-destructive behavior. The description adds meaningful extra context by promising the tool 'validated' information and explicitly stating it never invents a current price, which is a behavioral guarantee not present in the 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 entire description is one tight sentence with no filler. The main function is front-loaded, and the crucial behavioral caution about not inventing prices is appended in a clear semicolon-separated clause.

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 zero-parameter, read-only, idempotent tool with an output schema present, so the description does not need to explain input or return structure. It covers what the tool provides, validates, and explicitly refuses to do, making it complete for correct invocation.

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 description carries no parameter-documentation burden. The empty schema is fully covered, and no parameter semantics are needed beyond what the schema already expresses.

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 ('fuel-price source status and limitations') and a clear verb ('get'), and distinguishes itself from any price-inventing behavior by stating it never invents a current price. This is specific enough to separate it from generic context 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 gives no explicit guidance on when to use this tool versus alternatives like get_source_context or get_answer_context. The domain-specific wording implies a use case, but there are no stated conditions, exclusions, or sibling references.

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 provide read-only, idempotent, non-destructive cues. The description adds useful context beyond annotations: the returned data is 'validated' and 'public', and the scope is model-level rather than vehicle-specific. 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?

A single, front-loaded sentence communicates the action, the resource, and the key scope distinction with 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?

The description is adequate for a simple read-only lookup, and an output schema exists to document return values. However, the missing explanation of includeAnswers and the lack of explicit routing relative to sibling search/context tools leave a noticeable 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 0%, so the description needed to explain the parameters, but it only clarifies that modelKey must be exact. The includeAnswers boolean parameter is never mentioned, leaving its purpose unclear.

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 and resource: 'Get validated public context for one exact modelKey'. It also disambiguates from vehicle-level assessment by stating this is model-level knowledge, though it does not name 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 wording implies use when an exact modelKey is known and model-level context is needed. It does not explicitly state when to choose this over sibling tools such as search_vehicle_knowledge or get_answer_context, nor does it describe exclusion conditions.

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 establish read-only, idempotent, and non-destructive behavior. The description adds non-redundant context by saying the resource is public and that composite-looking IDs are opaque and never split, which prevents an agent from misinterpreting the ID format. It does not explain not-found behavior, but the output schema and read-only annotations reduce the need for that 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 short sentences with no filler. The core action is front-loaded, and the critical opaque-ID warning is placed in the second sentence where it is easy to retain.

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-required-parameter, read-only, idempotent lookup with an output schema, this definition is complete enough for correct invocation. The schema covers the parameter constraint, annotations cover side-effect safety, and the description clarifies the ID semantics and public scope. No essential operational detail 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?

With zero parameter descriptions in the schema, the description carries the semantic load. It says sourceId identifies a public SOURCE or SOURCE_GROUP and adds the key warning that seemingly composite IDs are opaque and must not be split. This is meaningful beyond the structural pattern, though it does not enumerate example IDs or distinguish how source-group values are represented.

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 and object: 'Get one exact public SOURCE or SOURCE_GROUP'. It also adds a distinguishing semantic—'Composite-looking source IDs are opaque and are never split'—so the operation is clearly an exact opaque-ID lookup rather than a search or aggregate. It does not explicitly contrast with sibling tools, so it misses the highest bar.

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 wording 'one exact' and 'SOURCE or SOURCE_GROUP' implies the tool should be used when the agent already has a concrete source identifier and needs its context. It also warns against constructing or splitting composite-looking IDs, which guides call construction. However, it never names alternatives or states when not to use this tool, leaving the boundary with search_vehicle_knowledge and the other get_* context tools to inference.

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 destructiveHint, so the safety profile is covered. The description adds valuable behavioral context: results are based on deterministic lexical relevance, and 'relevanceScore is not AI-confidence' is an important caveat preventing misinterpretation of search results.

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 entire description is one sentence with no filler. It front-loads the core purpose and includes the most important behavioral caveat in a compact second clause. Every word 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?

The output schema and annotations cover return structure and safety, while the description covers scope and relevance semantics. However, missing usage guidance and parameter semantics leave the agent to infer when to invoke this tool versus the knowledge-focused siblings, so the context is not fully 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 0%, so the description carries the burden of explaining 'query' and 'limit'. It does not mention either parameter or clarify how the query is matched or how limit affects results. The parameter names are fairly self-explanatory, but the description adds no semantic value 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 clearly states the action ('Search'), the resource ('public KentekenKompas model, answer, term and provenance knowledge'), and the method ('deterministic lexical relevance'). It is specific enough to identify the tool's function, though it does not explicitly distinguish it from sibling knowledge 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 gives no guidance on when to use this tool versus alternatives like explain_dutch_vehicle_term, get_answer_context, or get_model_context. The deterministic-lexical-relevance note implies a use case for exact keyword searches, but no when-to-use or when-not-to-use instructions are provided.

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