Abonnement24 deals

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and a closed world, so the safety profile is fully covered. The description adds the genuinely useful fact that results carry storage variants and deal counts, but says nothing about pagination or result 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?

A single well-formed sentence with the resource and its scope front-loaded, and no filler. It is perhaps slightly under-informative rather than 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?

With no output schema, the description carries the return-content burden and does so partly by mentioning storage variants and deal counts. For a simple two-optional-parameter read tool with rich annotations, this is nearly sufficient, though it omits pagination behavior.

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 brand and limit are already documented in the schema (including default 50 / max 100). The description adds no parameter-level meaning, 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 clear verb (list) and resource (phones with current subscription deals) and adds useful scope detail (storage variants, deal counts). It does not explicitly contrast itself with the close sibling search_phone_deals, so an agent must infer the boundary between the two.

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, when-not-to-use, or named alternative is given. Usage is only implied by the phrase 'actuele abonnementsdeals', leaving the agent to guess how this differs from search_phone_deals and search_sim_only.

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 readOnly, idempotent, and non-destructive, so the safety profile is covered. The description adds genuinely new behavioral context: results are sorted by average monthly price over the term, and each result carries speed, price, term, and a link. It does not discuss rate limits or pagination, but the added sorting/return behavior is real value.

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 with no filler, front-loaded with the resource and scope, then the sort order and return fields. Efficient, though the phrasing 'internet en internet met tv' is slightly redundant.

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 explains the return shape (speed, price, term, link) and the ordering. For a six-parameter, zero-required search tool whose params are fully schema-documented, this is largely complete; only explicit sibling routing 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?

Schema description coverage is 100%, so all six parameters (tv, limit, minSpeed, provider, connection, maxMonthly) are already documented in the schema. The description only alludes to the tv filter and price sorting, adding nothing beyond what the schema provides; 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 states a specific verb and resource: it searches home internet and internet+TV packages in the Netherlands with current prices. This clearly separates it from siblings like search_phone_deals and search_sim_only, though it does not name 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?

Usage is implied by the domain (home internet in NL) but there is no explicit when-to-use, when-not, or alternative routing. An agent can infer the context but must reason about when this beats its siblings rather than being told.

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 read-only, idempotent, non-destructive and closed-world. The description adds behavior the annotations don't cover: the sort order (average monthly price over 24 months including device), the default data minimum, and the specific fields returned (monthly price, one-time cost, total price, link) — valuable given there is no output 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?

Three front-loaded sentences: purpose and sort first, output fields second, the data-default caveat last. Efficient overall, with minor redundancy in re-explaining minDataGb already present in the schema.

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 eight-parameter, zero-required, read-only search tool with no output schema, the description covers purpose, sorting, defaults, and the shape of returned results. Missing only explicit guidance on combining filters and sibling selection, so it is largely 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 each parameter is already documented. The description only restates the minDataGb default rule (1 GB, 0 = all) that the schema itself already contains, adding no syntax or filtering semantics beyond the structured fields. 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?

States a specific verb and resource (searching phones with a bundled subscription) plus geographic scope (Netherlands), example devices, and the exact sort criterion and currency of price. The purpose is unambiguous, though it never explicitly names the sibling search_sim_only, so the contrast with the plan-only tool must be inferred.

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 default-behavior guidance (defaults to at least 1 GB data; minDataGb=0 unlocks no-data plans), which implies how to use the tool. However it gives no explicit when-to-use/when-not framing and never routes the agent to list_devices, search_internet, or search_sim_only, 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.

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

Annotations already declare this a safe, idempotent, read-only, closed-world operation, so the safety profile is covered. The description still adds real behavioral context beyond the annotations: the sort order (average monthly price across the term) and the per-result contents (price, data, minutes, contract duration, link). No pagination or rate-limit detail, which is a minor gap.

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 packs purpose, provider set, sorting rule, and return fields with no filler. It is efficient, though cramming the result fields into the same sentence slightly weakens scannability.

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 eight optional filters, no required parameters, and no output schema, the description usefully compensates by naming the fields each result contains and the sort order. An agent has enough to call and interpret it, with only sibling routing and result limits unspecified.

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% for all eight filters (esim, fiveG, provider, minDataGb, maxMonthly, unlimitedData, monthlyCancellable, limit), so the schema carries full parameter meaning. The description adds nothing parameter-specific, making the baseline 3 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 states a specific verb and resource ('Zoekt sim only abonnementen in Nederland'), names concrete providers, and adds scope details (sorted by average monthly price over the contract term). It does not, however, explicitly differentiate itself from the sibling 'search_phone_deals', so an agent must infer the boundary from the name alone.

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 implied by the domain (SIM-only subscriptions vs. device or internet searches), but there is no explicit guidance on when to pick this over search_phone_deals or search_internet, and no stated prerequisites or exclusions. Adequate but leaves routing to inference.

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