CookieInspector

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds value beyond that with 'No network call' (confirming a local, deterministic lookup consistent with openWorldHint=false) and the scope boundary 'Technical findings, not legal advice', which manages expectations about 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?

Three short sentences, front-loaded with the primary purpose and examples, with the 'no network call' and 'not legal advice' caveats placed last. Every sentence carries distinct information and none is 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?

For a single-parameter, no-network lookup tool with no output schema, the description covers both accepted input modes, the behavioral constraint, and the advice-vs-fact scope. There is no meaningful gap an agent would need filled before 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?

There is a single parameter with 100% schema description coverage, so the baseline is 3. The description's examples ('THIRD_PARTY_PRE_CONSENT', 'Cookiebot') reinforce the polymorphic input, but they convey essentially the same meaning the schema already documents (finding code or platform name), adding no syntax, format, or case-sensitivity detail.

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 (Explain) and two concrete resources (a CookieInspector finding code, a named consent platform), each with a real example ('THIRD_PARTY_PRE_CONSENT', 'Cookiebot'). This is clearly distinct from the scan-oriented siblings (start_scan, get_scan_findings, prescan_site), so an agent can route without 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?

Gives clear usage context: use it to decode a report finding code or to learn what to check in a given consent platform, and 'No network call' signals it is a static lookup rather than a live scan. It never explicitly names an alternative (e.g. get_scan_findings) or states when not to use it, 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so safety is covered. The description adds genuinely new behavioral context beyond them: which tools need a CookieInspector API key, that quotas are surfaced, and a scope disclaimer ('technical findings, not legal advice'). It stops short of describing the response shape or how quotas are expressed, but that is a minor gap given 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?

Three sentences, all front-loaded and purposeful: what it covers, when to call it, and the legal-advice disclaimer. The first sentence is dense with a long parenthetical enumeration, which is informative but slightly heavy for a single line.

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 no parameters, the description carries the full burden and discharges it: it previews the returned content categories, the account/quota information the caller will learn, and the limits of the advice. Nothing an agent needs before calling this orienting tool 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 tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a no-argument tool applies. No misleading parameter hints are 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?

States a specific verb ('Describe') and enumerates the concrete resource content: cookies and trackers before/after the consent click, banner behaviour, consent platform, Google Consent Mode. It also establishes its role as the meta/discovery tool in a family of scan-oriented siblings, so an agent can distinguish it from get_scan_findings or list_scans without opening a schema.

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

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

'Call this first when unsure which tool to use' is an explicit routing rule that tells the agent exactly when this tool beats the alternatives. Combined with the stated coverage of account requirements and quotas, the agent knows this is the entry point for orientation rather than for retrieving actual scan data.

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

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

Annotations already declare readOnly/idempotent/non-destructive. The description adds real value beyond them: the scan is header-and-HTML only, single page, and the output is deliberately limited (up to five trackers, three findings). It also flags 'technical findings, not legal advice,' which shapes how results should be presented.

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, and the field enumeration earns its length because there is no output schema. The density is high but every clause carries information; only the field list borders on over-enumeration.

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 must convey the return shape, and it does so comprehensively: score scale, risk level, cookie/tracker counts, consent platform, Consent Mode, findings, report link. Prerequisite and scope limits are also covered, leaving nothing essential 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?

Only one parameter, and the schema documents it at 100% coverage ('The preScanId returned by prescan_site'). The description reinforces the origin of the id but adds no syntax or format detail beyond the schema, so baseline 3 applies.

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

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

Specific verb ('Return the result') plus resource ('a pre-scan started with prescan_site'), and it enumerates the exact payload so the agent knows what comes back. It is clearly distinguishable from siblings like get_scan_status and get_scan_summary, which serve the full-scan flow.

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 establishes the prerequisite (must be a pre-scan started with prescan_site) and draws a boundary against the full scan, which 'requires a CookieInspector account.' It stops short of explicitly saying when to prefer this over the full-scan path in a selection rule, but the context 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 already establish read-only, idempotent, non-destructive semantics, so the description is not obligated to restate safety. It does add genuinely new behavioral facts: the response is capped at 25 items and each item carries severity, resource, and recommendation. The gap is that the 25-item cap is stated with no pagination or truncation guidance, leaving the agent unsure how to retrieve the remainder.

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 compact clauses with the payload description front-loaded, followed by the alternative-tool pointer and a short disclaimer. The opening phrase "The findings of a scan on the connected account" is slightly padded but carries no real 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, the description usefully enumerates the fields returned and the result cap, which is exactly the compensation needed. It stops short of stating ordering or how to page past 25 findings, the one thing an agent would still need to know for a complete picture.

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 a single parameter with 100% schema description coverage, and the schema already explains that scanId comes from start_scan or list_scans. The description adds nothing about the identifier's format or validity, 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?

Names the specific resource (findings of a scan) and the payload contents (severity, affected resource, recommendation), which is far more informative than the title alone. It does not explicitly distinguish itself from the close sibling get_scan_summary, so an agent must infer that this is the detailed row-level view versus an aggregate.

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 explain_finding for what a code means" is a clean, explicit routing rule to a named sibling, and the schema ties invocation to a scanId from start_scan or list_scans. It gives no exclusion against get_scan_summary or get_prescan_result, so the boundary in the findings-vs-summary pair is left implicit.

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 readOnly/idempotent/non-destructive, so the bar is lower; the description nonetheless adds real behavioral context beyond them: the four terminal/transient states, the direction of riskScore (0 best, 100 worst), and a scope disclaimer that output is technical findings rather than legal advice. It does not cover polling expectations, freshness, or errors for an unknown/expired scanId.

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

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

Two tight sentences, front-loaded with the resource and its state machine, then the return value semantics. Nothing repeats the title and nothing is 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?

With no output schema, the description correctly carries the burden of describing what comes back (status values plus riskScore), which is the essential payload. It stops short of describing other likely fields or error behavior, but for a single-parameter read tool it is largely 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?

Only one parameter and schema description coverage is 100%, so the schema already explains that scanId is 'returned by start_scan or list_scans'. The description adds no format, encoding, or validity detail beyond that, so the baseline 3 applies.

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

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

States a specific verb+resource ('Status of a scan') and goes further by enumerating the four possible lifecycle states and defining the riskScore scale. It implicitly separates itself from get_scan_summary/get_scan_findings, but never names those siblings, so an agent deciding between 'status' and 'summary' must infer the boundary.

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

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

There is no explicit when-to-use statement, no 'call after start_scan until status is completed' polling guidance, and no exclusions against get_scan_summary or list_scans. Usage is only implied by the enumerated states and by the schema note that scanId comes from start_scan/list_scans.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds value beyond them: it discloses the scale semantics of the risk score (0 best, 100 worst), the precondition that the scan must be completed, and a scope caveat ("technical findings, not legal advice").

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 front-loaded sentence plus a short caveat, with zero filler. The field list is dense but every item earns its place as return-content disclosure.

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

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

With no output schema, the description usefully enumerates the returned summary contents and the risk-score scale, and annotations cover safety. The remaining gap is what happens if the scan is not yet complete, which the agent must guess.

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 100% schema description coverage and a single scanId parameter already documented as coming from start_scan or list_scans, the schema does the heavy lifting. The description adds no format, sourcing, or error-handling detail about scanId, so the baseline 3 applies.

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

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

States a specific resource (scan summary) and enumerates exactly what it contains — risk score, verdict, banner/consent platform, cookie and tracker counts, top issues, report link. That content profile implicitly separates it from get_scan_findings (raw findings) and get_scan_status (progress), though no sibling is named outright.

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?

"A completed scan" is the only usage condition given; it implies the tool is for post-completion review but never says what to use while a scan is still running (get_scan_status) or where to go for full detail (get_scan_findings). 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?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), so the bar is lower; the description adds real value by disclosing the 20-item cap, newest-first ordering, and the riskScore scale with direction (0 best). It stops short of describing pagination or error 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?

Two short sentences, front-loaded with the core operation and results; very little waste. The trailing 'Technical findings, not legal advice' disclaimer is arguably tangential but does set expectations about 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?

With no output schema and a single optional parameter, the description carries the return-value burden well: it describes ordering, item count, and one key field with its scale. Minor gap is that the remaining per-scan fields and how to use a returned scan id are not mentioned.

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%: the limit parameter's range (1-20) and default (10) are fully documented in the schema. The description's 'up to 20' merely restates the schema's upper bound and adds no syntax or meaning beyond it, so the baseline 3 applies.

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

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

Names a specific verb+resource (list the most recent scans), scoped to 'the connected account', and adds ordering and result contents (riskScore 0-100, up to 20). This implicitly distinguishes it from per-scan siblings like get_scan_summary or get_scan_status, though it never names an 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 states what the tool returns but gives no when-to-use guidance, no exclusions, and never routes the agent to a sibling such as get_scan_findings or get_scan_status. Usage is only inferable from the word 'recent'.

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 annotations present but minimal (readOnlyHint=false, idempotentHint=false, destructiveHint=false), the description adds real behavioral context: the scan is anonymous, fetches only headers and HTML, and uses no real browser, so the agent knows it is a lightweight, non-mutating probe. It also discloses the output shape (preScanId plus report link), though it omits timing, rate limits, or auth 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?

The core capability and return value are front-loaded in the first sentence, which is exactly right. The trailing sentences about CookieInspector's positioning and the legal disclaimer are marginally useful but dilute a definition that could be tighter.

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 covers what it does, what it returns, and where to go next, which is sufficient to invoke it correctly. It stops short of explaining expected latency or failure modes, but nothing essential to calling the tool 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?

Only one parameter and schema coverage is 100%, so the schema already documents the url format with an example. The description adds scope meaning (it targets the home page, not arbitrary subpages) but nothing about URL normalization or accepted schemes beyond the schema's example.

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 ('Start a quick, anonymous pre-scan of a public website's home page') and scopes it precisely ('HTTP headers and HTML only, no real browser'). This clearly distinguishes it from the sibling start_scan, which implies a full browser-based scan.

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 follow-up routing by naming get_prescan_result and the preScanId handoff, which is useful workflow guidance. However, it never states when to choose this over start_scan, nor any precondition such as the site needing to be public and reachable, so selection guidance is only implied.

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 say readOnlyHint=false, idempotentHint=false, destructiveHint=false, which leaves quota and async behavior unexplained. The description fills that gap usefully by disclosing the monthly-scan quota consumption, the browser/consent-click behavior, the 5-page cap, and the returned scanId for polling. It does not state expected duration or whether a failed scan still consumes quota.

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 sentences, front-loaded with the action and scope, then constraints, then the follow-up workflow. Every clause earns its place; even the closing 'technical findings, not legal advice' line carries real meaning for a compliance 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, the description correctly supplies the return value (scanId) and the polling chain. Given a non-idempotent, quota-consuming async job, it is nearly complete; only runtime expectations and auth/permission requirements for 'the connected account' are 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?

Schema coverage is already 100%, so the baseline is 3, but the description genuinely adds meaning: 'main (US East)' and 'eu-de (Germany, for EU-targeted banners)' explain which region to choose and why. evaluateCcpa is left to the schema, which documents its default, so no gap is created.

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 ('Start'), resource ('full CookieInspector scan'), and binds the scope precisely: real browser, before and after the consent click, up to 5 pages, on the connected account. This distinguishes it from the sibling prescan_site by the word 'full' plus the page/consent detail, so an agent can route 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?

Clear context is given: it produces a scanId to poll with get_scan_status and then get_scan_summary, which routes the agent through the correct follow-up siblings. It also notes the tool consumes the plan's monthly scans. What is missing is an explicit when-not-to-use, e.g. when to prefer the lighter prescan_site instead.

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