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

Annotations already mark it as read-only and non-destructive, but the description adds real behavioral context: it works with any valid API key, consumes no audit quota, and returns specific fields including raw status, period end, cancel flag, and upgrade URL. This goes well beyond what the annotations provide.

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 core purpose, followed by clear usage triggers and a concise enumeration of returned data. Every sentence contributes meaning without padding or repetition.

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

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

With no output schema, the description fully compensates by listing the returned tier, raw status, period end, cancel setting, upgrade URL, and plain-language summary. It also covers quota impact and key validity, making it complete for a zero-parameter read-only tool.

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

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

There are no parameters, and the schema is empty, so there is no semantic burden to carry. The description reinforces that the tool operates on the caller's own subscription, which is sufficient given the absence of inputs.

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: 'Check the caller's own Website Auditor subscription standing.' It clearly identifies the tool's scope and distinguishes it from sibling tools like get_monitoring_status or get_report, which deal with other aspects of the product.

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

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

It explicitly lists concrete scenarios: 'am I on Pro,' 'is my trial still active,' 'when does my subscription renew/end,' 'why is this tool locked,' and before suggesting an upgrade. It does not mention alternatives or exclusions, 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 and destructiveHint false, but the description adds substantial beyond-annotation behavior: each uncached competitor consumes one audit against the daily quota, quota shortfall leads to a ranked subset plus a skipped list, over-quota returns an error with reset time, and it never silently drops competitors or invents scores. This is exactly the kind of context an agent needs.

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 long but every sentence earns its place: purpose, use-case triggers, return behavior, quota mechanics, over-quota error, subscription requirement, and fallback alternative. It is front-loaded with the core purpose and keeps critical decision-making information up front.

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 compensates by specifying what the tool returns: each competitor's score, where they appear that the site does not, a quota summary, a skipped list, and an over-quota error with reset time. It also covers the subscription prerequisite and the recommended fallback action, making the tool fully callable by an agent.

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

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

Schema coverage is 100%, so the schema already documents domain and competitors. The description adds meaningful semantics beyond that by explaining that each competitor not already cached costs one audit and that a quota shortfall changes which competitors are evaluated. This helps the agent set expectations and explain outcomes to the user.

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: 'Compare a website's AI visibility head-to-head against named competitors.' It then gives concrete example queries ('how do I stack up against X and Y'), making exactly when to use it unambiguous and distinguishing it from sibling tools like get_recommendations or run_audit.

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

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

It explicitly states 'Use this when' followed by three concrete user-phrasing triggers. It also tells the agent when not to proceed: if the user lacks a Website Auditor subscription, call get_sample_audit instead, naming the alternative and the condition for choosing it.

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 readOnly/openWorld/non-destructive behavior, so the description correctly avoids repeating that. It adds substantial beyond-schema context: a subscription requirement, trial terms, the promise of valid JSON-LD output, and a fallback tool. This meaningfully helps the agent manage user expectations.

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 front-loaded with the core action, then efficiently lists trigger phrases, the output guarantee, and the subscription/trial caveat. Although long, every clause earns its place because the paywall detail directly affects invocation decisions.

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 tool with full schema coverage and strong annotations, this description is complete. It covers when to use it, what it returns, access requirements, and the non-subscriber fallback. No output schema exists, but 'Returns valid JSON-LD' is sufficient for the tool's simple return type.

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 describes both parameters fully (domain example, type enum with auto-detect), giving 100% schema description coverage. The description adds only the general idea that output is tailored to the website, so it does not significantly advance parameter understanding beyond the schema baseline.

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 ('Generate'), a concrete deliverable ('ready-to-paste structured data (JSON-LD schema)'), and the intended effect on AI and search-engine understanding. It also gives clear trigger phrases, which helps an agent distinguish this tool from siblings like get_sample_audit.

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

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

It explicitly defines when to use the tool: when the user asks for 'schema,' 'structured data,' 'JSON-LD,' or wants the actual markup. It also names a condition and an alternative: if the user lacks a subscription, call get_sample_audit first. This is exact routing guidance.

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

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

With annotations already covering the read-only/open-world safety profile, the description adds substantial behavioral context beyond them: the subscription requirement and free-trial terms, the distinction between `sources: null` and an absent `sources` key, the instruction to treat `competitor` rows as context rather than placement targets, and the `name_warning` caveat to relay rather than present as settled fact. It also discloses that trend data is computed from stored snapshot history.

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 front-loaded with purpose and trigger queries before details, and every sentence carries distinct information — nothing is redundant. It is long (roughly 280 words), but the density is justified given the subscription requirement, return-value semantics, and caveat handling it must convey that no output schema exists to cover.

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 bears the full burden of explaining return values, and it does: score range, per-engine breakdown, top competitor, `sources` semantics including null vs absent, trend data, and the `name_warning` case. It also covers the access prerequisite (subscription/trial) and the fallback sibling tool, leaving nothing an agent needs to invoke it correctly unstated.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaning beyond the schema for the optional parameters: it warns that "a guessed name is scored as if confirmed, so supply one only when it is actually known," and explains the detection-fallback behavior for `business_location` (widening to country or dropping place, "right for a national or global business and wrong for a local one"). This goes beyond the schema's plain 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 opening line, "Check how visible a website is to AI assistants right now," pairs a specific verb with a precise resource and temporal scope, going well beyond the title. It further delimits the purpose by enumerating the exact user queries that trigger this tool ("does ChatGPT/Perplexity/Claude/Gemini recommend this business") and lists the concrete outputs (0–100 score, per-engine breakdown, top competitor), leaving no ambiguity about what it 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 explicitly says "Use this whenever someone asks..." followed by five concrete query patterns, giving unmistakable when-to-use guidance. It also provides an explicit conditional alternative: if the user lacks a subscription, "call get_sample_audit first to show them the exact output format, free and with no API key," which is as clear a routing rule as the calibration 5 example.

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 destructiveHint, so the safety profile is covered. The description goes further by disclosing the subscription requirement, the trial terms, and the aggregated-data basis, which are behavioral traits not present in annotations. It also clarifies the fallback path, adding real value beyond structured metadata.

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, front-loaded with purpose and usage, then the subscription detail is appended. It's somewhat long but each part earns its place, explaining prerequisites and a routing action. Slight verbosity in the trial terms but acceptable.

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

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

Given the low complexity (3 params, no output schema), the description covers purpose, usage, prerequisite, and alternatives. It does not detail the output format, but it points to get_sample_audit for exactly that, and the annotations carry the safety context. Minor gap: it doesn't clarify default behavior when geo/industry are omitted, but the schema implies they are optional overrides.

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 does not add extra meaning to parameters beyond the schema, though it mentions industry and location in the purpose. No significant gap, but no added value either.

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

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

The description states a clear verb and resource: 'Benchmark a website's AI visibility against its industry and location.' It differentiates from siblings by explicitly contrasting with absolute numbers and mentioning the use case for percentile/peer context, and it names get_sample_audit as an alternative for non-subscribers.

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 triggers ('how do I compare to others in my space,' 'is this a good score for my industry') and a clear when-not case ('rather than an absolute number'). It also prescribes a fallback action (call get_sample_audit) when the user lacks a subscription, providing unambiguous routing among siblings.

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

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

Annotations already flag readOnlyHint and destructiveHint, and the description adds meaningful behavioral context: the domain must be tracked, a paid Website Auditor subscription is required, and the return includes specific deltas like score movement and engines gained/lost. It also discloses trial terms and payment requirement, which is useful for setting user expectations. It stops short of discussing rate limits or error behavior, but those are not major omissions for this read-only tool.

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

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

The description is longer than average, but the length is earned: it covers use cases, prerequisites, return contents, and subscription/fallback details. The core purpose is front-loaded in the first sentence, and the additional detail is actionable. It is slightly verbose around the subscription trial explanation, but not distractingly so.

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

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

For a read-only, two-parameter tool with no output schema, the description is complete: it states what the tool returns, what preconditions exist (tracked domain, subscription), and what fallback to use when the user does not have the paid plan. There are no significant gaps that would prevent an agent from invoking it correctly.

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

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

Schema description coverage is 100%, so the schema already documents 'domain' and 'since' (including the 'last_check' option). The description indirectly clarifies 'since' by saying 'since it was last checked' and referencing week/month, but it does not add meaningful parameter-level details beyond the schema. This aligns with the baseline 3 for fully covered schemas.

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, actionable statement: 'Report what changed in a website's AI visibility and audit since it was last checked.' It then lists concrete user phrasings ('did anything change,' 'what's different this week/month'), which makes the tool's purpose unmistakable and distinguishes it from sibling tools like get_ai_visibility or get_sample_audit.

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 when-to-use guidance through example queries, states the prerequisite that the domain must be tracked and points to track_site, and gives a clear alternative path: call get_sample_audit first if the user lacks a subscription. This is strong routing behavior that helps an agent choose correctly.

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?

Goes well beyond the readOnly/openWorld annotations by explaining how the plan is grounded in `sources` marked yours/competitor/third_party, that competitor sources are never placement targets, and the fallback to report issues/stats when no citations exist. Also discloses subscription requirements and free-trial details, which materially affect whether the agent should call get_sample_audit.

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 front-loaded with the core purpose, then organizes trigger phrases, behavioral grounding, parameters, and subscription constraint into distinct clauses. Although longer than minimal examples, every sentence carries load-bearing information; the subscription/trial detail is critical for correct agent routing.

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 grounding, fallback, parameters, and subscription, but never states the precondition that an audit must already exist for the domain. It does not tell the agent to call run_audit first if no audit is present, which is a notable gap given the audit-dependent nature of the tool and the absence of an output schema.

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

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

Schema coverage is 100%, but the description adds meaning by explaining that `focus` and `constraints` steer the plan and that `prior_plan` holds markdown from an earlier call to refine rather than restart. This meaningfully supplements the schema's terse property 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?

States a specific action ('Build a written go-to-market plan') on a specific resource (the website's latest audit), grounded in citation evidence. Trigger phrases like 'turn this audit into a plan' and the mention of get_sample_audit clearly 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?

Provides explicit when-to-use trigger phrases ('what should I do about my AI visibility,' 'turn this audit into a plan') and a conditional alternative: if the user lacks a subscription, call get_sample_audit first. It also names the subscription prerequisite. It does not explicitly contrast with get_recommendations, which could be triggered by similar phrasing, so a small routing gap remains.

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 readOnlyHint and destructiveHint annotations, the description discloses an important behavioral condition: a Website Auditor subscription is required, including trial details and payment requirements. It also explains the fallback behavior to get_sample_audit for non-subscribers, which annotations could 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 front-loaded with the core action, then gives usage examples, return contents, and subscription caveats in a logical order. Every sentence adds necessary information for selecting and invoking the tool correctly; there is 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 tool with no parameters and no output schema, the description is fully self-sufficient: it explains what it does, when to use it, what it returns, and what prerequisites or alternatives apply. The agent has enough information to call it correctly or route to get_sample_audit when 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?

The tool has zero parameters and 100% schema description coverage, so there is nothing for the description to compensate for. The description still clarifies the implicit scope—'across all tracked websites'—which is useful 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 opens with a specific verb and resource: 'Get a glanceable summary of monitoring status across all tracked websites.' It clearly separates this from siblings like get_ai_visibility or get_changes by emphasizing the across-all-domains dashboard nature, listing return fields per domain.

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

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

The description explicitly says 'Use this when someone asks...' and gives concrete query examples. It also provides an alternative path: if the user lacks a subscription, call get_sample_audit first. This gives the agent clear routing logic.

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 provide readOnlyHint=true and destructiveHint=false, so the description correctly reinforces a non-destructive profile without contradiction. It adds substantial beyond-annotation behavior: the paid subscription requirement, free trial terms, payment method requirement, and instruction to fall back to get_sample_audit. It also discloses the return shape ('ranked actions with expected impact').

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 front-loaded with the core purpose and usage triggers, then moves into subscription details and fallback routing. It is somewhat long due to pricing and trial terms, but every sentence serves a functional purpose—no filler. It earns a strong score, though tightening the subscription wording could make it even more concise.

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

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

For a read-only tool with one parameter and no output schema, this description covers everything an agent needs: what it does, when to use it, what it returns, the subscription prerequisite, and the alternative path for users without access. Nothing essential 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?

Schema description coverage is 100% for the single 'domain' parameter, which is already well-documented. The description does not add further parameter-level detail, but with full schema coverage 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 uses a specific verb and resource: 'Get specific, prioritized fixes to raise a website's AI visibility and audit scores.' It clearly distinguishes the tool from siblings by emphasizing 'prioritized fixes' and 'ranked actions with expected impact,' and explicitly names get_sample_audit as a different, free alternative. This leaves no ambiguity about what the tool 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 gives explicit when-to-use triggers: 'when someone asks...' or 'after an audit surfaces issues.' It also provides a when-not-to-use and alternative: 'if the user doesn't have one, call get_sample_audit first.' This is exemplary usage guidance with a clear conditional route to a sibling 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?

Annotations already indicate readOnlyHint=true and destructiveHint=false, but the description adds substantial context beyond that: the tool requires a paid subscription, explains the free-trial condition, and describes the return payload (link + HTML snippet). This goes well beyond what annotations alone provide.

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 bit long but each sentence delivers essential information: core purpose, usage signals, and subscription fallback. The most important information is front-loaded, and the pricing detail is relevant context packed compactly.

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 a single parameter and no output schema, the description adequately covers return values (a link and HTML badge snippet), prerequisites (subscription), and fallback guidance. An agent has all necessary information to decide when to call it and what to expect.

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%, and the only parameter 'domain' is already documented in the schema with an example. The tool description adds no additional parameter-level detail, 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?

States a specific verb and resource: 'Get a shareable report URL and the embeddable badge snippet.' It clearly differentiates from siblings by naming the use case ('share,' 'export,' 'send a client,' 'embed') and even points to get_sample_audit as the alternative for non-subscribers.

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

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

Explicitly states when to use this tool ('Use this when someone wants to share/export/send/embed') and when not to ('if the user doesn't have one, call get_sample_audit first'). The subscription prerequisite and fallback behavior are spelled out directly.

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

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

Annotations already mark readOnlyHint=true and openWorldHint=false, but the description goes further by explaining the data is fixed, clearly marked as a sample, and always describes example.com. This adds meaningful behavioral context beyond the annotations without contradicting 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?

Each sentence earns its place: purpose, usage triggers, output shape, then the important caveat about sample vs real audits. It is slightly long but information-dense and logically ordered, with no redundant phrases.

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 demo tool with no output schema, the description fully explains the return shape (scored summary, per-test results, AI-visibility breakdown) and the boundary conditions. The sibling list provides the real-audit alternative, so nothing an agent needs to invoke it 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 tool has zero parameters, so the baseline is 4. The description appropriately communicates that no API key or setup is required, which is the only relevant 'parameter-like' context. There are no parameter details needed because the schema is empty.

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 the exact action and resource: 'Show a complete sample Website Auditor report.' It distinguishes itself from siblings by clarifying it returns static data for example.com and never a user's own site, so an agent can tell it apart from run_audit and similar 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?

Explicitly lists trigger intents ('try it,' 'see a demo,' 'show me what this does') and directs agents to use it INSTEAD of refusing when no API key is configured. It also states the alternative condition — auditing a real domain needs a subscription — giving clear when-to-use and when-not-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?

Annotations already mark this as read-only and non-destructive, and the description adds meaningful behavior beyond that: it discloses the subscription requirement, the exact returned data (domain, cadence, active state, slots used/remaining), and the fallback path when the user is not subscribed. This is exactly the kind of non-obvious context an agent needs.

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 front-loaded with the core purpose and use cases, then output, then subscription routing. The subscription explanation is a bit long with pricing and trial details, but it is relevant for deciding whether to call this tool or get_sample_audit. No filler is present, though it could be tightened slightly.

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 appropriately explains what the tool returns: each tracked domain with cadence and active state, plus slot counts out of 5. It also covers the subscription prerequisite and the fallback for non-subscribers. For a zero-parameter list tool, this is complete enough for an agent to invoke it correctly.

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

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

The tool has zero parameters and the schema coverage is 100%, so there is nothing for the description to add about parameter meaning. Per the baseline for a no-parameter tool, a 4 is appropriate; the description uses that freedom to explain output and access rather than parameter 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 opens with a specific verb and resource: 'List the websites currently being monitored for AI visibility on a schedule.' It also gives concrete user phrasings that should trigger this tool, making the purpose unmistakable. It clearly differentiates this list operation from other monitoring-related siblings by naming the exact output scope.

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

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

The description explicitly states when to use the tool with natural-language examples like 'what am I tracking' and 'how many monitoring slots am I using.' It also provides a conditional alternative: if the user lacks a Website Auditor subscription, call get_sample_audit first. This is clear routing guidance with no ambiguity.

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 readOnlyHint and destructiveHint annotations, the description discloses several important behaviors: the audit is one-time, returns a scored summary and report link, requires a paid subscription with trial terms, may return a name_warning that must be relayed as a caveat, and warns that an unverified business name is scored as if confirmed. This is rich behavioral context an agent needs to handle the result responsibly.

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 long but every sentence carries operational value: scope, trigger conditions, output summary, sibling-tool distinction, caveat handling, and subscription gate. It is front-loaded with the core purpose and then layers necessary detail without redundancy.

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

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

Despite having no output schema, the description explains what the tool returns (scored summary, report link, possible name_warning) and covers subscription requirements, fallback behavior, and free-alternative routing. For a tool with optional parameters and real-world caveats, this is complete enough for an agent to call it correctly.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds critical semantic warnings: business_name should only be supplied when actually known because a guessed name is scored as confirmed, and business_location omission triggers detection with fallback behavior. This meaningfully improves correct parameter use 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 states a specific verb and resource ('Run a full one-time audit of a website') and enumerates what the audit covers: AI visibility, SEO, security headers, broken links, and performance. It also explicitly distinguishes itself from get_ai_visibility, eliminating ambiguity about which tool returns the cited sources evidence.

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 explicit trigger phrases ('audit,' 'scan,' 'check,' 'review'), clarifies the complete-report use case, and tells the agent exactly when to use get_sample_audit instead (no subscription). This is model guidance for tool selection.

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

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

Annotations only declare readOnlyHint=false and destructiveHint=false; the description adds that this is a scheduled/ongoing operation, that it creates the history get_changes reads, and that it requires a paid subscription with trial details. It also handles the fallback behavior for non-subscribers. It does not spell out whether stopping is reversible or what happens to existing history, but the key consequences are 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?

All four sentences carry distinct information: function, trigger phrases, downstream dependency, and subscription gate with fallback. It is a bit dense, especially the parenthetical trial/payment clause, but it is still efficient relative to the complexity. Front-loaded with the core start/stop behavior before commercial details.

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 3-parameter tool with no output schema, the description covers the main requirements: correct triggering, subscription prerequisite, fallback to get_sample_audit, and the relationship to get_changes. It doesn't describe return values or edge cases like duplicate domains, but those are not strongly needed given the schema and annotations. The description is sufficient for an agent to select and invoke 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%: domain, cadence, and enabled all have descriptions, defaults, and enum constraints in the schema. The description only reinforces the cadence indirectly with 'on a schedule' and the enabled=false stopping behavior is already in the schema. Since the schema does the heavy lifting, this is a baseline 3.

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 'Start (or stop) ongoing monitoring of a website's AI visibility on a schedule,' which names a specific verb and resource. It explicitly contrasts with a 'one-off check' and names get_changes as a downstream consumer, distinguishing it from siblings like run_audit and get_changes. This is far more specific than the title alone.

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

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

It gives explicit trigger phrases ('monitor,' 'track,' 'watch,' 'get alerted about') and excludes one-off checks. It also provides a conditional alternative: if the user lacks a Website Auditor subscription, call get_sample_audit first. This is clear when-to-use and alternative 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?

Goes well beyond the destructiveHint annotation by disclosing idempotency ('safe to call even if the site isn't currently tracked'), the return value ('how many monitoring slots are now free'), and a subscription prerequisite with a clear fallback. 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?

Every sentence earns its place: purpose, usage triggers, idempotency, return value, and subscription gating with routing. It is longer than average but dense and front-loaded, with no filler.

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

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

With one well-documented parameter, destructive annotations, and no output schema, the description covers everything an agent needs to call it correctly: behavior, result, idempotency, and the non-subscriber edge case. The get_sample_audit routing closes the main uncertainty.

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 fully documents the single required domain parameter, so the description adds little parameter-level detail. The surrounding context clarifies that the domain is a monitored site, but this is baseline value given 100% schema coverage.

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: 'Stop ongoing monitoring of a website's AI visibility.' It also positions the tool as the inverse of tracking via trigger phrases like 'stop tracking' and 'unmonitor,' and distinguishes it from monitoring/list/report tools by framing it as removal and slot freeing.

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?

Provides explicit when-to-use guidance with quoted user intents and the slot-freeing goal, and routes non-subscribers to get_sample_audit first. It does not explicitly state when not to use it, such as when the user wants to start tracking a new site, though that is inferable from sibling tools.

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