Klicbot

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

With no annotations, the description carries the burden and does well: it states nothing is submitted, that address/file input immediately opens an editable map with proposal, price and quote, that the response contains the cost breakdown and leges, and that only the final quote should be confirmed. Auth, rate limits and error behavior are unaddressed.

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?

Purpose is front-loaded in the opening sentence and the type/alias rule follows immediately. The calamity-report paragraph is a digression but earns its place as a when-not-to-use signal; the flow is otherwise tight.

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 an 11-parameter tool with no annotations and no output schema, the description covers the flow and response shape ('verdeling in delen en de leges') but leaves nearly half the parameters semantically undefined, so an agent must guess at crs, reference and client_ref.

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 0% across 11 parameters, so the description must compensate. It explains klic_type (with enum values and alias), job_id semantics, and that address/file are alternative input modes, but crs, reference, client_ref, geometry, and the file_url/file_base64/filename split receive no explanation beyond hints.

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 first sentence names the priced resource types (graafgebied, oriëntatiegebied, adres, bestand) and 'Dient niets in' clarifies that this is a quote-only operation, not a submission. That distinguishes it from confirm_klic_melding, though the sibling is never named 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?

It gives concrete selection rules: klic_type GRAAF vs ORIENT (including that ORIENTATIE is an alias and has no start_date), when to supply job_id to amend an existing quote versus create a new job, and that calamity reports must go via klicbot.nl rather than this tool. No explicit routing to get_klic_request or confirm_klic_melding by 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?

With no annotations, the description carries the full burden and does real work: it clarifies there is no Kadaster submission, discloses the write-permission requirement on the API key, states the post-condition ('De order blijft payment_pending'), and quotes the exact rejection text for a stale quote. It does not address whether repeated calls can double-charge or what happens if payment initiation fails, which keeps it off a 5.

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?

Six short sentences, front-loaded with what the tool does and what it does not touch, then preconditions, then failure mode. Every sentence carries information an agent could not get from the schema or annotations.

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 payment-mutating tool with no annotations, this covers preconditions, permission, the stale-quote failure path, and the resulting order state; an output schema exists so return values need not be described. The only real hole is the unexplained required job_id, which an agent must guess the provenance of.

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 0%, so the description must compensate, and it explains three of four parameters well: confirmed must be true, quote_hash comes from check_klic_price, and customer_total_eur must match the stored quote (with a mismatch surfacing as the stale-quote error). job_id is never explained, which is the one remaining gap.

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 ('Start de betaling van een gequote KLIC-melding') and immediately draws the boundary that matters most for this domain: 'Er gaat niets naar het Kadaster'. An agent can distinguish it from check_klic_price, which produces the quote this tool consumes.

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 an explicit gating precondition ('Alleen aanroepen nadat de gebruiker de laatste prijs expliciet heeft bevestigd') and points to check_klic_price as the source of quote_hash, which effectively describes the required call order. It stops short of naming a sibling to use instead or stating explicitly what to do when the precondition is unmet, so 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?

With no annotations, the description must carry the whole burden. It does disclose one behavioral trait – that output size is bounded by max_features and that 0 means unlimited and should be used cautiously for large packages – but says nothing about permissions, whether the call is read-only, or the size/format characteristics of the returned geometry.

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, no filler, with the payload-size caveat placed alongside the parameter it concerns. Appropriate size for a two-parameter 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?

The output schema already documents return values, so that omission is acceptable. What is missing is a clear statement of what order_id refers to and how this differs from the sibling summary tool, which matters for correct invocation in a family of KLIC 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?

Schema description coverage is 0%, so the description must compensate. It explains max_features well (including the 0 = unlimited semantics not stated in the schema), but order_id is never described beyond the implicit 'voor een project', leaving the crucial identifier's source and format unexplained.

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: 'Haal IMKL GeoJSON op voor een project', which tells an agent exactly what the tool retrieves. It does not distinguish itself from the sibling klic_geojson_summary, so an agent must infer which of the two to pick.

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 a caution about large packages when max_features=0, but no guidance on when to use this tool versus klic_geojson_summary or get_klic_request, and no prerequisites (e.g. that an order must exist) are 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?

With no annotations, the description carries the full burden and provides almost nothing: 'get' implies a read, but there is no mention of permissions, behavior when the order_id is unknown, or whether the call is side-effect free. The presence of an output schema covers return values, but the behavioral profile is undocumented.

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 short sentence with zero filler, and the key concept (one request, by order_id) is front-loaded. It is efficient rather than bloated, though brevity here edges into under-specification.

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, so return values need not be explained, but for a tool with no annotations and an undocumented parameter the description leaves out errors, permissions, and routing to the ten sibling tools. An agent has to infer nearly all calling context.

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 0% with one required parameter, so the description must compensate, yet it only restates the parameter name ('order_id') as the identifier of the request. It gives no format, expected source, or validity constraints for that ID.

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 ('Haal detail op van één KLIC-aanvraag'), making clear it fetches a single record. The word 'één' implicitly distinguishes it from list_klic_requests/search_klic_requests, but no sibling is named 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?

There is no statement of when to use this tool versus list_klic_requests, search_klic_requests, or get_klic_geojson. The only hint is the required order_id, which the agent must infer means 'I already know which request I want'.

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 full behavioral burden. It does not state that the call is read-only, side-effect free, or static, nor does it explain what the overview actually contains beyond the word 'overzicht'. The only behavioral signal is an implicit one from the noun 'overview'.

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 short clause with no waste, but also almost no content — it is under-specified rather than economical. It is front-loaded but offers the agent only one piece of 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?

With an output schema present and zero parameters, the description does not need to explain return values. However, for a no-annotation discovery tool it should at least say that it is a safe read and when to prefer it over the domain tools, which it omits.

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 zero parameters, so there is nothing for the description to disambiguate; the baseline of 4 applies. The empty schema is consistent with a no-argument introspection call.

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?

Names a specific resource: an overview of MCP tools, resources, and REST API scope. That clearly separates it from the KLIC operation siblings (price checks, requests, geojson, dossiers). It lacks a strong action verb ('Overzicht van...' is a noun phrase), which keeps it just short of a 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 call this tool, when not to, or how it relates to the other discovery-oriented siblings such as klic_status or list_dossiers. The agent must infer that this is a discovery/introspection 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?

No annotations are provided, so the description carries the full burden. It usefully discloses that geometry is stripped and only counts plus a sample of properties are returned, but says nothing about permissions, delivery size limits, or whether the sample is stable across calls.

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 short sentence with no filler, and the key differentiator (no raw geometry) lands before the reader has to dig. It could still spend a clause on the parameters without becoming bloated.

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 so return structure needn't be restated, and the description covers the summary's shape. But with zero annotation coverage and zero parameter documentation, an agent cannot tell what max_sample does or what input constraints apply.

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% and the description mentions neither parameter. order_id is guessable from its name, but max_sample (default 20) is completely opaque — sample of what, features or properties — and must be documented somewhere.

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 action on a specific resource: a compact summary of an IMKL delivery yielding feature count plus a few properties. The phrase 'zonder ruwe geometrie' implicitly separates it from get_klic_geojson, though no sibling is 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 by the contrast with raw geometry — an agent can infer 'use this instead of get_klic_geojson when you don't need coordinates', but there is no explicit when/when-not, no prerequisites, and no 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?

No annotations are provided, so the description carries the full disclosure burden. It hints at possible states ('gequote of ingediende') but says nothing about whether this is a read-only operation, whether status polling is expected, how long processing takes, or what transitions occur. Significant gap for an unannotated 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?

A single, front-loaded sentence with no waste. Slightly terse given the disclosure burden, but efficient.

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, so return values need not be explained. However, with no annotations and no mention of polling behavior or state semantics, an agent lacks guidance on how to interpret and iterate on results.

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 0% for the single job_id parameter, so the description must compensate. It does add real value by naming the provenance of job_id (check_klic_price), which the schema does not, but gives no format or validity details.

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: retrieving the status of a KLIC notification, and scopes it to quoted or submitted notifications. This distinguishes it reasonably from siblings like get_klic_request, though it does not explicitly contrast with them.

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 parenthetical '(job_id uit check_klic_price)' implies the workflow — call check_klic_price first, then poll status here — but never states when to use this versus get_klic_request or list_klic_requests. Usage is implied, not spelled out.

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 must carry the behavioral burden; it usefully discloses that results exclude phone, email, and raw GeoJSON, which is meaningful privacy/field-filtering context. However, it omits whether this is read-only (implied but not stated), how pagination behaves, and any auth or rate-limit considerations.

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?

It is a single front-loaded sentence with no filler, and the exclusion list is placed immediately after the core action. It could be slightly more structured, but there is no wasted verbiage.

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 no annotations, no parameter descriptions, and no usage guidance, the description is too thin. It benefits from an existing output schema and the field-exclusion note, but it leaves out pagination behavior, read-only status, and sibling differentiation that an agent needs 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 0% and the description says nothing about the page or page_size parameters. The only meaning available comes from parameter titles and defaults, so the description fails to compensate for the documentation gap on pagination.

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 (Lijst) and resource (dossiers) with organization-level scope, so the core operation is clear. However, it does not distinguish 'dossiers' from sibling resources like list_klic_requests or search_klic_requests, leaving the agent to infer whether these are the same or different objects.

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 list_klic_requests, search_klic_requests, or get_klic_request. The description merely states what it lists, leaving the choice between listing and searching entirely to the agent.

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, and it discloses only that results are paginated and scoped to the caller's organization. It says nothing about ordering, permissions/authentication requirements, maximum page size, or behavior when the page is out of range.

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 with no filler. It is efficient, though its brevity comes at the cost of the missing details noted in other dimensions.

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, so return values need not be explained, but for a paginated listing tool with zero annotation coverage and 0% parameter documentation, the description leaves too much unspecified, especially the sibling distinction from search_klic_requests.

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% for both parameters, so the description must compensate, but it only hints 'paginated'. It gives no meaning for 'page' (1-based? default 1?) or 'page_size' (default 50, any maximum?), leaving the agent to guess from bare 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?

States a specific verb and resource ('Lijst KLIC-aanvragen') plus a scope ('van jouw organisatie') and a pagination hint. However, it does not distinguish itself from the sibling search_klic_requests, which an agent could easily confuse with this listing tool.

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 versus search_klic_requests or get_klic_request, and no preconditions. Usage can only be inferred from the name and the 'jouw organisatie' scope.

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 zero annotations the description carries the full burden, and it does disclose one important trait: filtering is client-side and limited to 'the first pages', so results can be incomplete. However it never says how many pages are fetched, whether results are ordered, or what permissions are needed — significant gaps for an unannotated 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?

One compact sentence with the searchable fields front-loaded and no filler. The parenthetical caveat is worth its space, though it could be sharpened into a concrete depth limit.

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, so return shape need not be described. But with no annotations and 0% schema coverage, the description should clarify the 'first pages' boundary, pagination behavior, and page_size semantics; as written, an agent cannot predict the completeness of results.

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 0%, so the description compensates partially: it explains what 'query' matches (address, project name, order_id) and what 'status' filters on. It says nothing about 'page_size' (default 100) or how query and status combine, leaving a third of the parameters undocumented in both places.

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 (search/filter requests) and enumerates the searchable fields: address, project name, order_id, status. It is distinguishable from siblings like list_klic_requests and get_klic_request, though it never names them explicitly to confirm the 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 parenthetical 'client-side filter over the first pages' implies this is a convenience filter rather than an exhaustive search, which hints at when to prefer list_klic_requests. But no alternative is named and no condition for choosing between them is stated, so usage must be inferred.

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 and does disclose one genuine behavioral trait: the resulting links must be opened in a logged-in browser, implying auth-gated resources. However it says nothing about link lifetime/expiry, permission requirements, or failure behavior for a link-generation tool where that matters.

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, and the primary information (what links the tool yields) is front-loaded. Slight terseness at the cost of clarity rather than 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?

Output schema exists so return values need not be described, and there is only one parameter. Still, for a tool that produces access links, the absence of any note on validity, permissions, or what an order_id refers to leaves an agent guessing.

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 must explain the single parameter, yet it only restates that an order_id is required. Nothing about its format, where to obtain it, or whether it refers to a dossier or a Klic request.

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 resource produced (a dossier link and viewer link) for a given order_id, but gives no verb and no indication of what generates the link (a dossier? a request?). It is more specific than the bare name 'viewer_link' but not enough to cleanly separate it from siblings like get_klic_request or list_dossiers.

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?

'Openen in een ingelogde browser' is a prerequisite (authentication context), not guidance on when to choose this tool over alternatives. No indication of when a viewer link is needed versus a dossier link, nor any reference to sibling tools.

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