Consentio cookie consent

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

Annotations declare openWorldHint and idempotent, and the description adds useful context: it performs a live page fetch, discloses the auth requirement (API key, Free keys accepted), and explains how the determination is made. Given readOnlyHint=false, it would help to clarify that this is not a mutation, but the description adds real behavioral value beyond 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 compact sentences that front-load the action and follow with the auth prerequisite. No filler, though the parenthesis structure is slightly cramped.

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 check with no output schema, the definition covers mechanism and auth prerequisites adequately. It doesn't explain what a 'not installed' result indicates or error behavior on fetch failure, which a richer definition would include.

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

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

Schema coverage is 100% and the siteId description already says it comes from list_sites. The description adds no parameter 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?

States a specific verb and resource: re-check whether the Consentio snippet is installed on a site, with the mechanism (fetches the page, matches the site key). This is clearly distinguishable from siblings like get_install_snippet (returns the snippet) and scan_cookies.

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 're-checks' implies this is for verifying after install rather than first-time retrieval, hinting at when to use it, but alternatives such as get_site_health are never mentioned. Usage context is implied rather than explicit.

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 already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds that this is an informational overview usable before an account exists, but it does not describe what the overview returns or any limits. That is useful context, but not rich behavioral disclosure.

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

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

Two tight sentences with no wasted wording. The content summary comes first, and the routing instruction is clearly front-loaded.

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 zero-parameter informational tool with annotations and no output schema, the description supplies the purpose and the key routing condition. It could say slightly more about what the overview covers or what the agent should do after calling it, but it is sufficient 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 tool has zero parameters, so the baseline is 4. The description correctly adds no parameter detail because none is needed.

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

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

It names a specific resource (Consentio overview) and its scope (plans and getting started), which distinguishes it from action tools like create_site or scan_cookies. It is informational rather than verb-first, but the purpose is clear enough for selection.

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 an explicit trigger: call this first when the user wants a cookie banner, GDPR consent, or Google Consent Mode v2 and has no Consentio account. It also implies an exclusion for users who already have an account, though it does not name which sibling to use in that case.

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

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

Beyond the annotations (which already declare a non-read-only, non-destructive, non-idempotent write), the description adds real context: the return payload, the plan-based quota ceiling, and the auth requirement with the caveat that Free keys suffice. It stops short of saying what happens when the limit is exceeded (error vs. silent failure) or noting that retries create duplicates.

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 with zero filler: the action and outputs come first, then the quota constraint, then the auth requirement. Each sentence carries distinct, actionable information.

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

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

With no output schema, the description correctly compensates by naming the returned site key and install snippet, and it covers quota and auth for a mutation tool. The main remaining gap is failure behavior when the plan limit is hit or the domain is already taken.

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%, with both name (max 60 chars) and domain documented in the schema itself, so the baseline is 3. The description adds no further meaning about the parameters, such as domain format constraints or whether the domain must be unverified/unique.

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

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

States a specific verb and resource ("Creates a site in the user's account") and names the concrete outputs (site key and install snippet), so it is clearly distinguishable from read-only siblings like list_sites and check_install. It does not, however, explicitly address the overlap with get_install_snippet, which also deals with the snippet.

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 "Creates" and constrained by "Respects the plan's site limit (Free: 1 site)", which tells the agent when the call will be rejected. There is no explicit when-to-use versus alternatives guidance (e.g. use get_install_snippet to re-fetch the snippet later rather than re-creating).

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 openWorldHint=false, but the description adds a genuinely useful behavioral fact: no API key is needed, which tells an agent this can be called before authentication is configured. It also discloses the return payload (snippet plus guide URL) even though no output schema exists. It stops short of noting whether the snippet is stable or changes over time.

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 tight sentence that front-loads the primary return value, then appends the secondary value and the auth note. No redundant restatement of the tool name and no filler.

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

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

For a simple two-parameter read-only getter with no output schema, the description covers what it returns, what it needs, and its auth posture, which is nearly everything an agent needs. The remaining gap is placement in the install workflow relative to check_install.

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 both siteKey and platform fully. The description only restates that the output is keyed on a site key and platform, adding no format, validation, or fallback detail beyond the schema. Baseline 3 is appropriate.

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

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

States a specific verb and resource: returns the exact <script> install snippet for the Consentio cookie banner and the platform install guide URL. The scope is narrow and concrete enough that an agent can distinguish it from siblings like check_install or consentio_overview without opening any 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?

Usage is only implied: an agent can infer this is the first step of installation, but the description never says when to call it versus check_install (which presumably verifies installation) or consentio_overview. No explicit exclusions or prerequisites beyond the site key requirement.

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 openWorldHint=false, so safety is covered. The description usefully adds the API-key requirement and free-tier note, but says nothing about freshness of the health data, caching, or failure behavior when a site is unreachable.

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 compact sentences with the returned values front-loaded and the auth caveat second. No filler, though the first sentence's fragmentary grammar costs a little clarity.

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 tool with no output schema, naming the returned fields (health level, score, uptime) and the auth requirement covers what an agent needs to call it. Remaining gaps are minor.

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 required parameter with 100% schema coverage, and the schema already explains that siteId comes from list_sites. The description adds no further meaning such as format or scope, 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 resource (a site) and enumerates what is retrieved — health level, score and uptime — which is enough to distinguish it from siblings like list_sites or check_install. It stops short of an explicit verb (e.g. 'Get the health...'), so it reads as a noun fragment rather than a full statement of action.

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

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

The only usage condition given is the authentication prerequisite ('Requires an API key (Free keys work)'). There is no guidance on when to prefer this over check_install or how it relates to list_sites (which supplies the siteId), so usage is implied rather than directed.

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 (readOnlyHint=true, openWorldHint=false), and the description adds real value by disclosing the sandbox/test exclusion and the API-key tier requirement. It does not define what 'recent' means (time window or ordering) or how many records the default page covers, so behavioral disclosure remains partial.

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

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

A single tight sentence with the scope qualifier front-loaded and the access restriction trailing. No filler, though 'recent' is left undefined, which slightly undercuts the concision's usefulness.

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

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

For a two-parameter read tool with no output schema, the definition is minimally adequate but leaves the agent guessing about the 'recent' window, result ordering, and what fields a consent record contains. Given the absence of an output schema, a little more detail about the return shape would help.

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 only 50%: 'limit' is documented in the schema but 'siteId' is not. The phrase 'of a site' implicitly assigns meaning to siteId, but the description never addresses the 'limit' parameter or its default of 20, so it does not compensate for the coverage gap.

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

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

States a specific resource ('consent records of a site') and scope qualifiers: 'recent' and sandbox/test consents excluded. The verb 'list' is carried by the tool name; it is clear what is returned and the exclusion sharpens it beyond a generic list.

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

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

The prerequisite 'Requires a Pro or Agency API key' is useful gating information, and 'recent' implies a bounded query rather than a full dump. However, there is no explicit when-to-use vs. when-not guidance, nor any reference to a sibling such as consentio_overview for aggregated consent 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 readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds genuinely new behavioral context: the auth requirement (API key, free keys accepted) and the fact that each returned site carries install status and health, which tells the agent what the response contains even without an output schema.

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

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

Two sentences and no waste: the core action and payload are front-loaded, followed by the single prerequisite an agent needs before calling. Nothing could be removed without losing information.

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

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

For a zero-parameter, read-only listing tool with no output schema, the definition covers the action, contents of the result, and the auth requirement. Minor gaps remain around ordering, pagination, or behavior for accounts with no sites, but these are low-stakes for this tool's simplicity.

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 and the schema is trivially complete. Baseline 4 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 gives a specific verb and resource ('Lists the user's Consentio sites') and states the scope of the payload (install status and health). It does not explicitly distinguish itself from overlapping siblings like get_site_health or check_install, so an agent must infer this is the bulk-listing variant rather than a single-site lookup.

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

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

The only usage-relevant information is the prerequisite 'Requires an API key (Free keys work)', which tells the agent about auth and that free-tier keys suffice. There is no when/when-not guidance and no routing advice against check_install or get_site_health, so the choice among siblings is left to inference.

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

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

Annotations already declare readOnlyHint and openWorldHint, and the description adds real operational context beyond them: no authentication required and per-IP rate limiting. It stops short of describing throttling thresholds or what the scan returns, but the added facts are genuinely useful.

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 what the tool does and followed by the two operational facts an agent needs. No filler and nothing 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 read-only scan the definition is mostly sufficient, but with no output schema the description never indicates what comes back (cookie names, tracker vendors, consent categories) or how large a response to expect. That is the main remaining gap.

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

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

Schema coverage is 100% for the single 'domain' parameter, so the schema already carries the burden. The description's phrase 'public website' reinforces the constraint that the domain must be publicly reachable, but adds little beyond the schema's own 'Public domain' description.

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

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

The description states a specific verb and resource ('Scans a public website for trackers and cookies') and even enumerates the categories detected (analytics, marketing, preferences). It is clearly distinct from siblings like list_consents or get_site_health, though it never names an alternative explicitly.

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

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

It provides practical context ('Does not need an API key', 'Rate limited per IP') that helps an agent decide it can call this freely, but there is no explicit when-to-use versus when-not guidance relative to the sibling tools such as list_consents.

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