iubenda

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

The description discloses the side effect (create), the uniqueness constraint (only one per site), and the precondition (site must exist). These go beyond the annotations, which only indicate non-read-only, non-idempotent, and non-destructive behavior, but do not detail failure modes.

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 two sentences long, front-loads the core action, and packs the key constraints without redundancy. It is concise and directly relevant 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?

The description gives enough high-level context for creation and constraints, but there is no output schema or return-value description. It also leaves error behavior (e.g., duplicate attempts or nonexistent site) unspecified, so an agent may need to infer outcomes from sibling tool patterns.

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?

All parameters are documented with schema descriptions, but the descriptions are minimal: site_id and remote_configuration are clear, while configuration is only described by an external link. Since configuration is a nested object with no internal schema, the description doesn't fully specify how to populate it.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Create') and the resource ('Cookie Solution for a site'), and adds two important constraints: 'Only one per site' and 'the site must exist first.' This distinguishes it from sibling tools like get_cookie_solution, update_cookie_solution, and delete_cookie_solution.

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

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

It gives a concrete prerequisite ('site must exist first'), which helps with sequencing after create_site. The uniqueness constraint implicitly suggests using update_cookie_solution if one already exists, though it does not name that alternative explicitly.

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?

The description discloses that the document is created as a draft, shown as 'resume generation' in the dashboard, and only becomes complete once owner info is set via update_site. This is meaningful behavioral context beyond the uninformative all-false annotations, though it doesn't cover duplicate-call behavior or return/output details.

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 concise sentences each add essential information: the core action, the preconditions, and the follow-up workflow. There is no filler, repetition of schema details, or unnecessary expansion.

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

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

The description fully supports a correct invocation by covering the required prerequisite, uniqueness constraint, draft lifecycle, and optional next step. It does not describe success/error responses or the optional configuration object, but those are either schema-covered or secondary to calling the 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 description coverage is 100%, with site_id and configuration/badge_style already described in the input schema. The description adds usage-level constraints like site existence and one-per-site, but it does not add meaning to the parameters beyond what the schema provides, so the baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb-resource pair: 'Create a Privacy & Cookie Policy document for a site', making the tool's purpose clear. It further distinguishes it from siblings by noting the one-per-site constraint and by pointing to create_site_pcp_service as the separate service-adding 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?

It states explicit preconditions: the site must exist first and only one policy is allowed per site. It also lays out the follow-up workflow — set owner info via update_site — and names the alternative for adding services, creating clear when-to-use 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?

It goes well beyond the basic annotations by disclosing that legislation flags are enabled by default, that no policy products are active until created, and that the response contains a dashboard_url field. It also instructs the agent to surface business_details_warning when present, which is valuable runtime behavior not available from annotations.

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

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

The description is four sentences long and every sentence earns its place: purpose, default legislation flags, inactive-policy state, and response handling. It is front-loaded with the core action and contains no filler or repetition.

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

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

The description covers key contextual information not present in the schema or annotations: defaults, response dashboard_url, and the warning field to surface. Even without an output schema, it gives the agent actionable output guidance, though it could mention other response fields that might be needed for follow-up operations.

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 input schema has 100% parameter description coverage, so the schema already carries the burden of explaining parameters. The description adds context about defaults and response behavior, but it does not add meaning to individual input parameters beyond what the schema provides. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description begins with a specific verb and resource: 'Create a new iubenda site.' It also adds default behavior details, making the tool's purpose unmistakable and clearly distinct from siblings like create_privacy_cookie_policy or create_terms_conditions.

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 provides useful context by stating that no Privacy Policy, Cookie Solution, or Terms & Conditions is active until explicitly created, which implies when sibling creation tools are needed. However, it does not explicitly state when to use this tool versus alternatives or provide any exclusion 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?

Annotations already signal this is not read-only and not idempotent, so the 'Add' wording adds little new safety information. The description contributes the prerequisite about an active Privacy & Cookie Policy, but it does not disclose failure behavior, duplicate handling, or side effects beyond creation.

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 tightly written sentences with no wasted words. The main action is front-loaded and the supporting lookup advice plus prerequisite follow naturally.

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

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

The description covers the essential call path: which resource to add, how to find service IDs, and a key prerequisite. It is adequate for a straightforward create call, but it omits any indication of the response/return value or what happens if the Privacy & Cookie Policy requirement is not met, leaving some situational ambiguity.

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 descriptions cover all four parameters, so the baseline is 3. The description adds extra value by telling the agent where service_id comes from ('Use list_pcp_services') and implying site_id identifies the target site, which goes 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 uses a specific verb ('Add') with a specific resource ('PCP catalog service') and target ('site'), making the action clear. It does not explicitly contrast with update_site_pcp_service or delete_site_pcp_service, but the add semantics and title are enough to distinguish it from most 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?

It gives a concrete prerequisite ('active Privacy & Cookie Policy') and a direct instruction to use list_pcp_services for finding valid service IDs. It does not spell out when to use update_site_pcp_service instead, but the context for this create operation is 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 only provide generic non-read-only, non-idempotent, non-destructive flags, so the description carries the burden of behavioral disclosure. It reveals a meaningful behavioral trait: the document is created as a draft shown as 'resume generation' and is only finalized once owner info is set via update_site. The uniqueness constraint is also disclosed.

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 with no filler. The main purpose is front-loaded, followed immediately by the most important constraints, and then the draft lifecycle detail. Every sentence earns its place.

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

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

For a create operation with no output schema and only generic annotations, the description covers purpose, preconditions, uniqueness, and post-creation draft behavior. It leaves the return value unspecified and does not state behavior if a Terms & Conditions document already exists, but the essential information needed to call the tool correctly 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 100%, so the schema already documents site_id and configuration. The description adds context that site_id must reference an existing site and that only one document is allowed per site, but it does not add detail about the configuration object. This meets the baseline for schema-covered parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific action ('Create...document'), a specific resource ('Terms & Conditions document for a site'), and adds defining constraints: one per site, site must exist first. This clearly distinguishes it from sibling create_* tools.

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

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

The description gives explicit preconditions and lifecycle context: only one per site, the site must exist first, and the document remains a draft until owner info is set via update_site. It does not explicitly name update_terms_conditions for modifying existing documents, but the creation flow and dependency on update_site are 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?

The destructiveHint annotation already signals a destructive operation, and the description adds no further behavioral context such as irreversibility, cascading effects, permission requirements, or impact on related records. It simply restates 'Delete' without going beyond what the annotation already conveys.

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

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

The description is a single front-loaded sentence with no wasted words. It is efficient but adds little explanatory depth, so it earns a 4 rather than a 5.

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

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

The tool is simple: one required parameter and no output schema, so the description plus annotations and schema are minimally sufficient to identify the call. However, it leaves out what the response looks like, whether deletion has cascading consequences, and any usage guidance for choosing this tool among related siblings.

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, site_id, and the schema already describes it as 'Site ID' with 100% coverage. The description adds the phrase 'for a site' but provides no additional meaning, format requirements, or edge-case context.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a clear verb ('Delete') and names a specific resource ('Cookie Solution for a site'), distinguishing it from sibling tools like delete_privacy_cookie_policy and update_cookie_solution. However, it mostly restates the tool name and title, so it stops just short of a 5.

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

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

No guidance is provided about when to use this tool rather than alternatives. The sibling list includes create, update, get, and delete variants, but the description never mentions them or any conditions that would select this tool over another.

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 destructiveHint=true and readOnlyHint=false, so the destructive nature is covered. The description adds the specific object being destroyed (the Privacy & Cookie Policy document), but does not disclose whether deletion is permanent or has cascading effects on related site services.

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

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

The description is a single, efficient sentence that front-loads the action and object. Every word earns its place, with no filler or redundancy.

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

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

For a simple deletion tool with one required parameter, destructive annotation, and no output schema, the description is mostly sufficient. It clearly names the target resource and the required scope, though it does not explain edge cases like deleting a nonexistent policy or impact on related PCP services.

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

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

Schema description coverage is 100%, with site_id documented as 'Site ID'. The description repeats the site context but adds no new parameter-level meaning such as format expectations or behavioral implications of the site_id.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('Delete'), a concrete resource ('Privacy & Cookie Policy document'), and a clear scope ('for a site'). This cleanly distinguishes the tool from sibling operations like create_privacy_cookie_policy, update_privacy_cookie_policy, and delete_terms_conditions.

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 provides no guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. It relies entirely on the tool name and context to infer that this is the deletion operation for privacy/cookie policy documents.

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 destructiveHint=true and idempotentHint=false, and the description adds no additional behavioral context such as permanence, cascading effects, authorization requirements, or result behavior. It does not contradict the annotations, but provides no incremental transparency beyond them.

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

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

The description is a single, efficient sentence with no filler. The action and object are front-loaded, making it immediately scannable and easy to parse.

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 destructive tool, the core calling information is present and the destructiveHint annotation covers the main risk. However, there is no description of expected return behavior, postconditions, or any side effects beyond deletion, leaving a moderate 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?

The schema has 100% parameter coverage with 'id' already described as 'Site ID'. The description echoes 'by ID' but adds no new semantic detail beyond confirming that the deletion is keyed by the site identifier.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Delete'), a clear resource ('an iubenda site'), and the key selector ('by ID'). It is unambiguous and easily distinguished from sibling tools like delete_site_pcp_service or update_site.

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 is provided about when to use this tool versus alternatives, prerequisites, or consequences. It simply states the operation without addressing when deletion is appropriate or what to check first.

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 destructiveHint=true, readOnlyHint=false, and idempotentHint=false, so the safety profile is covered. The description adds little beyond the word 'Remove,' which restates the destructive nature. It does not contradict annotations, and the bar for added behavioral disclosure is lowered by the annotations.

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

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

Two short sentences, no filler. The core action is front-loaded and the practical id-source hint follows immediately. Every word earns its place.

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

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

For a simple two-parameter delete tool, the description provides the essential information: what is removed and where to get the identifier. The destructive annotation covers the main risk. A brief note on permanence or return value would make it fully complete, but nothing critical is missing.

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

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

Input schema coverage is 100%, with both parameters documented ('Site ID' and 'Primary key of the added service'). The description essentially repeats the id guidance already present in the schema, so it adds minimal value beyond the structured field descriptions.

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 opens with a specific verb and resource: 'Remove a PCP service from a site.' This clearly identifies the action and target, and the reference to the primary key from list/create distinguishes this delete operation from related site-PCP tools like update_site_pcp_service or get_site_pcp_service.

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

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

The description gives clear operational guidance: use the primary key returned by list_site_pcp_services or create_site_pcp_service. This tells the agent where to obtain the required id. It does not explicitly name alternatives or when-not-to-use scenarios, but for a delete tool the usage context is sufficiently 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?

The description's 'Delete' matches the destructiveHint=true annotation without contradicting any annotations. It adds useful scope by clarifying that the target is a per-site Terms & Conditions document, but it does not disclose permanence, cascading effects, or failure behavior. Since the annotation already conveys destructiveness, the description provides minimal extra behavioral context.

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

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

The description is a single, compact sentence of nine words with no filler. The action, target, and scope are all front-loaded, making it immediately understandable.

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 delete operation, the description, schema, and annotations together provide enough information to invoke the tool correctly. The resource scope is clear, the destructive behavior is flagged, and the required site_id is documented. A minor gap is the lack of any statement about the expected response or lack thereof, since there is no output schema.

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

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

The input schema has 100% description coverage for site_id, so the schema fully documents the parameter. The tool description does not add any extra meaning about the parameter beyond what the schema provides. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states exactly what the tool does: it deletes the Terms & Conditions document for a site. The verb 'Delete' and the specific resource scope clearly distinguish it from sibling tools like create_terms_conditions, get_terms_conditions, update_terms_conditions, and delete_site.

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 guidance is given about when to use this tool versus alternatives such as update_terms_conditions or get_terms_conditions. There are no prerequisites, exclusions, or side-effect warnings; usage is only implied by the verb 'Delete.'

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?

The description adds the site-scoping constraint, which is a small behavioral detail beyond the annotations. However, it does not disclose what is returned, error behavior, or dependencies; the read-only safety is already covered by readOnlyHint=true.

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

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

The description is a single short sentence with no filler and the essential scope is front-loaded. It is appropriately minimal for such a simple tool definition.

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 well-documented parameter and readOnly annotations, minimal information may be sufficient. However, there is no output schema and the term 'Cookie Solution' is ambiguous next to 'Privacy Cookie Policy', so the description would benefit from clarifying the return value and how it differs from similar getter 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 coverage is 100%, so site_id is already documented. The description's 'for a site' reinforces the parameter's role but adds no format, source, or validation details, so the baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a clear verb-resource pair ('Get' + 'Cookie Solution') and scopes it to a site, which distinguishes it from the create/update/delete siblings. However, it does not differentiate 'Cookie Solution' from the related sibling 'get_privacy_cookie_policy', leaving mild ambiguity.

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 provides no guidance on when to use this tool versus alternatives, nor any prerequisites or exclusions. The verb 'Get' weakly implies read-only retrieval, but no explicit usage context is 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?

Annotations already communicate that this is read-only and non-destructive; the description adds useful context about what the response includes. It does not disclose error behavior, not-found cases, or how the optional lang parameter affects the result, so the transparency is adequate but not rich.

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

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

The description is a single, front-loaded sentence with no filler. Every part is informative: the action, the resource, the lookup method, and the expected response contents.

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 straightforward two-parameter getter, the description is sufficient: it names the resource, the required ID, and the main response contents. It lacks explicit language-behavior or error-handling detail, but the schema and annotations cover the remaining essentials.

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

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

Schema description coverage is 100%, so both id and lang are already documented. The description itself only restates the 'by ID' aspect and adds no new parameter-level detail; the baseline of 3 is appropriate when the schema carries the parameter documentation burden.

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 a specific retrieval verb ('Get'), a precise resource ('PCP catalog service'), and the identifying key ('by ID'). It also names the two relevant response contents — available personal data types and processing places — which distinguishes it from list_pcp_services and get_site_pcp_service.

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

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

The description implies the usage through the resource type and ID, and the schema's id description ('from list_pcp_services') gives a helpful workflow hint. However, there is no explicit when-to-use or when-not-to-use guidance, nor a pointer to a site-scoped sibling like get_site_pcp_service.

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 destructiveHint=false, so the safety profile is covered. The description adds a 'current' temporal nuance, but does not disclose error behavior, return shape, or any special conditions.

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

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

A single, well-structured sentence with no filler. The main action and scope are front-loaded, making the purpose immediately clear.

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 read-only tool with one fully documented parameter and no output schema, the description is almost complete. It clearly states what is retrieved and for which entity; only the exact return fields are unspecified, which is a minor gap here.

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 input schema has 100% description coverage for the only parameter, site_id, described as 'Site ID'. The description adds no format, constraints, or extra meaning beyond what the schema already provides, so the schema carries the burden.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Get'), a specific resource ('current pricing package'), and scopes it to a site. This clearly distinguishes it from sibling getters like get_site and get_user.

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 name and description: use this when you need the current pricing package for a site. However, it does not explicitly discuss when not to use it or compare it with alternative 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 and destructiveHint=false, so the safety profile is covered; the description does not contradict this. The description adds no behavioral details beyond the resource name, such as response form or absence of site mutation, but this is a simple read operation.

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

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

The description is a single short sentence that front-loads the verb and resource with no redundant wording. It is appropriately sized for a one-parameter read operation, though it carries minimal substance.

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 getter with one documented parameter and read-only annotations, the description is minimally sufficient. However, with no output schema, it does not clarify what form the returned document takes, such as text, URL, or structured object, which could be useful for correct invocation.

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

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

The input schema fully documents the single site_id parameter with 100% coverage, so the description does not need to compensate. The phrase 'for a site' loosely maps to site_id but adds no format, requiredness, or example beyond what the schema already provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a clear verb ('Get') and a specific resource ('the Privacy & Cookie Policy document for a site'), which is readily distinguishable from many siblings. It does not explicitly name alternatives such as get_pcp_service or get_terms_conditions, but the resource and site scoping are specific enough.

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 is provided about when to choose this tool over closely related siblings such as get_pcp_service or get_site_pcp_service, and no exclusions or prerequisites are mentioned. The only contextual cue is 'for a site', which is already implied by the site_id parameter.

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 destructiveHint=false, so this is known to be a safe read operation. The description adds valuable behavioral detail beyond annotations by specifying the polling semantics, the authoritative status field, the ready alias, and the exact categories of returned 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 description is three sentences with no wasted language: it front-loads the purpose, then gives the polling guidance, then lists the returned data. Every sentence contributes directly to correct invocation and interpretation of the result.

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 with no output schema, the description is complete: it states when to call it, how to interpret completion, and what fields the response contains. Nothing essential for selecting or invoking this tool correctly is missing.

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

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

The input schema already documents site_id as 'iubenda Site id (numeric id or public id)' with 100% coverage, so the description does not need to add parameter-level detail. The description's reference to 'an iubenda site' aligns with the schema but adds no new semantic 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?

The description uses a specific verb and resource, 'Retrieve the current Radar compliance scan for an iubenda site,' making the tool's purpose explicit. It also differentiates from start_scan by framing this as the polling counterpart that returns the scan result, and it enumerates the key categories of returned data.

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

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

The description gives clear usage context: 'Poll this after start_scan until `status` is `completed`' and identifies `status` as the authoritative signal. It does not explicitly name alternatives to avoid, but the polling workflow and termination condition are clearly 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?

Annotations already declare readOnlyHint=true, so the description does not need to restate safety. It adds little beyond 'by ID' and does not mention behavior on missing/invalid IDs or the shape of the returned site. This is acceptable for a simple read but does not exceed the annotation coverage.

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

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

A single, front-loaded sentence with no filler. It states the resource, verb, and selection mechanism in the most economical form possible for this simple 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?

For a one-parameter read-only tool with readOnlyHint=true, the description is nearly complete for invoking the tool correctly. It could mention what is returned or how missing IDs are handled, but the operation is simple enough that these are minor 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?

The input schema already fully documents the only parameter, 'id', as 'Site ID' with 100% schema description coverage. The description merely restates lookup-by-ID and adds no additional format, constraints, or contextual 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 uses a specific verb ('Retrieve'), a clear resource ('a single iubenda site'), and a selection key ('by ID'). This distinguishes it from list_sites and other site-related tools, so an agent can tell exactly what the operation does.

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

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

The description implies that the tool is used when you already have a site ID and want one site, but it does not explicitly state when to use this tool versus alternatives like list_sites when no ID is available. Usage guidance is present only by implication.

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 destructiveHint=false, so the read-only nature is covered. The description adds the scoping information that this is a site-added PCP service, but does not disclose return behavior, error cases, or other operational traits. This adds some value without going beyond annotations significantly.

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 concise sentences with no filler. The main retrieval purpose is front-loaded, and the pointer to list_site_pcp_services is a useful addition that earns its place.

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

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

For a simple read operation backed by readOnly/destructive annotations and a fully described schema, the description gives the agent everything needed: what to retrieve, how to identify it, and where to go for update/delete keys. No output schema exists, but none is necessary for this straightforward getter.

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

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

Schema description coverage is 100%, so the baseline is 3. The description clarifies that 'id' is the catalog service_id and that the resource is site-scoped, but it does not meaningfully enrich parameter understanding beyond what the schema already provides. The 'lang' parameter remains unexplained, though it is optional.

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 ('Get'), a clear resource ('PCP service added to a site'), and the lookup key ('catalog service_id'). It also distinguishes this from global catalog tools like get_pcp_service by emphasizing the site association.

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 clearly implies this tool is for retrieving a site-specific PCP service by catalog service_id, and it points to list_site_pcp_services for finding primary keys. It does not explicitly name alternative get tools or exclusion conditions, but the context is clear enough for an agent to select it appropriately.

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 destructiveHint=false, so the safe-read profile is known. The description adds that the result is a 'document', which provides a small behavioral hint about the return value, but it does not go further into formats, versions, or error behavior. This is minimally adequate given annotation coverage.

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 sentence that front-loads the verb and resource. Every word earns its place, and there is no redundant elaboration.

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 read-only getter with annotations covering safety and no output schema, the description provides the essential purpose. It could be more complete by stating the returned representation or behavior when no Terms & Conditions exist, but nothing critical is missing for invoking the 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?

The input schema already documents site_id at 100% coverage, so the baseline is 3. The description only reinforces that the site context is relevant without adding parameter format, constraints, or additional 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 uses a specific verb ('Get') and resource ('Terms & Conditions document') tied to a site, which clearly distinguishes it from the create/update/delete siblings in the tool list. It also separates it from related policy tools by naming the exact document type.

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

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

The description implies the tool should be used when you need a site's Terms & Conditions document, but it does not explicitly state when to prefer this over alternatives or mention the create/update/delete counterparts. Context is clear but exclusions and routing guidance are absent.

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 destructiveHint=false, covering the safety profile. The description adds valuable beyond-annotation context by clarifying that updated_at reflects internal record changes, not user-initiated activity, which prevents misinterpretation of returned 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?

Two sentences with no wasted words: the first states the primary action, and the second provides an important caveat. The key information is front-loaded and easy to parse.

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 parameterless, read-only tool with annotations covering side effects, the description is complete. It names what is retrieved, clarifies a potentially confusing field, and needs no output schema to be actionable.

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

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

The tool has zero parameters, so the schema already provides complete coverage. The description adds a field-level semantic note about updated_at, which is useful context though not parameter-specific. Baseline 4 applies for zero-parameter tools.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Retrieve') and resource ('authenticated user's account details'), clearly stating what the tool does. It is distinct from sibling tools that manage sites, cookie solutions, terms, and scans, so an agent can easily tell it apart.

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 usage context is implied: use this tool when you need the authenticated user's account details. However, there is no explicit statement about when to use it versus alternatives, though no sibling tool appears to overlap this function.

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 destructiveHint=false, so the safety profile is clear. The description adds context that this is a catalog-browsing operation and mentions query filtering, but it does not disclose return shape, pagination behavior, or any other runtime nuances beyond what annotations and schema already cover.

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 two sentences with no filler. It front-loads the primary purpose, then explains the key query-filtering behavior. Every sentence earns its place.

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

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

For a simple read-only list operation with zero required parameters, the description provides enough context to call the tool correctly: browse the catalog, discover addable services, and optionally filter by query. It could be more complete by noting the distinction from list_site_pcp_services or describing the response shape, but those are minor gaps given the low 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 100%, so the schema already documents all five parameters. The description adds only a helpful example for the query parameter ('google'), which is useful but not extensive. The baseline of 3 applies because the schema carries the parameter semantics.

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 action ('Browse the catalog') on a specific resource ('Privacy Controls and Cookie Policy (PCP) services') and clearly frames the scope as discovering services available to add to a site. This distinguishes it from sibling tools like list_site_pcp_services and get_pcp_service.

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 clearly explains when to use the tool: to discover services that can be added to a site. It gives a concrete example of filtering by query. However, it does not explicitly say when not to use it or point to alternatives such as list_site_pcp_services for services already associated with a site.

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 indicate readOnlyHint=true and destructiveHint=false, covering the read-only safety profile. The description adds the useful behavioral prerequisite of an active Privacy & Cookie Policy, but does not disclose error behavior or response shape.

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

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

The description is a single, front-loaded sentence that states the action, scope, and an important prerequisite without any filler. Every part earns its place.

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

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

The schema and annotations cover parameters and read-only behavior, but the description omits guidance on sibling tool selection, expected return shape, and behavior when the required policy is absent. It is adequate for a simple list operation but has 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 100%, so all five parameters are documented in the schema. The tool description itself adds no additional meaning about the parameters, matching the baseline expectation when the schema carries the information.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action (List), the resource (PCP services), and the scope (added to a site). It implicitly distinguishes from the sibling list_pcp_services by focusing on site-scoped services, though it does not explicitly name that alternative.

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 provides a clear precondition: an active Privacy & Cookie Policy is required. However, it does not explain when to use this tool versus the closely related list_pcp_services sibling, leaving some selection guidance to inference.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds conceptual context about what sites are but does not disclose further behavioral traits such as pagination behavior or response shape, though the schema documents pagination parameters.

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

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

Two short sentences with no redundancy. The action and resource are front-loaded, and the second sentence provides useful domain context without padding.

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

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

For a simple read-only list endpoint, the description, schema, and annotations together are sufficient for an agent to invoke the tool correctly. Minor omissions like pagination behavior and return structure are not critical because the schema covers parameters and the operation is non-destructive.

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

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

Schema description coverage is 100%, so page, size, and team_id are already fully documented. The description adds no parameter-level meaning, but it does not need to because the schema carries the burden.

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 opens with 'List all iubenda sites,' which is a specific verb plus resource and clearly states scope. The second sentence clarifies what a site is, distinguishing this tool from sibling tools like list_pcp_services and list_site_pcp_services.

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

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

The description makes the intended use explicit: to list all sites. It does not explicitly mention alternatives or when not to use it, but the resource name and list verb provide clear context for selection among the sibling 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?

The description adds significant behavioral detail beyond annotations: it returns immediately with an empty envelope, the scan runs asynchronously taking 1–2 minutes, and iubenda emails the site owner when finished. This gives the agent a clear model of side effects and timing that annotations alone do not convey.

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 concise and front-loaded: purpose, immediate return behavior, timing, email notification, and follow-up workflow. Every sentence earns its place, including the user-facing instruction about waiting or checking back, which is essential for correct agent behavior.

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

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

For a single-parameter tool with no output schema, the description is complete. It explains the async nature, the empty envelope, the follow-up retrieval path, and how to manage user expectations. There are no critical gaps that would prevent an agent from invoking or handling the 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?

The input schema already documents site_id with 100% coverage, including that it accepts a numeric id or public id. The description mentions site_id in the get_scan follow-up but does not add new semantic meaning beyond the schema, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: 'Schedule a Radar compliance scan for an iubenda site.' It clearly distinguishes this from the sibling get_scan by explaining that start_scan initiates the scan while get_scan retrieves results, and it sets expectations for asynchronous execution.

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 provides explicit guidance on what to do after calling the tool: ask the user whether they want to wait for the email or check back, then use get_scan(site_id). It names get_scan as the follow-up alternative, though it does not explicitly state when NOT to use this tool or list alternative scan-related 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?

The annotations say the operation is not read-only, not idempotent, not destructive, but the description adds no behavioral context beyond the word 'Update'. It does not disclose whether the configuration is fully replaced or merged, what happens when remote_configuration is toggled, or any side effects.

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

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

The description is a single, clear, front-loaded sentence with no wasted words. It is appropriately compact for a simple update tool, though it sacrifices useful context for brevity.

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 one required parameter and two optional nested/boolean parameters, the description is too thin. It does not clarify what happens when configuration or remote_configuration is omitted, whether this tool creates a solution if none exists, or what the response looks like. Given no output schema, more contextual detail is needed.

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

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

Schema description coverage is 100%, so the schema already documents site_id, configuration, and remote_configuration. The tool description adds no additional parameter meaning; the external documentation link in the schema is helpful but not part of the description itself.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Update') and the resource ('Cookie Solution') scoped to a site. While it does not explicitly compare itself to create/delete/get_cookie_solution, the verb alone plus the unique resource name sufficiently differentiate it from sibling tools.

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

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

No guidance is given about when to use this tool versus create_cookie_solution, get_cookie_solution, or delete_cookie_solution. There is no mention of prerequisites, such as the site already having an existing Cookie Solution, nor any indication of when an update is appropriate.

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 indicate readOnlyHint=false, so the write nature is known. The description adds little beyond scope ('for a site') and does not disclose what is updated, whether the existing document is overwritten, what side effects occur, or any permission requirements. No contradiction with annotations.

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

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

The description is a single, front-loaded sentence with no filler words. It could be slightly more informative, and it partially repeats the title, but it is efficient and well-structured.

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 mutating tool with no output schema, the description is too thin. It does not explain what updating the policy entails, what fields are affected, or the operational context, leaving an agent with limited information 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 100%, with site_id and configuration/badge_style already described. The description adds no parameter-level meaning, so the baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('Update') and a specific resource ('Privacy & Cookie Policy document for a site'). This clearly distinguishes it from sibling tools like create_privacy_cookie_policy, delete_privacy_cookie_policy, and get_privacy_cookie_policy.

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 is given about when to use this tool versus alternatives. The verb 'Update' implies the policy already exists, but the description never tells the agent to prefer this over create/delete or mentions 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?

Annotations only confirm the operation is not read-only, not idempotent, and not destructive. The description adds no behavioral detail beyond 'update', such as whether omitted fields are preserved, side effects of setting owner details, or draft-policy finalization. For a mutation tool, this is a meaningful 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 description is a single front-loaded sentence with no filler or redundancy. It is appropriately concise, though it is arguably too terse to fully support the tool's complexity.

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 six parameters, nested objects, no output schema, and no behavioral annotations that clarify update semantics, a one-sentence description is incomplete. Important context like owner finalizing draft policies is buried in the parameter schema rather than surfaced in the tool description.

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

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

Schema description coverage is 100%, so the baseline is 3 even though the tool description contributes no parameter information. The schema already documents all six parameters, including the owner per-language array semantics and business_details.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('Update') on a specific resource ('existing iubenda site'). This clearly distinguishes it from sibling tools like create_site, delete_site, and get_site.

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 word 'existing' implies this tool is for sites already created, not for new site creation, but it does not explicitly name alternatives or provide when/when-not guidance. This is implied usage rather than explicit 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 establish that this is a non-read-only, non-idempotent, non-destructive mutation. The description adds that the service must already be site-attached and identified by its primary key, but it does not disclose whether omitted optional fields are preserved or cleared, nor any side effects 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?

The description is a single front-loaded sentence followed by one targeted usage note. Every word earns its place, and the most important scoping information appears first.

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

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

The schema documents parameters and annotations cover the basic safety profile, but the description leaves update semantics ambiguous: it is unclear whether omitted array fields are replaced wholesale or merged. Without an output schema, success/error behavior is also not communicated.

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

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

Schema description coverage is 100%, so all four parameters are already documented. The description repeats the primary-key origin already present in the schema for id, adding little semantic value beyond what the schema provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action and resource: 'Update a PCP service added to a site.' This targets a specific existing relation rather than a global service or site-level setting, distinguishing it from siblings like update_site, create_site_pcp_service, and delete_site_pcp_service.

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

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

The description gives a clear prerequisite: use the primary key returned by list_site_pcp_services or create_site_pcp_service. This tells the agent where to get the required id, but it does not explicitly contrast with create/delete or state when not to use this tool.

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?

The description does not disclose side effects, idempotency, partial vs. full replacement semantics, or any validation behavior. Annotations provide no behavioral hints beyond non-read-only, non-destructive, non-idempotent stances.

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 concise and free of extraneous content. It uses a single clear sentence.

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

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

The tool is simple, and the schema provides basic parameter names, but important context is missing, such as whether the configuration replaces the entire document or just updates certain fields, and what the expected response is.

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?

All parameters have descriptions, but they are minimal. 'site_id' is just 'Site ID' and 'badge_style' is 'Badge visual style' without explaining allowed values or their meaning. The configuration object's intended structure is only partially 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?

Description clearly states the action ('Update') and the resource ('Terms & Conditions document for a site'), distinguishing it from sibling create/delete/get operations.

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 is provided on when to use this tool versus alternatives, such as create_terms_conditions or update_site. The verb 'update' implies modification of an existing resource, but explicit when/when-not conditions are absent.

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