Openapi®

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 usefully signals that this returns only the 'last' status rather than a history, implying a read-only lookup. It does not state whether it is read-only, what status values exist, or whether polling is expected, so meaningful gaps remain.

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?

Very short and front-loaded with the purpose before the Args block. The Args format lightly duplicates the schema, but nothing is wasted and the key parameter fact is included.

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 one-parameter status tool with no output schema, the description covers purpose and parameter provenance adequately. It does not describe the possible status values or return shape, which matters more here because there is no output schema to fall back on.

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, and it does: it documents the single parameter's name, that it is required, and where its value comes from (an async downgraded request). That provenance is genuinely beyond what the empty 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?

States a specific verb and resource ('Show the last status of an async request'), which is concrete enough to distinguish it from the many check_*/get_* siblings. However it never names or contrasts with the closest sibling, get_docuengine_request_status, so an agent gets no in-description disambiguation.

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 clause 'returned by an async downgraded request to the mcp server' implies the context in which this tool is called (after an async request has been deferred). But there is no explicit when-to-use, when-not-to-use, or alternative naming, leaving routing 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 a closed world, so the safety profile is covered. In the absence of an output schema, the enumerated result fields (spfDetails, dmarcDetails, mxRecords, timedOut, etc.) do add real disclosure about what comes back, but nothing is said about rate limits, timeouts, auth, or cost of a live check.

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 definition front-loads its purpose reasonably but then collapses ~36 field names into a single parenthesis, followed by a differently formatted 'Args:' block. This is a large, unstructured dump rather than concise, front-loaded guidance.

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

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

Given no output schema, enumerating return fields is a defensible completeness choice, and the read-only annotations cover safety. However, the description omits any usage context and does not explain the sync/async relationship with its start sibling, leaving a meaningful gap for a 1-param enrichment tool.

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

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

Schema description coverage is 0% and the single parameter has no schema-level documentation. The description's 'email: the email to check' merely restates the parameter name without adding format, validation, or normalization meaning.

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 and resource ('Retrieves advanced information about an email address'), so an agent knows it enriches an email. It does not distinguish itself from the sibling check_email_start, so the 'advanced' qualifier carries the differentiation implicitly rather than 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?

No when-to-use guidance, no prerequisites, and no mention of the check_email_start/check_async_status async pattern implied by the sibling set. The agent is left to infer whether this call is synchronous or has to be paired with a start/status flow.

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 and idempotentHint=true, so the safety profile is covered. The description adds nothing else: it says 'Retrieves', which actively suggests a synchronous read, while the name 'check_email_start' and the sibling 'check_async_status' imply an async job start that returns an identifier. That behavioral gap is significant.

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 in one sentence and the total length is small. The 'Args:' block duplicates the schema but follows a common convention, so it does not waste much space.

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 and only minimal annotations, the description should explain the async start/poll workflow and roughly what comes back. Instead it neither covers the polling requirement nor the response shape, leaving an agent likely to misuse the result.

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 full burden, yet 'email: the email to check' merely restates the parameter name. No format, validation, or constraint information (e.g., required syntax or normalization) is provided.

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 ('Retrieves detailed information') and resource ('an email address') and enumerates the data domains returned (SPF, DMARC, disposability, fraud). It never differentiates itself from the sibling 'check_email_advanced', leaving the start/advanced split to inference.

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 when-to-use guidance at all: no indication of when this should be chosen over 'check_email_advanced', no mention that the 'start' naming implies a job that must be polled via 'check_async_status', and no prerequisites.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true and openWorldHint=false, so the safety profile is covered. The description's only added value is the enumeration of returned fields (vpn, tor, fraudScore, recentAbuse, etc.), which is genuinely useful because no output schema exists, but it is a raw name dump with no explanation of what any field means or how to interpret it.

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 correctly front-loaded in the first clause, but the trailing parenthetical is a ~40-field run-on list that dominates the definition and is hard to scan. It is not padded with fluff, yet the structure is poor for a definition this short in intent.

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 lookup with no output schema, the description does attempt to disclose the return surface via the field list, and annotations cover the read-only/idempotent behavior. However, the parameter's accepted format is never clarified and the field names carry no meaning, leaving meaningful gaps for an agent that must interpret 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% and the sole parameter is described only as 'valid ip number'. This adds no format detail (IPv4 vs IPv6, CIDR, hostname allowed?) and the word 'number' conflicts with the schema's declared string type, so it is mildly misleading rather than helpful.

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: 'Retrieves advanced information about an ip address', which is enough to distinguish it from the email/mobile/url siblings in the check_*_advanced family. The 'advanced' qualifier is unexplained (no check_ip_start sibling exists to contrast with), but the resource is unambiguous.

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, no prerequisites, and no mention of alternatives or when-not-to-use it. An agent must infer applicability purely from the resource 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?

Annotations already declare readOnlyHint=true, idempotentHint=true and openWorldHint=false. The description adds the useful detail that the lookup is against an 'official database', but says nothing about the return shape (boolean vs. matched data) or lookup behavior. With annotations carrying the safety profile, a 3 is fair.

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 definition is short and front-loaded, with the core purpose stated first. The Args block is somewhat redundant for a single self-describing parameter, but overall there is little waste.

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 single-parameter validation tool with no output schema, the description covers the essential purpose. However, it never indicates what the tool returns (a validity flag, an error, or matched registry data), which an agent needs to interpret the result.

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 full burden, yet 'fiscal code of an italian person' only restates the parameter name and adds a thin hint (person, not company). It omits the expected format (16-character alphanumeric pattern) or any validation expectations.

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 ('Check') and resource ('Italian Fiscal Code') against an authoritative source ('official database'). It clearly distinguishes this validator from sibling checkers (email, license plate, pec, mobile) by its resource, though it never explicitly names alternatives.

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 nature of a validation tool, but there is no explicit when-to-use, no conditions, and no mention of alternatives among the many sibling 'check_*' tools. An agent can infer the intent but gets no routing guidance.

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, yet it says nothing about whether this is a read-only lookup (implied but unstated), whether it costs money/is metered, auth requirements, or what the response contains. The combination matrix is a parameter constraint, not behavioral disclosure.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the purpose, but the body is run-together with inconsistent spacing ('IT-insurance,FR-car'), a typo ('informations'), and list formatting that is hard to parse. Compact, but structure could be cleaner.

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?

Handles the input side (three required params, valid values, valid combinations) adequately, but with no output schema and no annotations it leaves the return shape and behavioral profile undocumented. For a lookup tool an agent cannot know what it gets back.

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 and largely does: it names all three required params, enumerates valid countryCode and type values, and adds the cross-field 'Available Combinations' constraint. It loses a point for listing 'DE' as a valid countryCode while no DE combination is offered, an inconsistency that could mislead.

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 ('Retrieve informations about ... licensePlate') and scopes it by country and type, which distinguishes it from the other check_* and get_* lookups.

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 or when-not guidance, but the 'Available Combinations' list constrains the acceptable country/type pairings, which is implied usage information an agent can act on. No alternatives to this tool are named.

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

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint=false, covering the safety and determinism profile. Absent an output schema, the field enumeration adds useful signal about what comes back, but the description never says whether the call is synchronous or returns a pending job id (relevant given the sibling check_async_status).

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 sentence is front-loaded and efficient, but the raw 30-field dump in parentheses is unstructured padding that reads like a schema listing rather than guidance. It is not egregiously long, but the parenthetical does not earn its full space in its current form.

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 one required parameter, no output schema, and annotations covering safety, the field list partially substitutes for the missing output schema. What remains missing is the async/sync calling pattern and the relationship to the check_mobile_start / check_async_status siblings, which are central to using this tool 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 coverage is 0%, so the description must compensate, and it does supply the required input format (international prefix, example +39) for the single 'mobile' parameter. It stops short of giving the full expected pattern such as an E.164 example, but the essential format constraint is conveyed.

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 ('Retrieves advanced information about a mobile number') and enumerates the returned fields, making the subject matter unambiguous. It does not, however, differentiate itself from sibling check_mobile_start or explain the 'advanced' vs 'start' distinction, leaving sibling selection to inference.

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 only guidance is an input-format note ('with international prefix es +39'), which is about how to call it, not when. Nothing tells the agent when to choose this over check_mobile_start or whether a result must be fetched via check_async_status.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true and openWorldHint=false, so the safety profile is covered. The description adds the returned field set (useful with no output schema) but says nothing about auth requirements, rate limits, or failure behavior; given annotation coverage, a 3 is appropriate.

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 a single sentence, but the bulk of the text is a flat 14-item field dump that reads like a return-value enumeration rather than guidance. It is not bloated to the point of harm, but much of the listing does little to help an agent invoke the 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?

With no output schema, listing the response fields is genuinely valuable, and the description supplies it. However, for a validation tool sitting next to check_mobile_advanced, the missing usage guidance and the thin input-format note leave real gaps for an agent choosing and calling it.

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% - the single 'mobile' property is a bare string with no description - so the description's 'with international prefix es +39' is the only format hint available. It helps, but is ambiguous (unclear whether a plus sign, spaces, or the odd 'es' prefix is expected) and leaves the accepted input format underspecified.

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 ('Retrieves basic information about a mobile number') and enumerates the returned fields, so the agent knows exactly what this produces. It implicitly contrasts with check_mobile_advanced via the word 'basic' but never names that sibling, so differentiation requires inference.

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 when-to-use or when-not-to-use guidance, and no mention of check_mobile_advanced despite it being the obvious alternative in the sibling list. The only hint is the adjective 'basic', which is not enough to route an agent reliably between the two mobile tools.

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, openWorldHint=false, and idempotentHint=false, so the safety profile is covered. The description adds only the 'available for purchase' intent, with no disclosure of return behavior, auth needs, or rate limits, so it adds modest value beyond the 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?

Front-loaded purpose sentence, brief usage clause, and a compact Args line. Slightly redundant (title and first sentence repeat the same idea) and contains a typo ('avaible'), but it is tight and easy to scan.

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 one-parameter read-only tool this is close to adequate, but with no output schema the description never explains what the check returns (boolean, status, reason), leaving the agent without a clear picture of the result shape.

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 is the sole documentation for the single parameter. 'pec: the pec address to check' labels the parameter but is essentially a restatement of the field name, adding little semantic detail about format or validity.

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 (checks) and resource (PEC / Certified Email address availability for purchase). The purpose is unambiguous, though it does not explicitly differentiate itself from the check_email_* siblings, which is the main clarity gap.

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?

Explicitly gives a when-to-use condition ('when the user asks if a PEC address is available'). It omits any when-not or alternative-tool routing, but for a narrow single-purpose tool the trigger context is sufficient.

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 the safety profile is covered structurally. The description adds the set of diagnostics computed (riskScore, phishing, malware, dnsValid, etc.), which is genuinely informative absent an output schema, but says nothing about latency, rate limits, auth, or whether this is a live scan versus cached data.

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 bulk of the description is a single run-on parenthetical dumping 30+ field names with no grouping or priority. The field list is informative in the absence of an output schema, but it is not front-loaded, not structured, and buries the actual purpose in noise.

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 one-parameter, no-output-schema tool, the field enumeration compensates for the missing return contract and the annotations cover the read-only nature. However, routing guidance versus the many sibling check_*_advanced tools and any operational caveats are absent.

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?

Only one parameter, with 0% schema description coverage, so the description must carry the load — and it only offers 'url: valid url address'. That confirms the input must be a validated URL but adds no format, scheme, or example detail beyond the schema's type.

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 gives a specific verb and resource ('Retrieves advanced information about an url address') and enumerates the fields returned, so an agent knows this is a deep URL-reputation/analysis lookup. It does not, however, distinguish itself from the sibling check_*_advanced family or explain what 'advanced' buys over a basic check.

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, when not to, or which sibling to prefer (e.g. check_email_advanced / check_ip_advanced). The only guidance is the implicit 'advanced' naming convention, leaving the agent to infer purpose from the field list.

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. It usefully discloses pricing (€5.50, split €0.60 search / €4.90 document) and the two-step search-then-finalize behavior, which are genuine additions beyond structured data. But it says nothing about what the search results contain, pagination, permissions, or error behavior, leaving significant behavioral gaps.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The definition is short, bulleted, and front-loaded: workflow routing comes first, followed by price and required-parameter notes. Every line is compact, though the raw ID and price breakdown are somewhat peripheral to invocation.

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 6-parameter tool with no annotations and no output schema, the description covers only the workflow and cost. Five optional filtering parameters are unexplained and the contents of the 'search results' are never described, leaving the agent unable to invoke it well beyond the single required field.

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% across 6 parameters, so the description must compensate. It only mentions 'Required: taxCode' (which merely restates the schema's required field) and says nothing about the five optional date/actGroupCode filters, which are the ones an agent actually needs to understand. Most parameters remain undocumented.

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 identifies the specific service ('Atto Ottico', ID 6687eea71a241a5d1be0f9f9) and states its role in the workflow ('This returns search results'). It also distinguishes itself from the sibling patch_docuengine_atto_ottico. However, the resource itself ('Atto Ottico') is undefined jargon, so an agent cannot tell what document type it is actually retrieving without outside 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?

It explicitly describes a two-step process and routes the agent to the correct alternative: 'Use patch_docuengine_atto_ottico to select and finalize.' That is clear when-to-use guidance. It stops short of stating exclusions or when not to use it, so it falls just below the top band.

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 meaningful behavior: the two-step search-then-finalize flow, the nature of the return (search results), and the cost model (€4.50 total, €0.10 search / €4.40 document). It does not mention auth requirements or rate limits, but the pricing and workflow disclosure is above average.

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 definition is compact and front-loaded: service identity first, then price, required input, and workflow, each on its own labeled line. Every line conveys distinct information with no filler.

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

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

For a single-param, no-annotation, no-output-schema tool, the description covers the workflow and cost but leaves the output content and auth requirements unstated, and does not disambiguate the sibling bilancio variants. Adequate but with visible gaps.

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?

There is one parameter at 0% schema description coverage, so the description must supply its meaning. It only restates '📋 Required: taxCode' without explaining that this is an Italian fiscal code/VAT identifier or its expected format, adding essentially no semantics beyond the schema's required list.

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 specific DocuEngine service (Bilancio Ottico) with its ID and domain tag '[Camerali]', and clarifies that it is a search step rather than the finalizing step. It distinguishes itself from its patch_ sibling, though it never explains what a 'Bilancio Ottico' is relative to the bilancio_riclassificato and bilancio_xbrl 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 two-step workflow is stated explicitly: this tool returns search results and 'patch_docuengine_bilancio_ottico' selects and finalizes. That gives a clear when-to-use and which-alternative signal. It stops short of explaining when to choose this bilancio variant over the riclassificato/xbrl variants.

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 behavioral burden and does disclose meaningful traits that structured fields do not: the cost breakdown (€5.00 total, €0.10 search + €4.90 document) and, critically, that this call only returns search results rather than the finalized document. It omits error/failure behavior and result shape, so it is strong but not complete.

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 definition is front-loaded with the service identity, then price, required input, and workflow in scannable labeled lines, with no wasted sentences. The repeated title and raw service ID are mildly redundant but not harmful.

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 one-parameter, no-output-schema tool the description covers what it does, the cost, the required input, and the two-step handoff. However, with no output schema it never indicates what the returned search results contain, leaving the agent to guess about the result shape.

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 has 0% description coverage for the single parameter, so the description must compensate. It only repeats '📋 Required: taxCode', which merely restates the schema's required flag, and never explains that taxCode is the Italian fiscal code/VAT or its expected format.

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 specific service ('DocuEngine service: Bilancio Riclassificato'), gives its service ID, and states the operative action ('This returns search results'), so an agent knows it retrieves search matches for a reclassified balance-sheet document. It does not, however, distinguish this resource from its close siblings (bilancio_ottico, bilancio_xbrl) beyond the name, keeping it 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?

The two-step instruction is explicit: this call returns search results and the agent must then use 'patch_docuengine_bilancio_riclassificato' to select and finalize, naming the alternative tool and the condition for switching to it. There is no statement of when not to use it (e.g., when another service is more appropriate), so it falls short of 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 still carries useful operational context: it discloses the cost (€4.50, split into €0.10 search + €4.40 document) and that this call yields search results rather than the finalized document. It does not cover auth requirements or what the search result payload looks like.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded identification, then cost, required param, and workflow in a compact emoji-delimited block. Dense and scannable, though the emoji markers are somewhat noisy.

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 priced two-step tool with no annotations and no output schema, it adequately covers cost and workflow but omits what the search results contain and how their identifiers feed the patch call. The taxCode format gap also remains.

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?

Only one parameter exists with 0% schema description coverage, so the description must compensate and it does not — 'Required: taxCode' merely restates what the schema already marks required. No format guidance (e.g. Italian fiscal code length/structure) or example is given.

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 precisely ('Bilancio XBRL', service ID, 'Camerali' category), but no real verb — the search behavior is only revealed incidentally at the end ('This returns search results'). It does not differentiate the XBRL variant from the many sibling bilancio tools (ottico, riclassificato).

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 states the two-step workflow and names the exact follow-up tool (patch_docuengine_bilancio_xbrl), which is genuine routing guidance. However it gives no criteria for choosing XBRL over bilancio_ottico or bilancio_riclassificato, which is the harder selection problem in this sibling set.

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 exist, so the description carries the full behavioral burden. It usefully discloses a cost (€2.10) and that it is a 'direct' service call, but says nothing about output shape, latency, authorization, or failure behavior for what is likely a paid external lookup.

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?

Very short and front-loaded: service name, ID, category, price, and required parameter are packed into a few lines with no filler. Structure is functional, though the ID string is of questionable value to an agent.

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 one-parameter, single-output paid service with no output schema and no annotations, the description omits what the document contains and when to request it, leaving an agent unable to judge relevance beyond the Italian label. It is under-specified for the decision it must support.

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, and it only repeats 'Required: taxCode' without explaining the expected format (Italian codice fiscale) or any constraints. It adds essentially nothing beyond what the JSON schema already shows.

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?

It states the tool fetches a DocuEngine service called 'Cariche Attive Persona' with an opaque service ID, but 'Cariche Attive Persona' is an untranslated Italian service name that does not tell an agent what data comes back (company officer/role records for an individual). It is distinguishable from siblings only by the raw name, not by an explained verb+resource.

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 when-to-use guidance, no conditions for selecting this over the many similar sibling services (e.g. docuengine_quote_attive_persona, docuengine_esponenti_attivi_azienda), and no exclusions. The only routing help is the price and required input, not usage context.

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 usefully discloses the price (€13.70) and the required taxCode, but omits whether this is a paid order with side effects, whether delivery is synchronous or asynchronous (many siblings like check_async_status and get_docuengine_request_status suggest async workflows), and what the result looks like.

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 short and front-loaded, leading with the service identity and keeping the price and required-parameter notices scannable. It is efficient, though the emoji-delimited lines carry mostly metadata rather than explanatory content.

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 paid document service with four parameters, no parameter documentation, no annotations, and no output schema, the description is too thin. It should at least clarify the operation type, whether results arrive synchronously or via a status-check flow, and what the shippingAddress/shipmentRecipient fields imply about physical delivery.

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% across 4 parameters, and the description only restates that taxCode is required — information already present in the schema's required list. The optional phone, shippingAddress, and shipmentRecipient parameters (which suggest physical delivery) are entirely unexplained in both schema and description.

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 (Certificato Artigiano, [Camerali]) and identifies it as a DocuEngine service, which helps distinguish it from the many sibling document tools. However, it never states the actual action — whether it orders, retrieves, downloads, or generates the certificate — so the verb is effectively 'direct tool for service X', which is closer to an identifier than a clear purpose.

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 alternatives such as docuengine_certificato_di_iscrizione, docuengine_certificato_storico, or the generic document-download siblings. The only context is the service name itself, so the agent must infer applicability from the resource label alone.

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

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

With no annotations, the description carries the full burden. It usefully discloses the price (€13.70), which is real behavioral context not present in the schema, but omits whether this is a paid purchase, whether delivery is asynchronous and requires check_async_status, and how the document is returned. For a paid document-retrieval service that is a significant 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?

The text is short and front-loaded with the price and required parameter, which is good. But it repeats the service name twice and the internal ID plus 'Direct tool for DocuEngine service' are filler that consume space without informing tool selection.

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?

No output schema and no annotations mean the description must be self-sufficient, yet it provides no return-value or lifecycle information and leaves 3 of 4 parameters undocumented. For a paid, likely shipped document service this is inadequate.

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 only identifies taxCode as required, matching the schema without adding meaning. The three optional parameters (phone, shippingAddress, shipmentRecipient) are left entirely unexplained in both places, even though they imply the certificate is physically shipped — an important behavior the agent cannot infer.

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 essentially restates the tool name ('Certificato Di Iscrizione') and wraps it in boilerplate ('Direct tool for DocuEngine service'). It does not explain what a certificate of registration contains or why an agent would request it. It also fails to distinguish it from close siblings like docuengine_certificato_artigiano, docuengine_certificato_storico, or the various visura_camerale_* 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?

Aside from naming the one required parameter (taxCode), there is no guidance on when to select this tool over the dozens of sibling DocuEngine products. No prerequisites, no exclusions, no routing hints are given.

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 disclose a meaningful trait, the €16.70 price, which helps an agent understand this is a paid operation. Beyond that it says nothing about permissions, whether the operation is read-only or stateful, expected latency, or what the result contains.

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 text is short and front-loads the resource name and required input. However, it wastes space on an internal service ID ('689cb8972d09c0a9bcb946f5') that is meaningless to an agent, and the pricing/required lines are formatted as raw metadata rather than prose guidance.

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

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

For a paid document-generation tool with four parameters, no annotations, no output schema, and 0% parameter documentation, the description is far too thin. An agent cannot determine ordering requirements, delivery behavior, or what is returned, leaving critical gaps 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?

Schema description coverage is 0%, so the description must compensate but largely does not. It notes taxCode is required, yet that fact is already encoded in the schema's required array, adding no new meaning. The other three parameters (phone, shippingAddress, shipmentRecipient) are entirely undocumented in both schema and description, leaving their role 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 names the resource ('Certificato Storico') and its category ('[Camerali]'), which conveys a specific document type. However, it reads largely as a restatement of the tool name and gives no functional explanation of what a historical certificate contains or how it differs from siblings like docuengine_certificato_di_iscrizione or docuengine_certificato_artigiano. An agent must still infer the actual purpose 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?

There is no indication of when to choose this tool over the many sibling certificato/visura tools, nor any prerequisites or exclusions. The only routing hint is the '[Camerali]' tag and the price, which do not tell an agent when this specific certificate is the right choice.

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 behavioral burden, yet it only discloses the price (€17.30). It does not say whether this is a read or a chargeable write/order, whether it is synchronous or async (the sibling set includes get_docuengine_request_status and check_async_status, implying async), what auth is needed, or what happens on the account when invoked.

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 text is short and front-loads the service identity, which is good. But the internal ID '(ID: 69c5456840be088d9c41df88)' is noise and the required-parameter list is redundant with the schema, so some of the length is not productive.

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 9 required parameters, zero schema descriptions, no annotations, and no output schema, the description is far too thin. It omits parameter meaning, return shape, async/request-tracking behavior, and the charging implications of a priced service.

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% and there are 9 required parameters, so the description must compensate. Instead it merely restates the 9 parameter names already listed in the schema's required array, adding no meaning, format, or file-vs-string semantics for fields like 'document' and 'delegationFile'.

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 ('DURC Online') and frames it as a DocuEngine service call, so an agent can identify it as the DURC document request. However, the verb is vague ('Direct tool for service'), it never defines what DURC is, and it does nothing to distinguish this from the dozens of sibling docuengine_* services beyond the product name.

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 the many other docuengine_* siblings, no prerequisites, and no exclusions. The only context is a pricing line and a required-field list, which is not usage guidance.

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 does disclose genuine behavioral facts the schema cannot convey: the service costs €2.30 and belongs to the '[Camerali]' category. However, it says nothing about what is returned, latency, or whether the call is read-only or billed per invocation.

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?

Very short and front-loaded, but the internal service ID and emoji-formatted price/required lines are more metadata dump than useful prose. It is concise without being informative, so size alone doesn't earn a high score.

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 annotations, no output schema, and an undocumented parameter, the description should carry the load. It omits what the service returns and how the result is delivered, leaving the agent unable to predict the outcome of the call.

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 the single taxCode parameter. The description only repeats that taxCode is required, adding no meaning such as format (Italian fiscal code / VAT number), validation rules, or whether it identifies the company or a person. It fails to compensate for the schema 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?

The description is essentially a wrapper label: 'Direct tool for DocuEngine service: Esponenti Attivi Azienda' restates the tool name without explaining in plain language what the service returns (active company officers/directors of a company). With many near-identical siblings (docuengine_soci_attivi_azienda, docuengine_cariche_attive_persona, docuengine_quote_attive_persona), an agent that doesn't read Italian cannot distinguish 'esponenti' from 'soci' or 'cariche'.

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 guidance, no prerequisites, no mention of alternatives. The only usage-relevant statement is the required parameter, which the schema already enforces. Nothing tells the agent when this service is the right choice over its many siblings.

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 usefully flags that the call is paid (€3.90) and labels itself a 'direct tool', but says nothing about whether the operation is synchronous or returns a request needing polling via get_docuengine_request_status, nor about output format or permissions.

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?

Short and front-loaded, but the sentences are fragmented service-template boilerplate (service prefix, raw ID, price, param list) rather than a coherent lead sentence describing the operation, so structure is only marginally effective.

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 annotations, no output schema, and 0% parameter coverage, the description is the sole carrier of context and falls well short: it omits the report's contents, output shape, cost handling beyond the price tag, and async behavior expected in this DocuEngine family.

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 and does not. It only echoes the required keys ('reaCode, cciaa') without explaining that reaCode is the REA registry number or that cciaa identifies the Chamber of Commerce, leaving both parameters semantically opaque.

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 resource ('Eventi Negativi Azienda') and distinguishes it from the sibling docuengine_eventi_negativi_persona by target entity (Azienda vs persona), which an agent can use. However, it never says what it actually produces (a report of negative/insolvency events for a company); for a non-Italian reader the purpose is implicit and effectively restates the tool name plus an internal ID.

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 when-to-use guidance, no prerequisites, and no routing to alternatives. The only operational hints are price and required parameters; nothing tells the agent when this report should be chosen over the many other visura/fascicolo siblings.

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 disclose a material trait – the operation is billable at €3.90 – which is genuinely useful. But it says nothing about permissions, auth, what the report contains, or how results are returned/delivered.

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 short and front-loads the service line, but the internal service ID (680a53e1...) is noise for an agent, and the price/required lines duplicate structured data. Compact yet not maximally information-dense.

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

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

With no annotations, no output schema, and a dense sibling family, the description should explain the report's content and return mechanism. It provides only a name, an opaque ID, a price, and a parameter restatement – insufficient for an agent to invoke this confidently.

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 for three undocumented parameters. It merely restates the required parameter names (name, surname, taxCode), which duplicates the schema's 'required' list without adding meaning – e.g., taxCode expected format, whether name must match taxCode, or case sensitivity.

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 type ('Eventi Negativi Persona') and implicitly distinguishes itself from the azienda sibling via the 'Persona' qualifier. However, it never states a verb describing what the tool actually does (retrieve/download a negative-events report), and the Italian name may not convey meaning to an agent. Purpose is inferable but not explicit.

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 alternatives. Given 60+ siblings including docuengine_eventi_negativi_azienda and various protesti/pregiudizievoli tools, the absence of any routing or when-not-to-use context is a real gap.

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 behavioral burden, and it does disclose two non-obvious traits: the €15.70 cost (important for a paid call) and that it is a 'direct' (presumably synchronous) tool. It still says nothing about what is returned, latency, failure modes, or whether a document link is produced, so the disclosure is partial.

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 text is short and the key facts (product name, price, required parameter) are front-loaded. However, the internal service UUID (69c40e2f327b41417c839015) and duplicated product name in brackets are noise that add no decision value.

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 paid document-retrieval call with no annotations, no output schema, and 0% parameter documentation, the description is under-specified. It does not explain what the fascicolo contains, how the result is delivered, or what province/companyName are for, leaving real gaps for an agent to call 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% across three parameters. The description flags taxCode as required, which the schema already encodes, but the optional province and companyName parameters are left entirely unexplained in both schema and description. It does not compensate for the coverage 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?

The description names a specific document product ('Fascicolo Societa' Di Capitali', category 'Camerali'), so an agent knows what artifact is being ordered. However, the framing 'Direct tool for DocuEngine service' is boilerplate and does not distinguish it from close siblings like docuengine_fascicolo_storico_societa_di_capitali or docuengine_visura_camerale_ordinaria_societa_di_capitale.

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 when-to-use guidance, no statement of prerequisites, and no mention of the alternative fascicolo/visura tools an agent should consider instead. The only directive is 'Required: taxCode', which is a parameter note rather than usage context.

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 the cost (€11.70) and the required input, but says nothing about what is returned, whether the document is generated synchronously or asynchronously, or any auth/rate constraints.

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 short and front-loaded with the service identity, price, and required field. The embedded internal ID is arguably noise, but overall there is little waste.

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, no annotations, and undocumented optional parameters, the description leaves key questions unanswered for a paid document-retrieval service: what the fascicolo contains and how the optional params affect the result.

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 only flags taxCode as required. The 'province' and 'companyName' parameters are completely unexplained in both schema and description, so the agent cannot tell whether they are disambiguators, filters, or optional fallbacks.

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 specific service ('Fascicolo Societa' Di Persone') and labels it as a DocuEngine camerali document, so an agent can infer it retrieves a company file for partnerships. However, it never states the verb or what the fascicolo contains, and it gives no differentiation from close siblings such as docuengine_fascicolo_storico_societa_di_persone or docuengine_fascicolo_societa_di_capitali.

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 when-to-use guidance, no mention of alternatives, and no prerequisites beyond the '📋 Required: taxCode' line. With dozens of docuengine_* siblings, the absence of routing information is a real gap.

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 does disclose genuinely useful behavior: the €16.50 price and the required input. However, it omits whether the call is synchronous or needs polling, auth requirements, and what the returned document looks like, which are material for a paid document-generation 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?

The text is short and the cost and required-parameter facts are front-loaded, which is efficient. The internal service ID is noise for an agent but costs little.

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 annotations, no output schema, and zero parameter coverage, the definition leaves critical gaps: what the 'fascicolo storico' contains, how results are delivered, and the meaning of two of three inputs. For a paid document tool with this much surrounding sibling ambiguity, it is inadequate.

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% and there are three parameters, but the description only flags taxCode as required. The purpose and expected format of the optional province and companyName parameters are never explained, so the description fails to compensate for the documentation 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?

The description largely restates the tool name ('Fascicolo Storico Societa' Di Capitali') and labels it a 'Direct tool for DocuEngine service,' which is a tautology rather than an explanation of what the document actually is. It gives no basis for distinguishing this from close siblings such as docuengine_fascicolo_societa_di_capitali or docuengine_visura_camerale_storica_societa_di_capitale.

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 select this tool over the many other DocuEngine fascicolo/visura variants, nor any exclusions or prerequisites beyond the implied 'taxCode required.' An agent is left to infer the routing decision purely from the 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 it discloses only the price (€11.70) and the required parameter. It says nothing about whether this is synchronous or returns a request ID to poll (siblings like get_docuengine_request_status suggest an async pattern), what the returned document looks like, or any auth/permission requirements.

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 short and does not waste words, but the information it front-loads (ID, price, category) is metadata rather than task-relevant guidance. Compactness here reflects under-specification rather than disciplined concision.

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 paid, multi-parameter, no-annotation, no-output-schema service in a dense sibling set, the description is far too thin: it omits the async/return behavior, the meaning of two optional parameters, and any routing logic. Only the cost and required field are covered.

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% across 3 parameters. The description names only taxCode (redundant with the schema's required list) and gives no meaning, format, or role for province or companyName, so it fails to compensate for the coverage 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?

The description essentially restates the tool name ('Fascicolo Storico Societa' Di Persone') plus an internal ID and a category tag '[Camerali]'. 'Direct tool for DocuEngine service' adds no semantic content, and no English gloss is given for what a 'Fascicolo Storico' actually retrieves. It does not distinguish itself from close siblings such as docuengine_fascicolo_societa_di_persone or docuengine_visura_camerale_storica_societa_di_persone.

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 when-to-use guidance, no prerequisites, and no mention of any alternative. The phrase 'Direct tool' hints at a contrast with some indirect/async path but never explains it, leaving the agent to infer selection among ~75 siblings unaided.

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 behavioral burden, yet it only discloses a price (€2.10) and a category tag. It does not say whether this is a read-only lookup, what authentication it needs, whether the cost is billed per call, or what the response contains.

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 short and front-loads the service and resource name, which is good. However, the emoji-decorated price and required lines are formatted as marketing metadata rather than informative prose, adding noise without adding understanding.

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 paid, parameterized DocuEngine lookup with no annotations and no output schema, the description is far too thin: it omits what the document contains, its legal/regional scope, and any return expectations. It does not do enough to help an agent choose it over the dozens of sibling document 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% for the single taxCode parameter, so the schema provides only a bare string type. The description's "Required: taxCode" merely repeats the required array already present in the schema and adds no format guidance (e.g., Italian fiscal code structure), leaving the parameter undocumented.

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 largely restates the tool name ("Quote Attive Persona") and labels it a "Direct tool for DocuEngine service," which adds no meaning about what the operation actually does. It never states a verb or explains the resource beyond the Italian phrase in the name, so an agent cannot tell from the text whether this returns a person's shareholdings or something else.

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 when-to-use guidance, no exclusions, and no reference to alternatives. The sibling docuengine_cariche_attive_persona and the many visura/quote-family tools are indistinguishable from this one based on the description, so the agent has no routing signal.

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 does disclose a cost (€2.30) and the required field, which is genuinely useful behavioral context for a paid document service. It does not state whether the call is synchronous or asynchronous, how the document is returned (inline vs. downloadable via get_docuengine_documents), or whether results are cached.

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 short and front-loaded, which is good, but the identifier hash is noise for the agent and the required-field note restates the schema. The price line is the only distinct piece of information carried.

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 paid document-generation tool with no annotations, no output schema, and 0% parameter coverage, the description omits critical context: what the returned document contains, whether it is synchronous, and how to retrieve the result. It is not sufficient for an agent to invoke this correctly without additional assumptions.

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 parameter. The description repeats the schema's required field name ('taxCode') but adds no semantics: whose tax code (company vs. person), expected format (11-digit partita IVA vs. 16-char codice fiscale), or whether an error is returned for an invalid value. With only one parameter the burden is small, but the repetition adds nothing.

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 identifies the operation via its Italian name 'Soci Attivi Azienda' (active shareholders of a company) and gives a service ID, but neither the description nor the title translates or explains what the document actually reports. An agent unfamiliar with Italian chamber-of-commerce terminology cannot distinguish this from docuengine_esponenti_attivi_azienda or docuengine_quote_attive_persona without external 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?

'Direct tool for DocuEngine service' implies this is the call to use for this specific document, and the required taxCode signals a lookup keyed to a company. There is no explicit when-to-use vs when-not-to-use statement, no mention of the sibling esponenti_attivi (which sounds like the same thing), and no note about async status checking despite check_async_status/get_docuengine_request_status siblings.

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 and mostly fails: it does not say whether this is a synchronous or asynchronous request, what the response contains, or what the taxCode is used for. The one genuine behavioral fact it adds is the price (€4.90), which is real but narrow.

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 text is short and front-loads the tool identity, but the internal service ID (6687eed51a241a5d1be0f9fa) and the 'Direct tool for DocuEngine service' prefix are noise that consume space without informing an agent. The emoji-labeled price and required fields are at least scannable.

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 service call sitting among dozens of near-identically named document tools, the description does not explain what 'Statuto' is, when it applies, or what the caller receives. With no annotations and no output schema, more disclosure was required than is present.

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 should compensate for the undocumented taxCode parameter. Instead it merely restates 'Required: taxCode', which is already encoded in the schema's required array, adding no format, validation, or semantic detail (e.g., person vs. company tax code).

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 ('Statuto', a Camerali company document) and thus differentiates by document type from the ~70 sibling docuengine_* tools. However, it never supplies a verb — it is unclear whether the tool retrieves, generates, or requests the document — and 'Direct tool for DocuEngine service' is boilerplate rather than a statement of purpose.

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 when-to-use guidance, no prerequisites, and no comparison against alternatives such as get_docuengine_services or the many other docuengine_* document tools. Only the required parameter is noted, which is not usage guidance.

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 discloses two meaningful behavioral facts: the price (€6.50) and the word 'Direct', which implies a synchronous call. It does not describe output format, side effects, or error behavior, leaving clear gaps.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is short and front-loads the service name, price, and required parameter. The service ID and emoji formatting add slight noise but do not obscure the core 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?

For a simple one-parameter service call, the description provides the essential invocation details (service identity, price, required input). However, with no output schema it does not explain what the tool returns, and it omits any distinction from sibling document 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 only repeats that ‘taxCode’ is required without explaining what the value is (e.g., Italian fiscal code vs VAT number), its format, or where to obtain it, adding no semantic meaning 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?

States the specific DocuEngine service ‘Visura Camerale Inglese’ and category [Camerali], which distinguishes it from sibling services such as the ordinaria and storica variants. However, it relies on the service name rather than an explicit verb like 'retrieve' to convey the action.

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?

Offers no guidance on when to use this tool versus alternatives like the ordinary or historical visura services, or the generic document retrieval tools. The phrase 'Direct tool' is not elaborated into a use condition.

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

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

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses the cost (€2.90) and the two required identifiers, but says nothing about whether the request is synchronous or async, whether it consumes credits, what permissions are needed, or how the document is delivered.

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 short, front-loaded and structured with clear price and required-parameter lines. The boilerplate 'Direct tool for DocuEngine service' phrasing and duplicated service name are mild waste but not enough to hurt readability.

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 paid document-order service with two undocumented identifier parameters, no annotations and no output schema, the description omits what the visura contains, its format/language, and how the result is returned or polled. It should do substantially more for an agent to invoke it safely.

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 both parameters are undocumented in the schema and the description only repeats their names as 'Required: reaCode, cciaa'. It never explains what a cciaa (Chamber of Commerce code) or REA code is, their formats, or how to obtain them, adding no semantic value over the schema's required array.

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 (Visura Camerale Ordinaria - Impresa Individuale) and labels itself a 'Direct tool for DocuEngine service', but it is largely a restatement of the tool name plus an ID and price. With siblings like docuengine_visura_camerale_ordinaria_societa_di_capitale and _societa_di_persone present, it never explains what distinguishes the 'impresa individuale' variant or what the document actually contains.

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

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

No when-to-use or when-not-to-use guidance is given, and no alternative among the many sibling visura/fascicolo tools is named. The only routing signal is the entity type embedded in the tool name itself, which the description merely repeats.

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 full behavioral burden. It usefully discloses that this is a paid operation (€4.90) and lists the required parameters, which is some credit. But it says nothing about processing time, async/polling behavior, authentication, or what the returned document contains – all significant for a paid document-retrieval 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?

The text is short and front-loaded, but the leading 'Direct tool for DocuEngine service:' prefix and the internal service ID are boilerplate that consume space without informing the agent. Otherwise it is reasonably 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?

There is no output schema and no annotations, so the description must convey behavioral and return context, yet it omits any description of the document produced, delivery mechanism, or timing. For a paid, likely-asynchronous document service with undocumented parameters, this is inadequate.

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 for both parameters. It only lists 'reaCode, cciaa' as required without explaining what a REA code is or what the CCIA (chamber of commerce) value should look like, leaving format and origin undefined.

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 document type – an ordinary chamber-of-commerce report for a capital company – so the resource is identifiable. However, it is largely a restatement of the tool name, and it does nothing to distinguish this from the many sibling visura variants (ordinaria vs storica, societa di capitale vs di persone vs impresa individuale, inglese).

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 the numerous alternatives such as visura_camerale_storica_societa_di_capitale or visura_camerale_ordinaria_societa_di_persone. The only context is 'Direct tool for DocuEngine service', which does not help selection.

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. It usefully discloses the per-call price (€3.40), which is genuine behavioral context not available elsewhere. It does not say whether the call is synchronous or returns an async handle, what the document contains, or whether it consumes credits, so the transparency is partial.

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 text is short and front-loaded with the service identity, price, and required inputs. It is marred by raw metadata (a Mongo ObjectId) and emoji formatting that add no selection value, but the core is not padded or verbose.

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 paid, parameterized document-retrieval tool with no annotations, no output schema, and 0% parameter coverage, the description omits what is returned, async/sync behavior, and disambiguation from the five-plus similarly named visura siblings. Price and required inputs alone are not 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?

Schema description coverage is 0%, so the description must compensate for two undocumented parameters. Instead it merely lists 'Required: reaCode, cciaa', duplicating the schema's required array, and never explains that cciaa is the Chamber of Commerce code or reaCode the REA registration number, nor gives format examples.

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 (Visura Camerale Ordinaria for società di persone) and labels it a DocuEngine service, which lets an agent distinguish it from the capitale/impresa-individuale variants. However, it never states the action — whether this fetches, orders, or generates the document — so the purpose is essentially a restatement of the tool name plus an ID.

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 guidance is given, and the crowded sibling set (visura_camerale_ordinaria_societa_di_capitale, _impresa_individuale, _storica_societa_di_persone, fascicolo_*) makes routing ambiguous. The agent must infer selection purely from the name; nothing in the text says why or when to pick this over a historical or fascicolo 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 full behavioral burden. It usefully discloses that the service costs €3.90, which is real behavioral context, but says nothing about auth, latency, sync vs async delivery, or output format for a paid document-generation call.

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?

Very short and front-loaded: the service identity, then price and required inputs. The internal ID (6671a5d69e6f0e447bc265a1) is filler, but the overall footprint is 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?

For a two-required-parameter tool with no annotations, no output schema, and no schema descriptions, the definition is too thin. It omits what the report contains, how the result is returned, and what the parameters mean, leaving the agent under-informed 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?

Both parameters (cciaa, reaCode) have 0% schema description coverage, so the description must compensate, yet it only repeats the bare names 'reaCode, cciaa' under 'Required'. It never explains that cciaa identifies the Chamber of Commerce and reaCode is the REA registration number, nor gives formats or examples.

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 document service (Visura Camerale Storica - Impresa Individuale) which distinguishes it from siblings like the 'ordinaria' and 'societa di capitale' variants by name. However, it only restates the tool name and ID without explaining what a historical chamber-of-commerce report for a sole proprietorship actually is, leaving an English-speaking agent to infer the resource.

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 when-to-use or when-not-to-use guidance and no named alternative, despite several near-identical siblings (visura ordinaria impresa individuale, storica societa di capitale). 'Direct tool' implies a straight service call but does not help the agent route between the many competing document tools.

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 behavioral burden. It discloses the price (€5.90), which is useful, but says nothing about authentication, delivery/async behavior, what the report contains, or how it differs from the ordinaria sibling in output.

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 short and front-loads the service name and ID. The price and required-parameter lines are compact, though the ID and price add limited agent value relative to space.

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?

No output schema, no annotations, and 0% parameter coverage mean the description should do more. For a paid, parameterized service tool it omits what the report returns, how it is delivered, and any prerequisites, leaving significant gaps.

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. It lists reaCode and cciaa as required but only repeats what the schema already marks as required, without explaining what a REA code or CCIA code is or their expected format.

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 service (Visura Camerale Storica for Societa' Di Capitale) and gives its ID, so the resource is identifiable. However, it essentially restates the tool name and does not differentiate from siblings such as docuengine_visura_camerale_ordinaria_societa_di_capitale or docuengine_visura_camerale_storica_societa_di_persone beyond the name itself.

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 guidance is provided. The description never explains when to choose this historical report over the ordinary version, the societa-di-persone variant, or the fascicolo alternatives, leaving the agent to infer selection from the Italian name alone.

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

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

With no annotations, the description carries the full behavioral burden, yet it only discloses a price (€4.40) and a generic 'Direct tool' label. It does not say whether the call is synchronous or async, what the returned document looks like, authorization requirements, or whether a reaCode/cciaa mismatch changes behavior. The price disclosure is the sole useful behavioral detail.

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?

Short and front-loaded, with the service identity first and price/required markers after. However, the opaque service ID and the name restatement consume most of the text, so the brevity reflects under-specification rather than information density.

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 and no annotations, so the description must explain the operation fully, yet it omits return content, access requirements, and selection logic within a very dense family of ~70 DocuEngine/visura siblings. For a paid, domain-specific document tool it is not complete enough to call reliably.

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. Instead it merely repeats the required set already declared in the schema, giving no meaning for reaCode (REA registry number) or cciaa (Chamber of Commerce). No formats, examples, or constraints are added.

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 restates the tool name ('Visura Camerale Storica - Societa' Di Persone') as a service label rather than stating what the tool actually does or returns. It never distinguishes this historical partnership report from close siblings like docuengine_visura_camerale_ordinaria_societa_di_persone or docuengine_visura_camerale_storica_societa_di_capitale. Purpose is effectively a tautology of the name.

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 when-to-use guidance, no exclusions, and no comparison to the many sibling 'visura' variants. Listing 'Required: reaCode, cciaa' is a schema restatement, not usage guidance. An agent cannot tell from this text why it would pick the storica partnership report over the ordinaria or societa_di_capitale versions.

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 full behavioral burden. It discloses the price (€0.90) and required parameters, but omits read-only vs. write behavior, authentication needs, return format, and side effects, leaving significant behavioral gaps.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is short and front-loads the service name and key facts (price, required params). It is mostly efficient, though it redundantly repeats 'Visura Protesti Azienda' and includes an internal ID that may not help the agent act.

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

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

Given no annotations, no output schema, and 0% parameter description coverage, the description is incomplete for a paid service tool. It identifies the service and price but lacks parameter definitions, usage guidance, and any indication of what the tool returns or how to interpret 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 description coverage is 0%, so the description must compensate by explaining the parameters. It only repeats the parameter names and their required status, adding no meaning about what reaCode and cciaa represent, their format, or how to obtain them.

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 identifies a specific DocuEngine service ('Visura Protesti Azienda') and includes an ID, so the agent knows it retrieves that particular report. However, it does not explain what a 'Visura Protesti Azienda' contains or distinguish it from close siblings like docuengine_visura_protesti_e_pregiudizievoli_azienda, leaving the exact scope ambiguous.

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 or when-not-to-use guidance is provided. The service name implies it should be used to obtain this specific report, but there is no mention of alternatives or prerequisites, so an agent must infer selection criteria.

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 behavioral burden, yet it only adds the price (€3.70) as useful context. It says nothing about what the returned document contains, whether the call is read-only, latency/async behavior, or delivery, despite siblings like check_async_status and get_docuengine_request_status hinting this may be an asynchronous ordering flow.

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 text is short and front-loaded with the tool's identity, but the internal service ID is noise for an agent and the price/required fields are appended without structure. It is compact but under-specified rather than truly concise.

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 document-ordering tool with no annotations, no output schema, and two completely undocumented parameters, the description leaves critical gaps: it never says what the document is, what the caller receives, or how results are delivered. It is inadequate for the tool's complexity.

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, but it merely repeats the two required parameter names (reaCode, cciaa) without explaining their meaning, format, or where they come from. No value is added beyond the schema's own required list.

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 restates the tool name and adds an internal service ID and category tag, but never explains in plain terms what a 'Visura Protesti e Pregiudizievoli Azienda' actually retrieves (a company report of protests/legal prejudicial events). It identifies a specific resource but a non-Italian-reading agent must infer the purpose, and it does not distinguish itself from the close sibling docuengine_visura_protesti_azienda.

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 when-to-use or when-not-to-use guidance, no mention of prerequisites, and no reference to any alternative. The many sibling visura tools are left for the caller to sort out unaided.

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 discloses a price (€3.70), which is useful cost context, but says nothing about whether the call is synchronous or asynchronous, whether it is billed on failure, how long it takes, or whether the result must be retrieved via get_docuengine_documents. For a paid document-fetch tool in a family that includes async status/retrieval siblings, that is a serious omission.

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 short, front-loaded fragments: identity, category/document name, price, and required parameters. Nothing is padded and the key facts appear immediately. Slightly mechanical in tone 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?

For a paid, three-parameter document-generation tool with no annotations and no output schema, the description omits the behaviors an agent most needs: output/retrieval mechanics, sync vs async nature, and any delivery or failure semantics. The price line is a good start but the definition is incomplete for this complexity.

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 does not: it merely repeats the three parameter names (name, surname, taxCode) already listed in the schema with no format guidance (e.g. Italian codice fiscale structure), no indication of whether the subject must be Italian, and no note that all three are mandatory. The parameter names are self-explanatory but the description adds no semantic depth.

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 (visura = official report) and resource (protesti e pregiudizievoli for a natural person), distinguishing it from sibling tools like docuengine_visura_protesti_persona_fisica or the azienda variants. It also embeds the internal service ID. It stops short of 5 because it never states in plain language what the report contains or why an agent would request it, leaving the Italian bureaucratic term to carry the meaning.

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 label '[Camerali]' and the required-param line imply this is a chamber-of-commerce document request, and the persona_fisica suffix implies natural-person scope. But there is no explicit when-to-use, no contrast with docuengine_visura_protesti_persona_fisica or docuengine_eventi_negativi_persona, and no prerequisites beyond the three required parameters. Usage is inferable but not stated.

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 of behavioral disclosure. It does add one useful trait — cost (€0.90) and that it is a 'direct' (presumably synchronous) tool — but it omits whether credentials are required, what the returned document contains, and how the result is delivered, leaving major behavioral gaps.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is short and front-loaded with the tool's purpose, price, and required inputs. However, the internal service ID (69b96b74327b41417c838fb0) is implementation noise that does not help the agent decide or invoke, and the repeated resource name wastes space.

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 document-retrieval tool with three parameters, no annotations, no output schema, and an async-looking sibling set, the definition is thin. It states cost but omits what the visura returns, delivery/async behavior, and how it differs from the overlapping 'protesti e pregiudizievoli' sibling.

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, but it only repeats the required parameter names (name, surname, taxCode) that the schema already lists. It adds no format guidance (e.g., Italian taxCode structure) or meaning 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 names a specific resource ('Visura Protesti Persona Fisica', categorized '[Camerali]'), so the agent knows it fetches a protest record for a natural person. However, it largely restates the tool name and gives no contrast against close siblings like docuengine_visura_protesti_e_pregiudizievoli_persona_fisica, so differentiation is left to the agent to infer.

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 or when-not-to-use guidance. The description does not tell the agent how this differs from docuengine_visura_protesti_azienda or the 'protesti e pregiudizievoli' persona variant, nor does it mention prerequisites, so the agent must guess from the name alone.

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

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

No annotations provided, so description carries full burden. It discloses the response shape (JSON with files and attributes file_name, file_size, download_link, content, expire) and the dependency condition, which is useful. However, it omits auth requirements, rate limits, what happens if the condition is not met, and whether the download is destructive or read-only.

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 content is front-loaded with the triggering condition and then the response structure. Two short paragraphs, no filler, though the parameter descriptions are vague rather than concise.

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 two-parameter download tool with no annotations and no output schema, the description provides the response shape and the prerequisite condition. It still lacks error handling, authentication needs, and clear parameter sourcing, leaving gaps an agent might encounter.

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% with 2 required parameters (document_id, document_url). The description says both are 'the value id in return of a previous request', which is imprecise and confusing—document_url is described as an id, not a URL. No format, source, or distinction between the two parameters is clarified.

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 (Download) and resource (document), and uniquely ties the action to the estado_richiesta value 'Dati disponibili' from get_italian_company_official_document. Distinguishes from sibling get_italian_company_official_document, though it could name other document siblings more 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?

Gives a clear condition: use only when stato_richiesta equals 'Dati disponibili' from a prior get_italian_company_official_document call. No explicit when-not or alternatives, but the precondition is a strong routing signal.

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 is implicitly a read-only lookup, but it discloses nothing about name-matching behavior, whether partial/ambiguous names return multiple results, or how to disambiguate. That is a real gap for a search tool with unstated matching rules.

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 key information front-loaded. It is not wasteful, though the very brevity is what leaves the parameter and behavioral gaps unaddressed.

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 lookup that lacks annotations and an output schema, the description should at least explain what comes back (an ISTAT code) and how ambiguous matches are handled. Neither is covered, so an agent cannot confidently predict results or failure modes.

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 single parameter 'comune' is documented only as 'a given Italian municipality', which is essentially a restatement of the parameter name itself. No guidance on accepted format, capitalization, accents, or exactness of the name match is given, leaving the main source of invocation error undocumented.

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 clear verb ('Searches for') and specific resource ('the ISTAT code associated with a given Italian municipality'), so an agent understands the direction of the lookup. However, it does not name the reverse-direction sibling find_IT_municipality_by_istat, which an agent could easily confuse with this 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?

Use is implied (you have a municipality name and want its ISTAT code), but there is no explicit when-to-use instruction and no mention of alternatives like find_IT_municipality_by_istat or find_IT_municipalities_by_zip. The agent must infer the routing itself.

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. It discloses the return content (list of municipalities plus ISTAT codes), which is useful given there is no output schema, but says nothing about read-only safety, whether a single ZIP can map to multiple municipalities, or any auth/rate-limit constraints.

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 verb and resource lead, and the keying field is stated last without 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?

For a simple one-parameter lookup with no annotations or output schema, the description covers the core operation. However, it omits input format guidance and the possibility of multiple results per ZIP, which are the main things an agent would still need.

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?

There is one parameter and schema description coverage is 0%, so the description must compensate but only implies that zip_code means an Italian ZIP. It gives no format, length, or example (e.g., 5-digit CAP), leaving the agent to guess the accepted input syntax.

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 (retrieves), resource (Italian municipalities and their ISTAT code), and lookup key (ZIP code). The 'by_zip' framing implicitly differentiates it from siblings like find_IT_municipality_by_istat and find_IT_istat_by_comune_name, though it never names them 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 only implied by the lookup direction: you use this when you have a ZIP code and want the associated municipalities. There is no statement of when to choose this over the ISTAT- or comune-name-based siblings, and no exclusions or prerequisites are given.

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 provided, the description carries the full behavioral burden. It implies a read-only lookup but never confirms this, nor does it disclose any errors, rate limits, or authentication requirements. The long field list is return-schema content, not behavioral disclosure.

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 dominated by a 17-line dump of output fields rather than a front-loaded purpose statement. This is bloated and poorly structured for an agent trying to determine when and how to call the tool; only the first line provides real signal.

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 one-parameter lookup with no output schema, the description should minimally define the parameter and confirm read-only behavior. Instead it lists return fields that belong in an output schema and omits the essential parameter definition and usage 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?

The schema has 0% description coverage and only one parameter, `istatCode`. The description never explains the expected format, validation, or source of this code — it merely lists returned fields. The parameter's semantics remain entirely unstated in both schema and description.

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 verb 'retrieves detailed data' and the specific resource 'Italian municipality using the ISTAT code.' This distinguishes it from the sibling `find_IT_istat_by_comune_name` (which resolves the reverse lookup) and `find_IT_municipalities_by_zip`, though it doesn't explicitly name those alternatives.

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 guidance on when to use this tool versus alternatives. The presence of `find_IT_istat_by_comune_name` implies this is the forward lookup when you already have the ISTAT code, but the description never states this condition or any prerequisites.

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 and largely fails it: no mention of authentication, rate limits, whether results are cached or live, or what the response looks like. 'To improve success of results' hints at result variability but discloses nothing concrete.

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, front-loaded with the purpose before the formatting advice. Minor waste in re-declaring 'Args: address: string', which duplicates the schema, and in the grammatical slip 'informations'.

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 annotations and no output schema, the description should ideally describe the returned data and error behavior for a simple single-param tool. The input-format hint is helpful, but the output side is entirely unspecified, leaving a real 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% for the single address parameter, so the description must compensate, and it does: it specifies a concrete format '[street], [city] [postal code] [country]'. This is meaningful guidance beyond the bare 'type: string' schema, though it does not explain how malformed input is handled.

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 verb ('Retrieve informations') and resource ('about a place'), which is clearer than a tautology, but it is vague about what is actually returned — coordinates, formatted address, administrative data — and it never distinguishes itself from the sibling 'reverse_geocode'. An agent must guess what 'informations' means.

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 alternatives; notably the sibling 'reverse_geocode' (the inverse operation) is never mentioned. The only guidance is about input formatting for better results, which is input semantics rather than usage routing.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=false, so the safety/behavior profile is largely covered. The description adds only the modest caveat 'or extended registry info where available', hinting that data completeness varies by country, but says nothing about auth requirements, latency, or per-country feature gaps.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded first sentence with a clean Args block; every element earns its place. The separate 'Returns:' sentence slightly duplicates the opening 'Returns advanced company information' and could be merged.

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 two-parameter read tool with annotations and no output schema, the essential call mechanics are present. However, the sibling-overlap problem (EU vs WW vs IT, start vs advanced) and the country-specific variation in returned data are not addressed, which is the main gap for correct selection.

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 full parameter burden and does so: it aliases vatCode to 'VAT code or company registration number' and clarifies country_code as a two-letter code with examples (FR, DE, ES). Only the vatCode format/validation remains unspecified.

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 ('Returns advanced company information for a company in the specified country') and scopes it geographically via the name/title. It does not differentiate itself from the many near-identical siblings, notably get_company_EU_start, get_company_WW_advanced, and get_company_IT_advanced, so the agent cannot tell which variant to pick from the text 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?

There is no when-to-use guidance and no alternatives named, even though the sibling set contains an obvious 'start' versus 'advanced' distinction and multiple geographic variants (EU/IT/WW). The agent is left to infer precedence 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=false, so the safety profile is covered. The description adds the returned field list (companyName, vatCode, address, activityStatus), but says nothing about auth, rate limits, or what happens when a company is not found.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the purpose, then return fields, then args. The 'Returns:' and 'Args:' blocks are efficient, though the repeated 'Returns' phrasing 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?

No output schema exists, so listing return fields is the right move, and both required params are exemplified. However, the missing when-to-use guidance against the many company siblings leaves a real gap for an agent choosing among alternatives.

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 full burden and mostly delivers: it gives concrete vatCode examples (DE123456789, FR12345678901234), clarifies vatCode may be a registration number, and shows the country_code format and accepted values. It stops short of stating format/length constraints per country.

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 (Returns) and resource (basic company information) scoped to a specified country. The word 'basic' implicitly contrasts with the 'advanced' sibling variants, but the description never names or explains that contrast, so the differentiation is only partial.

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 guidance on when to prefer this over get_company_EU_advanced, get_company_WW_start, or the other ~20 company siblings. The agent must infer from the name alone that 'start' means a lightweight lookup.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true and openWorldHint=false, so the safety profile is covered. The description still adds real behavior via dryRun ('only get count and cost'), a cost-preview mode not expressible in annotations, but it omits anything about rate limits, cost magnitude, 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?

One leading sentence states the effect, then a compact per-argument list — front-loaded and free of filler. Slight redundancy in restating parameter names, but the format is scannable and appropriately sized for 8 undocumented parameters.

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 search with no output schema or schema descriptions, the definition covers all inputs but stops short of completeness: no result shape, no explanation of enrichment tiers, no note on what 'cost' means in dryRun, and no filtering semantics. Adequate to call, not sufficient to call confidently.

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% across 8 parameters, so the description carries the full documentation burden and does document every one, including defaults (limit 10, dataEnrichment 'name'). Depth is thin in places — dataEnrichment lists values 'start, advanced, name' without explaining what each returns, and provinceCode conflates 'department code or region'.

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 concrete verb and resource — returns a list of French companies matching search criteria — and the FR scope implicitly separates it from the IT/EU/WW search siblings. It does not name an alternative explicitly, so an agent must infer the routing from the tool name.

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 guidance is given: nothing says when to prefer this over get_company_EU_advanced, get_company_IT_search, or the *_start variants, nor whether criteria are AND-combined. Usage must be inferred entirely from the parameter list.

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, openWorldHint=false, and idempotentHint=true, covering the safety profile. The description adds genuine value beyond that by enumerating the returned data, including the 10-year balance-sheet history and shareholders, which is the only place this return content is documented since there is no output schema. It stops short of auth, rate-limit, or error behavior, but for a read-only lookup that 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?

The 'Returns' framing is front-loaded and the Args section is separated, but the middle is a dense wall of comma-separated field names that is hard to parse. It is appropriately sized for a tool with no output schema, but the structure could be far cleaner (grouped categories, bulleted).

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 sensibly compensates by listing the returned fields, and it documents the single required parameter and its dual input formats. An agent has enough to call it correctly; only input-format specifics and failure behavior are 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 0%, so the description must carry the full load: it explains that vat_or_taxCode accepts either a VAT code or a tax code of an Italian company, which the bare 'string' schema does not. However, it gives no format details (length, numeric-only, prefix conventions), so the compensation is 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?

States a specific verb (Returns) and resource (an italian company's registration, tax, and financial data) retrieved via vatCode or taxCode, and enumerates the returned fields so the agent knows the payload is rich. It does not differentiate from close siblings like get_company_IT_full or get_company_IT_advanced vs get_company_IT_start, so an agent cannot tell why to pick this over those without opening each 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?

No when-to-use guidance, no prerequisites, and no mention of alternatives such as get_company_IT_full, get_company_IT_search, or get_company_IT_start. The only hint is the implied 'advanced = comprehensive' framing, which is not explicit routing guidance.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true and openWorldHint=false, so the safety profile is covered structurally. The description adds genuine behavioral scope limits beyond that (top-10 shareholders by ownership share, cashflow only with a 2-year history, ATECO history only since 2022), but says nothing about auth/prerequisite steps, latency, cost, or behaviour when a VAT is unknown.

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 in the first sentence and the invocation guidance is placed at the end where it addresses the input. The bulleted data catalog is long, but each line documents a distinct returned field family the agent would otherwise not know about, since there is no 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?

With no output schema, the description correctly compensates by enumerating the returned data in unusual detail, and annotations cover the safety profile. The remaining gap is operational context – how to authenticate, what happens on a not-found VAT, and how it differs from the advanced/start siblings – which is not strictly required to call the tool successfully.

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 carry the parameter burden, and it only restates the arg label: it accepts a 'VAT number or Tax Code of an Italian company'. No format, length, country-prefix or validation detail is added. For a single required parameter with an explicit either/or hint, a 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 first sentence gives a specific verb and resource ('Returns the complete and detailed profile of an Italian company') and the following bullets enumerate exactly what is retrieved, so an agent knows the payload is far richer than the search/start variants. It does not, however, distinguish itself from siblings like get_company_IT_advanced or get_company_IT_start, so sibling disambiguation is only partial.

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 one explicit routing hint – 'Use get_company_IT_search to obtain VAT' – which tells the agent how to obtain the required input. But there is no guidance on when to prefer this tool over get_company_IT_advanced, get_company_IT_start, or the docuengine/visura siblings, so usage is only implied for the main decision.

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 exist, so the description carries the behavioral burden alone. It discloses that this returns the full, updated code set for Italy, implying a stable reference lookup, but says nothing about response shape, caching, or whether the codes are the accepted input vocabulary for get_company_IT_search.

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 but followed by a massive inline enumeration of 60+ code pairs that dominates the definition. If this mapping cannot be returned in the response, it belongs in documentation or the output schema; as written it bloats the description and buries the routing instruction.

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 no-parameter reference-list tool with no output schema and no annotations, the description supplies the purpose, the scope, and the companion tool. An agent knows when to call it and what it will receive, though the inline enumeration would be better served as the actual return payload.

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 and the schema coverage is 100%, establishing the baseline of 4. The description correctly implies a parameterless reference lookup and the enumerated codes actually function as the expected value domain for downstream calls, which is useful beyond the empty 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: obtain legalFormsCodes and descriptions, scoped to Italy. It distinguishes the artifact from sibling lookups like get_company_IT_search, though the sentence is grammatically garbled ('Usefull with') and the bulk of the text is a code table rather than purpose prose.

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 explicitly tells the agent to use this with get_company_IT_search, which is the key routing signal an agent needs. It does not state when-not to use it or that no parameters are required, but the relationship to the sibling is made clear.

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 this readOnly/idempotent/openWorld=false, so the safety profile is covered. The description adds real behavioral value beyond that: a 1000-record cap, skip-based pagination, and the dryRun count+cost simulation, which an agent needs to plan 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?

Front-loads usage guidance before the arg list, which is the right order. It is long, and some per-parameter lines are thin ('...is optional', 'The cadastral code for the town'), but the size is defensible for a 27-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?

There is no output schema, so the description briefly covers returns (a list, enriched when dataEnrichment is set, or a count/cost under dryRun). For a 27-param search tool this is nearly complete; only the exact shape of the returned records is left implicit.

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 0% schema description coverage, the description carries the entire burden and does so for essentially all 27 params, including 'multiple values forbidden' constraints, the dataEnrichment default and allowed values, and enum-style hints for legalFormCode and activityStatus.

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 ('Returns a list of italian companies based on search criteria') and clarifies its role versus the VAT-number path. It references siblings get_company_IT_start and get_company_IT_advanced as sources of the enrichment payloads, giving partial sibling differentiation rather than a crisp full separation.

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?

Offers several concrete when-to-use conditions: when you don't know the VAT number, when you want a count via dryRun=1 with no limit, and when you need enriched data. It implies but never names the alternative for the case where you DO know the VAT number, so the guidance is clear context without a complete when-not branch.

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, which tell the agent this is a safe, repeatable, limited lookup. The description adds the list of returned fields, which is useful context, but does not describe auth, rate limits, caching, or error behavior. With annotations carrying the safety profile, 3 is appropriate.

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 first sentence is front-loaded and informative, listing the exact returned fields. The 'Args:' block repeats the parameter name and gives a tautological description that adds little. Overall reasonably sized but includes a redundant section.

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 1-param read-only lookup with no output schema, the definition is adequate yet incomplete. It lists returned fields, which is helpful, but lacks format guidance for the input, error semantics, and sibling differentiation. An agent could call it, but might also misroute to a more expensive sibling.

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 parameter name 'vat_or_taxCode' is not self-explanatory. The description repeats the one-line arg description but does not explain format (e.g., numeric string, length, optional IT prefix), nor whether vatCode and taxCode are different formats, nor what happens for foreign codes. Since coverage is low, the description must compensate and it does so only minimally.

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?

Clear verb+resource: returns company data from a VAT or tax code. But it doesn't distinguish from siblings like get_company_IT_full, get_company_IT_advanced, or get_company_IT_search which sound like they do similar things. Still, 'start' vs 'advanced'/'full' implies a low-fidelity cheap lookup, but this is not stated.

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 guidance on when to use this vs get_company_IT_advanced, get_company_IT_search, get_company_IT_full, or the docuengine tools. There is no explicit when/when-not or alternative routing. The word 'start' hints at a cheap entry point but it is not explained.

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 the safety profile is fully covered by structured data. The description adds nothing behavioral beyond that—no note on data freshness, coverage limits, billing, or what 'advanced' tier data includes.

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 sentences plus an Args block, front-loaded with the purpose before the parameter explanations. The Args list duplicates schema structure but is justified given 0% schema description coverage.

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

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

For a read-only, two-parameter lookup the usage surface is small, but with no output schema the description leaves the return contents entirely undefined ('advanced company information' could be any field set), and the tier relationship to sibling tools is 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?

Schema description coverage is 0%, so the description carries the burden and largely does: it clarifies that vatCode also accepts a company registration number and that country_code is a two-letter format. This adds genuine meaning beyond the bare schema types, though no example values or validation hints are provided.

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 and resource (returns advanced company information) and scopes it as 'worldwide', but 'advanced' is an opaque tier label and the description never distinguishes this from the many sibling lookups (get_company_WW_start, get_company_WW_top, get_company_EU_advanced). An agent cannot tell from the text alone which tier variant it needs.

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 guidance is given. The description does not explain when to pick WW_advanced over WW_start, WW_top, or the IT/EU advanced variants, nor does it state any prerequisites. The agent must infer usage entirely from the tool 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?

Annotations already declare readOnlyHint, idempotentHint and openWorldHint=false, so the safety profile is covered. The description adds nothing beyond this: it does not explain what 'basic' data is returned, whether pagination or rate limits apply, or any auth constraints.

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?

Compact and front-loaded: the purpose sentence comes first, then a short Args block. No wasted prose, though the parsed 'Args:' formatting is slightly mechanical rather than prose-integrated.

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 2-parameter lookup the description covers purpose and both params, but it omits what the 'basic' payload contains, how this tier differs from WW_advanced/WW_top, and (with no output schema) any indication of return shape. Adequate but with clear gaps.

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, and it does: it documents vatCode as 'VAT code or company registration number' (a meaningful dual-acceptance note) and country_code as a two-letter code. Both required parameters gain real semantics beyond the bare string types.

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 ('Returns basic company information for a company worldwide'), so the agent knows the operation. However, it does not distinguish this 'start' tier from sibling tools get_company_WW_advanced and get_company_WW_top, which occupy the same namespace.

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 guidance and no mention of alternatives. Given that three sibling tools (WW_start, WW_advanced, WW_top) appear to offer different depth tiers for the same resource, the absence of routing guidance is a real gap.

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 (readOnlyHint=true, idempotentHint=true, openWorldHint=false) already declare this is a safe, repeatable, closed-world read. The description adds value by listing the returned data fields, which matters because there is no output schema. It still omits behavioral context like whether missing companies return null vs error, or whether the lookup is live vs cached.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loading 'Returns ...' is good, but the payload is a raw comma-dumped field list with inconsistent formatting (a trailing space before 'Args:') rather than a structured, scannable breakdown. It is moderately verbose without clear hierarchy.

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, listing returned fields is a reasonable compensation. But the omission of any differentiation from the many sibling company-lookup tools (WW_start, WW_advanced, EU_*, IT_*) leaves a material gap for correct tool selection.

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 and does map both parameters (vat_or_taxCode = VAT or tax code; country_code = country code). But it adds no format syntax, casing, or example values, and does not clarify the interaction between the two required args.

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 clear verb ('Returns') and enumerates the resource fields for a worldwide company lookup, so the agent knows what data comes back. However, it never distinguishes this tool from its close siblings get_company_WW_start and get_company_WW_advanced (nor the EU/IT variants), and the title ('Start...') even conflicts with the name ('top'). An agent cannot tell from the description which WW tier 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 no when-to-use guidance, no mention of what makes this the 'top' tier versus 'start' or 'advanced', and no prerequisites (e.g. which VAT/taxCode formats are accepted, or coverage limits). Usage must be entirely inferred from the 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 behavioral burden. It says it returns download links but doesn't state whether links expire, whether the operation is safe/read-only, what happens if the request is still processing, or what form the response takes. For a tool with zero annotation coverage this is a substantial 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 efficient sentence with the purpose front-loaded and no wasted words. It is well-sized, though the brevity comes at the cost of detail elsewhere.

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 retrieval tool with no annotations and no output schema, the description should at least characterize the returned links (expiry, quantity, format) and the prerequisite request lifecycle. It notes only that links are returned, leaving key operational context 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 0% and the description never mentions 'request_id' explicitly. The only hint is the phrase 'produced by a request,' which leaves the parameter's origin, format, and how to obtain it undocumented in both schema and description.

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: 'Returns the download links for the documents produced by a request.' This is clear enough to distinguish from most siblings, but it never names the related tools (get_docuengine_request_status, the document-generating docuengine_* calls), so an agent must infer the workflow linkage on its own.

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

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

No guidance on when to call this versus alternatives. It doesn't explain the expected flow (generate document → poll status → fetch links) or that a prior request must exist, which is essential context given the large sibling set of docuengine_* tools.

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 behavioral burden. It implies a read-only lookup via 'Returns', but says nothing about authentication needs, rate limits, whether the request is asynchronous, or what happens if the request_id is unknown or expired.

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 efficient sentence with no filler and the resource front-loaded. It is concise, though the brevity comes at the cost of the missing guidance noted elsewhere.

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 and no annotations, so the description must carry the meaning of 'details' — but it never says what is returned or in what form. For a status-polling tool in a family of ~40 DocuEngine tools, this leaves the agent under-informed.

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 schema documents no parameter semantics. The description's phrase 'specific DocuEngine request' only loosely associates request_id with a request entity and gives no format, origin, or example of a valid 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?

States a clear verb+resource: returns details and status for a specific DocuEngine request. It is distinguishable in spirit from the docuengine_* document-generation siblings, but it never names check_async_status or explains how they differ, so sibling differentiation is implied rather than stated.

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 when-to-use or when-not-to-use guidance. With a sibling like check_async_status present, the agent gets no signal about which status-checking tool to pick or when a request_id is available to poll.

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, but the operation is a simple zero-parameter read with no side effects and it does say what comes back (services plus their required parameters). It stops short of confirming the read-only nature or how large/long the catalog is.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence that identifies the resource and the payload with no filler. Nothing to trim.

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 zero parameters and no output schema, the description adequately covers both the input side (nothing needed) and the output side (a list of services with their required parameters). A note on how this relates to the sibling document tools would make it 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?

The tool takes no parameters, so the baseline of 4 applies. The one sentence about 'required parameters' refers to the returned service definitions, not to inputs, so there is no input semantics to document.

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: returns the catalog of DocuEngine services along with their required parameters. This clearly differentiates it from the sibling docuengine_* tools, which each retrieve a particular document type, though it never names that contrast 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 call this versus the many docuengine_* document tools, nor that it should be used as a discovery step before invoking a specific service. The discovery role is only implied by the word 'list'.

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 does not say whether the call is synchronous or asynchronous (siblings check_async_status/get_docuengine_request_status suggest async workflows), whether it is billable, what permissions or credentials are needed, or what is returned. The unusual requirement to pass a document_url in order to 'retrieve' a document is also left unexplained.

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 sentence is front-loaded and short, and the arg list is compact. It is slightly redundant with the input schema, but there is no padding or 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?

With no output schema, no annotations, 0% schema coverage and no explanation of the document_url parameter or async behavior, the description is not sufficient for an agent to invoke this tool correctly. It also mixes Italian and English and uses an internal arg name that conflicts with the 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 description coverage is 0%, so the description must compensate, and it only partially does: 'url of the requested document' does not explain where that URL comes from or what form it takes, and the identifier is written as 'vat_or_taxCode', which does not match the actual parameter name 'vat_or_tax_code'. The two required params are named but their format/validity rules are unstated.

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 ('Recupera una visura camerale di una azienda') and names the identifiers accepted (Partita IVA or Codice Fiscale), so the agent can tell what this tool returns. It does not, however, distinguish it from the many sibling docuengine_visura_camerale_* tools or from get_italian_company_official_documents_list / download_italian_company_official_document.

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 the numerous sibling document tools (e.g. download_italian_company_official_document, get_italian_company_official_documents_list, docuengine_visura_camerale_ordinaria_*). The agent must infer the workflow (list -> get -> download) on its own.

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 discloses the return shape at a high level (a list of endpoints) and that it is a lookup ("Recupera"), but does not mention permissions, rate limits, whether an unknown VAT/tax code errors or returns empty, or any cost/async behavior.

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 purpose sentence is front-loaded and waste-free, with the argument documented briefly afterward via a conventional "Args" block. The bilingual mismatch (Italian prose, English arg labels) is slightly inelegant but does not bloat the text.

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 lookup tool with no output schema and no annotations, the description covers what it does, what it returns conceptually, and how it chains to get_italian_company_official_document. It stops short of describing error/empty-result behavior, which is the main remaining gap.

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

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

Schema description coverage is 0%, so the description must compensate, and it does: it explains that the single argument is the company's VAT code OR tax code. Minor drawback: it names the arg "vat_or_taxCode" while the schema uses "vat_or_tax_code", and it doesn't state accepted formats (e.g. length/prefix).

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 concrete verb ("Recupera") and resource ("elenco di endpoint di visure camerali disponibili per una azienda"), and explicitly positions itself against the sibling get_italian_company_official_document by saying the returned endpoints are meant to feed that tool. An agent can distinguish this discovery/lookup tool from the document-fetching sibling without opening either 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 clearly states the context of use: call this to get the available document endpoints, then use them with get_italian_company_official_document. However, it gives no when-not guidance (e.g. no note about what happens if the company has no documents, or whether this must precede the fetch tool).

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