Interfibra

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

Annotations already establish the safe read-only profile, and the description adds real operational context on top: the listing is not authoritative for eligibility (FTTH at the address is required), the voucher is issued by Open Fiber under its own conditions, and inactive initiatives must not be proposed. It stops short of describing the response shape or the meaning of fields other than inElenco/attiva.

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?

Roughly five sentences, each carrying distinct information (purpose, trigger, parameter effects, eligibility caveat, inactivity guard). Slightly dense in the opening clause, but front-loaded with the tool's identity before the usage rules.

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 has to carry the return semantics, and it does explain the grouping and key fields (inElenco, attiva). It remains incomplete on the full response structure, but an agent can call it correctly and interpret the answer.

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 the baseline is 3, but the description goes beyond the schema by explaining the effect of each parameter on the result set: `comune` yields an inElenco membership answer, `provincia`/`regione` narrow the list, and no parameters returns everything.

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 the specific artifact (the 100 € Open Fiber 'La Fibra che ti premia' voucher, activations by 31/12/2026), what it returns (conditions, dates, municipalities grouped by region and province), and clearly separates it from verifica_copertura, which is named as the different tool for address-level eligibility.

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?

Explicit trigger ('Usalo quando il cliente chiede del buono o di promozioni in un comune'), explicit filtering behaviour per parameter, an explicit handoff rule to verifica_copertura for the real check, and an explicit exclusion ('Con `attiva` false ... non proporla'). Nothing about when to pick this vs a sibling is left 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=true, idempotentHint=true, openWorldHint=false and destructiveHint=false, so the safety profile is covered. The description adds one useful piece of context — that the payload includes the router and its conditions — but says nothing about auth needs or payload shape beyond that.

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 — the resource, the required input, and the notable return content are all packed in efficiently. Not padded, though also not especially well structured for scanning.

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 must speak to returns, and it does ('tutti i dati ... compreso il router con le sue condizioni'). For a simple one-parameter read lookup with full read-only annotations, this is close to complete; only slug provenance and error behaviour are unaddressed.

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 carries the burden for the single 'slug' parameter. 'dato il suo slug' tells the agent the identifier is an offer slug, which is helpful, but gives no format, source, or validity guidance.

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 the resource and scope precisely ('tutti i dati di una singola offerta'), and the singular 'singola' implicitly distinguishes it from the sibling elenco_offerte (list of offers). The retrieval verb is implied rather than stated, so it falls 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 explicit when-to-use guidance, no prerequisites (e.g. where the slug comes from, whether the offer must be active), and no named alternative. The only hint is the singular/plural contrast with elenco_offerte, which the agent must infer.

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, so safety is covered. The description adds meaningful context beyond them: prices are live from the site ('non memorizzati') and the Open Fiber voucher note is time-limited ('finché dura'), which are genuine behavioral traits an agent could not derive from 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 main purpose is front-loaded, but the body is a single sprawling sentence with a long comma/colon-separated enumeration and a semicolon clause. It is information-dense yet hard to scan; a short structured list of returned fields would serve the agent better.

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 full return-value burden and largely meets it by enumerating the concrete fields (canone, sconti, router, costi di uscita, fatturazione, notaBuonoOpenFiber). Combined with the rich annotations, an agent has enough to call it correctly, though the enumeration is not exhaustively organized.

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% and the single enum parameter 'pubblico' is fully documented in the schema, so the schema does the heavy lifting. The description gestures at the concept ('per chi è l'offerta') but adds no syntax or filtering semantics beyond what the schema already provides; 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 resource (the Interfibra price list) and enumerates exactly which attributes it returns (canone, router, costi di uscita, tempi di attivazione, etc.), so an agent understands the payload well. It does not, however, distinguish itself from the sibling dettaglio_offerta, which appears to cover a single offer rather than the list.

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 explicit when-to-use, when-not, or alternative routing. The phrase 'attivabile oggi' implies it surfaces currently activatable offers, but nothing tells the agent to pick this over dettaglio_offerta or verifica_copertura; the choice is left 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, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds genuinely useful behavior beyond that: it enumerates the returned fields (titolo, testo, URL da citare, metadati) and states a price-freshness caveat ('prezzi del listino di adesso; fa fede la scheda di trasparenza tariffaria'), which an agent cannot infer from structured fields.

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 dense sentences, front-loaded with what is returned and the required input, followed by the price caveat. No filler, though the enumeration of return fields is slightly redundant with the output 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?

An output schema exists, so return structure need not be explained, yet the description still covers input provenance, id format, and the price-authority caveat. Nothing an agent needs to call fetch correctly is missing; the only mild redundancy is listing returned fields.

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 the schema already documents the single id parameter, which justifies a baseline of 3. The description goes further by showing the id's actual syntax via three namespaced examples, giving the agent concrete pattern knowledge the schema lacks.

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 (return the full text of a content) and the resource, and explicitly anchors it to the sibling tool that produces the input: 'un contenuto trovato con search'. The namespaced id examples ('offerta:…', 'pagina:…', 'comune:…') make the contract unambiguous, distinguishing it from search/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?

The description makes clear this is the follow-up step to search and that the input must come from a search result. It does not name an explicit alternative or a when-not condition, but for a single-purpose lookup tool the routing context is unambiguous.

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, destructiveHint=false and a closed world, so the safety profile is fully covered. The description adds content scope (which topics are covered) but nothing operational such as freshness/caching or response shape. 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 anchored on "Dati dell'azienda" followed by a comma-delimited topic list. The enumeration is long but each item is a distinct topic index with no filler or repetition.

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 input parameters and no output schema, the topic enumeration effectively serves as the return-content contract and is fairly thorough. It stops short of stating the response format or availability of each item (e.g. the voucher is noted as time-limited), but for a static info tool this is close to sufficient.

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 the baseline is 4. There is nothing for the description to disambiguate on input, and it does not mislead about any parameters.

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 resource (azienda Interfibra) and enumerates the specific domains covered: contatti, orari, tecnologie, prezzi, fatturazione, buono Open Fiber. An agent can tell it is the general company-information lookup. It does not, however, name or contrast itself with the overlapping sibling buono_open_fiber, which also covers the voucher topic.

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 explicit when-to-use, when-not-to-use, or alternative routing. The topic list implies it answers company/FAQ-style questions, but with siblings like buono_open_fiber and dettaglio_offerta overlapping on content, the description gives no rule for choosing between them.

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?

Beyond the readOnly/idempotent annotations, the description discloses meaningful behavior: the link does not create orders, document and acceptance remain the client's, coverage may be rejected for a given address, and the attested street mismatch is surfaced in `interpretazione`. It also explains the number-confirmation flow (SMS link or code). Rich behavioral context, though it doesn't describe the link's lifetime or rate limits.

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 purpose is front-loaded and each sentence carries substantive constraints (mandatory cliente, address behavior, no-order guarantee, confirmation flow). It is a dense, somewhat long paragraph but nearly every clause earns its place; no filler or restated 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 an 8-parameter, no-output-schema read tool with annotations already covering safety, the description covers the key behavioral and parameter aspects and even names the `interpretazione` field. It is largely sufficient for correct invocation, with only peripheral params (cap, provincia, agente) left unexplained.

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 coverage at 50%, the description compensates by explaining the cliente enum's business meaning, the role of comune/via/civico in coverage rechecking, and the interpretation output when the verified street differs. It adds meaning for the address trio and cliente beyond the schema, though cap, provincia, and agente remain unaddressed 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?

The opening states a specific verb and resource: "Restituisce il link alla pagina di sottoscrizione di un'offerta, con indirizzo e tecnologia già compilati." An agent can tell it produces a subscription link rather than merely checking coverage. It does not explicitly name or differentiate from siblings such as verifica_copertura or dettaglio_offerta, so it falls 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?

Usage is implied through preconditions (cliente is obbligatorio, business vs private rules, address needed for technology in the link) rather than stated as when-to-use vs alternatives. No explicit routing to verifica_copertura or other siblings is given, even though coverage is recheckable here. Adequate but with clear gaps.

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, non-destructive and closed-world, so the safety profile is covered. The description adds real behavioral value beyond that: it discloses the return shape (results with id/title/URL) and the two-step retrieval pattern ('il testo si legge con fetch'), plus the scoping boundary that it does not resolve addresses.

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 first clause, followed by the corpus list, the return shape, and the sibling exclusion. The middle enumeration is dense but each item maps to a real content domain, so it earns its place; only slightly long.

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 search tool with an output schema present, this is essentially complete: corpus scope, return shape, and the alternative tool are all covered. Minor omissions such as result limits or pagination behavior are not material given the output schema.

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% and the single query parameter is already documented with examples, so the baseline is 3. The enumeration of indexed content domains adds indirect help in formulating queries, but it does not add syntax or format detail beyond what the schema provides.

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 verb (Cerca) and enumerates the exact corpus it covers: prices, conditions, home/business price lists, coverage, activation, payments, assistance, company info, and the Open Fiber voucher. It also distinguishes itself from the sibling verifica_copertura in the same breath, so an agent can separate the two without opening a schema.

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 an explicit when-not and names the alternative: 'Non verifica un indirizzo: per sapere cosa arriva a un civico usa verifica_copertura.' That is a direct routing rule to the correct sibling, which is exactly what usage guidance should do.

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, openWorld and non-destructive, so the safety profile is covered. The description goes further and discloses non-obvious behaviour: fuzzy street matching reported via `interpretazione` (scritto/inteso), fallback `alternative` streets, suggestion output when comune/via are ambiguous, and conditional presence of `buonoOpenFiber`. It does not cover latency or rate limits, but for a read-only lookup this is substantial added context.

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 core capability is front-loaded in the opening sentence, and every subsequent sentence carries distinct information (listino uniformity, ambiguity handling, interpretazione/alternative semantics, buonoOpenFiber). It is a dense single paragraph with several parenthetical asides rather than a cleanly structured block, but no sentence is 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 carries the return-value burden and does so well, naming the technology, speed, offer, router, recognised address, interpretazione, alternative and buonoOpenFiber. The main gap is the negative case (what happens when no technology is available at the address), which is only implied by the suggestion behaviour.

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 the baseline is 3. The description singles out `cliente` and explains the privato/azienda distinction and why it matters for offer eligibility, but this largely restates the enum's schema description. For `via`, `civico` and `comune` it adds nothing 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 first sentence states a specific verb and resource: it returns which Interfibra technologies (FTTH, FTTC, FWA) can be activated at an Italian address, plus max speed, best offer and router. That is far more specific than a tautology. It stops short of explicitly differentiating from siblings like elenco_offerte or dettaglio_offerta, which also deal with offers, so an agent must infer the boundary.

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 context is clear (verify coverage for a given address, then advise the client), and the description even prescribes follow-up behaviour: tell the client which street was verified and use an alternative if it is not theirs. It does not state when to reach for a sibling tool instead, so there are no explicit exclusions.

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