Goppa

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

Annotations already declare readOnlyHint=false, idempotentHint=true, destructiveHint=false and openWorldHint=true; the description adds real value beyond that by explaining the side effect ('Goppa reads the site's home page'), the non-effect ('nothing on the site changes'), and a quota consequence ('counts toward the sites your account includes'). It does not mention what happens if the account's site limit is reached.

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 purpose and then side effects, all substantive. Minor redundancy between 'nothing on the site changes' and 'changes nothing' in the final sentence, but the quota note earns its place.

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

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

With an output schema present, return-value explanation is unnecessary, and the description covers the mutation's effects, its external read behavior, and idempotency. The remaining gap is failure/quota-exceeded behavior, which is not described.

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 adds no format guidance (no scheme/protocol rules, no subdomain or path handling) beyond the schema's 'like yourstore.com' 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?

The description opens with a specific verb+resource ('Add one of your websites to your Goppa account') and states the resulting benefit ('check, measure and track it'). It is unmistakably the only write/creation tool among a list of read-oriented siblings, so no disambiguation is needed.

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 clarifies the intent — registering a site so Goppa can monitor it — which is adequate context for choosing this tool. It also notes the idempotent case ('adding a site that is already in the account changes nothing'), but never states prerequisites, limits, or what to do if the site is already tracked instead.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds value by disclosing that scoping to a site also returns that site's measurement schedule, automatic check and keyword research (without it, the account as a whole and its sites). It says nothing about pagination behavior or result size despite the cursor parameter, which is a remaining gap.

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

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

A single sentence, front-loaded with 'Your Goppa account:', then a compact enumeration of returned fields. The parenthetical '(and in total, where the account has a total)' is slightly awkward but earns its place by clarifying a conditional return shape.

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?

An output schema exists, so return values needn't be spelled out, and both params are documented at 100% coverage with a full annotation set. For an optional-parameter read tool this is nearly complete; only pagination expectations are unaddressed in prose.

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

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

Schema description coverage is 100%, so both parameters (site and cursor) are fully documented in the schema itself. The description adds no syntax, defaults, or format detail beyond the schema, so the baseline 3 is appropriate.

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

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

The description names the resource (the Goppa account) and enumerates the concrete contents returned: plan, sites, AI measurement and keyword-research quotas, next scheduled measurement and next automatic site check. That is specific enough for an agent to know this is the account-overview read rather than a per-site analytics call. It does not explicitly contrast itself with siblings such as get_weekly_summary, which keeps it from a 5.

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

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

Usage is only implied: an agent can infer this is the starting point for account-level questions about quota, plan and scheduling. There is no explicit when-to-use/when-not guidance and no pointer to alternatives like get_site_audit or get_weekly_summary.

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 read-only, idempotent, non-destructive behavior, so the bar is lower. The description still adds value beyond them: answer text is third-party and marked untrusted (a safety trait the agent must respect), only the latest measurement is returned (no historical data), and pagination is fixed at 10 per page.

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?

Content is front-loaded with what is returned, then the trust caveat, then the page size — a sensible order. It is dense and slightly run-on in the field enumeration but every clause carries information; no filler sentences.

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 an output schema present, the description needn't document return structure, yet it still summarizes the payload, flags the untrusted-text property, and states the page size. The remaining gap is behavior when no measurement exists yet, which the agent would have to discover.

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 every parameter (site, cursor, engine) is fully documented in the schema itself, including the enum values and the multi-site fallback behavior. The description's only parameter-adjacent detail, '10 per page', largely restates what the cursor description already says ('next 10 items'), 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?

The description names a specific verb and resource ('the answers recorded in the latest measurement') and enumerates the returned fields (question, engine, named/cited, businesses and sources, excerpt), so an agent knows exactly what data comes back. It distinguishes itself implicitly from siblings like get_ai_sources or get_ai_visibility by focusing on individual answer records, but 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?

'Latest measurement' implies this should be read after run_ai_measurement, and 'answers' implies per-answer retrieval rather than aggregate visibility. However, no sentence states when to choose this tool over get_ai_visibility, get_ai_sources, or get_ai_traffic, so the routing 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, idempotentHint, destructiveHint=false and openWorldHint=false, so safety is covered. The description still adds real behavioral context beyond them: results are grouped per engine, answers are counted by whether you were named, and the first block is competitor-only citations. It omits page size, though the cursor parameter's schema covers pagination.

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, no filler, with the primary subject front-loaded. The second sentence is terse to the point of being cryptic ('First, the sources cited only in answers...'), which costs a little clarity but not space.

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

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

An output schema exists, so return values need not be described, and annotations plus the schema cover safety, the multi-site requirement and pagination. What the description adds — engine grouping, naming counts, competitor-first ordering — makes it sufficient for correct invocation. It is only marginally thin on when to prefer it over the visibility and traffic siblings.

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

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

Schema description coverage is 100%, and both parameters (site, cursor) are fully documented in the schema, including the multi-site requirement and the next_cursor mechanics. The description adds no parameter-level meaning, 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?

It names a specific resource (the sites/sources AI assistants cited) and adds scope detail: broken down engine by engine, with counts of answers that named you. That is more than a restatement of the title and lets an agent distinguish it from answer-level siblings like get_ai_answers. It never names a sibling outright, so the differentiation is inferred rather than stated.

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

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

The second sentence ('First, the sources cited only in answers that named a competitor and not you') signals a priority ordering or default focus, which implies when this call is most useful. However, it reads as output-ordering information rather than guidance, and it never states when to pick this over get_ai_visibility, get_ai_traffic or get_ai_answers, nor any prerequisites.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely non-obvious data semantics beyond that: the three counts are 'kept separate and never added together,' which prevents an agent from summing them into a bogus total, and it discloses the data source (the Goppa plugin on the user's own site), implying a site without the plugin yields nothing.

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 dense sentence that front-loads the source and then enumerates the metric types; no filler or restatement of the title. Slightly oblique phrasing ('counted on your own site by the Goppa plugin') costs a little parsing effort but every clause carries 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 an output schema present and full parameter documentation, the description only needs to establish what is being measured and when to call it. It handles the former well but leaves the crowded AI-metrics sibling set undisambiguated, which is the main thing an agent could get wrong here.

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

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

Schema coverage is 100% and both parameters carry detailed descriptions, including the multi-site selection behavior and the cursor contract. The description adds nothing about 'site' or 'cursor' beyond the schema, 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?

The description names a specific resource — real AI traffic measured on the user's own site — and enumerates the three distinct stream types (assistant-opened pages, clicks from AI answers, crawler visits). That is far more specific than the title alone. However, it never distinguishes itself from the many AI-related siblings (get_ai_answers, get_ai_sources, get_ai_visibility), so an agent cannot tell which AI tool to call from the description alone.

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

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

There is no when-to-use, when-not-to-use, or alternative-routing language at all. The phrase 'on your own site' faintly implies a contrast with AI visibility/answer measurements elsewhere, but the agent is left to infer that against three closely named siblings. No prerequisites (e.g., plugin must be installed) are stated as a precondition for calling.

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 readOnly/idempotent annotations, the description discloses useful behavioral detail: results come per engine, are expressed as 'k of n answers', include market and date plus earlier measurements of the same questions, and that a percentage is only shown from 10 answers. The sample-size threshold is exactly the kind of caveat an agent would otherwise misreport; only pagination/limits are unaddressed.

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 opens with the core question ('Whether AI assistants named your site') and then qualifies it. It is dense but every clause carries information; the engine enumeration is the only mildly padded segment.

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?

An output schema exists, so return shape needn't be spelled out, and the description still covers sample-size gating, comparison to earlier measurements, and per-engine granularity. What remains thin is guidance on choosing this over the other AI-visibility siblings.

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

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

Schema coverage is 100% and the single `site` parameter already documents domain format, optionality, and the multi-site selection behavior. The description adds nothing about the parameter, 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?

States a precise verb-and-resource pair: reads whether AI assistants named your site in the latest Goppa measurement, broken out per engine (ChatGPT, Gemini, AI Overview, AI Mode, Perplexity). It does not explicitly name or disambiguate against close siblings like get_ai_answers, get_ai_sources, or get_ai_traffic, so the agent must infer the split from the data it says it returns.

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: 'latest Goppa measurement' signals this reads existing measurement data rather than running one (run_ai_measurement). There is no explicit when-to-use, when-not-to-use, or statement of which sibling answers which adjacent question.

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, openWorldHint=false and destructiveHint=false, so the safety profile is fully covered. The description adds useful content scope — it discloses that results include broken backlinks, month-over-month new/lost deltas, and a competitor link gap, which is not inferable from annotations or the schema. It says nothing about volume, time range defaults, or rate limits, but an output schema exists so return shape needn't be described.

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 sentence, front-loaded with the core definition ('the sites that link to yours') and then itemizing the contents. Dense with colons and commas but every clause names real returned data, so nothing is filler. Slightly list-like to read, but no wasted sentences.

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 a single fully-documented parameter, an output schema, and complete read-only annotations, the only thing the description must supply is what content the tool surfaces — and it does so exhaustively, including the non-obvious link-gap and broken-backlink sets. Nothing needed to select or 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?

Schema coverage is 100% and the single 'site' parameter is documented in detail, including the fallback behavior when omitted and the multi-site requirement. The description adds nothing about the parameter, so baseline 3 applies — the schema carries this dimension entirely.

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 enumerates the specific data returned — linking sites, backlinks, broken backlinks, new/lost month over month, and the link-gap set (competitor-only linkers). That is far more specific than the title 'Read your backlinks' and lets an agent tell it apart from get_competitors or get_google_overview. It lacks an explicit verb ('returns'/'lists'), so it reads as a noun phrase rather than an action statement.

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

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

There is no statement of when to call this versus the many sibling read tools (get_competitors, get_google_overview, get_what_changed). The month-by-month and link-gap content hints at scope, but no explicit conditions, exclusions, or alternatives are given.

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

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

Annotations already declare readOnly, idempotent and closed-world, so the safety profile is carried structurally. The description adds genuine behavioral detail beyond that: results are aggregated as 'named in k of n answers' and it reports a separate count for answers naming the competitor but not you, which tells the agent what the output measures rather than merely that it is a read.

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

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

It is a single dense sentence that front-loads the subject (which businesses) and then the metric. The trailing clause about competitors named without you is slightly compressed but every part carries information; 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 an output schema present, the description needn't explain return shape, and it correctly spends its words on what the numbers mean (k of n, per-engine, named-not-you) and on scope (your site). This is sufficient for an agent to call 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%, so both `site` (including the multi-site fallback behavior) and `cursor` are already fully documented in the schema. The description adds no parameter-level information beyond the implicit 'your site' framing, 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?

The description names a specific resource (businesses/domains co-named in AI answers with your site) and a specific breakdown (engine by engine), which is concrete enough for an agent to know what comes back. It does not, however, name or contrast with the obvious overlapping sibling get_google_competitors, so disambiguation is left to inference.

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

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

Usage is only implied: an agent can infer 'use this when you want AI-answer competitors' versus google competitors. There is no explicit when-to-use, no exclusion, and no pointer to get_google_competitors or get_ai_answers as the alternative for a different question, which is a real risk given the sibling set.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false; the description reinforces this with 'Reading this changes nothing' and adds genuinely new context about what the payload contains and the required human-approval gate before applying. It stops short of describing pagination behaviour (10 items per page) or error cases, which live only in the 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?

Purpose is front-loaded and the closing sentences carry the operating constraint and hand-off. The colon-separated enumeration plus the parenthetical about the site's code/builder/app is slightly run-on, but each clause conveys actionable content rather than 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?

An output schema exists, so return values need not be spelled out, yet the description still summarises the shape of each fix and the llms.txt case. Combined with the approval workflow and the read-only assurance, an agent has what it needs to call this correctly; only the pagination/next_cursor loop is left to the schema.

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

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

Schema description coverage is 100%, so all three parameters are already documented, and the description adds only the loose notion of 'for one site' and the llms.txt inclusion. Baseline 3 is appropriate when the schema carries the parameter burden.

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

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

States a specific verb and resource — retrieving SEO fixes the user has already approved in Goppa — and enumerates what each fix carries (page, field, location, current text, new text, plus an llms.txt). The 'already approved' qualifier implicitly separates it from get_seo_fixes, but it never names that sibling, so an agent 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?

Gives a clear workflow: show the fixes to the user, apply only with their go-ahead, then call report_fixes_applied — a named next-step tool. It does not explicitly say when to prefer get_seo_fixes instead, so the when-not side 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 this as a safe, read-only, idempotent operation, so the bar is lower. The description adds some useful behavioral context by noting that large portals are listed apart and by summarizing the metrics included, but it does not disclose ordering, pagination, or other operational details beyond what annotations already cover.

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

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

The description is compact and front-loads the core definition of the returned sites and their metrics. The second sentence about large portals is short and relevant, though the overall phrasing is more noun-phrase summary than actionable instruction.

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

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

For a simple read-only tool with a fully described single optional parameter, rich annotations, and an output schema, the description provides enough context to understand what data is returned. The main remaining gap is selection guidance against related sibling tools, which is only partially addressed.

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 single optional 'site' parameter is fully explained in the schema, including its fallback behavior when omitted. The description adds no additional parameter meaning, so the baseline of 3 is appropriate.

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

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

The description clearly identifies the resource as sites ranking on Google for the same searches as the user, and lists the specific fields returned: keywords in common, size, and count of tracked keywords ranked above. It does not, however, differentiate itself from the sibling tool get_competitors, leaving ambiguity about which competitor tool to select.

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

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

The description implies the tool is for viewing Google competitors, but it gives no explicit guidance on when to use it versus alternatives such as get_competitors, get_google_overview, or get_google_rankings. It also provides no when-not conditions or prerequisites.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context like the 28-day Search Console window and week-by-week visibility index, but does not discuss freshness, limits, or permissions.

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

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

The content is front-loaded and each clause adds a distinct data category, with no obvious filler. However, it is a single long run-on sentence that would be easier to scan as structured clauses or bullets.

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?

An output schema exists, so the description need not explain return values, and the annotations cover safety. The description is complete enough about the data categories and time window for an agent to know what this overview provides, though it omits usage routing context.

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

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

The single 'site' parameter is fully described in the schema, including its behavior when multiple sites exist. The description itself does not mention the parameter, so the schema carries the full parameter burden and the baseline score of 3 applies.

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

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

The description clearly identifies the tool as a Google/Bing site overview 'beyond rankings' and enumerates the included metrics, so an agent knows what data it returns. It does not explicitly name sibling alternatives, but the scope statement signals how it differs from a rankings-only tool.

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

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

The description lists what the tool contains but never states when to use it versus alternatives such as get_google_rankings, get_weekly_summary, or get_site_audit. There are no explicit exclusions or routing rules for the agent.

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, and closed-world, so the safety profile needs no restating. The description does add one genuinely useful behavioral fact: positions are bucketed (Top 3, 4-10, 11-20, 21-30, not in top 30) rather than exact, which annotations cannot convey. It says nothing about pagination behavior or what 'tracked' scopes to, so it is useful but not rich.

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

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

One compact sentence that leads with the resource and then lists outputs in a tight parenthetical; nothing is padded. It is a sentence fragment with no explicit action verb, which is the only structural weakness.

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 full schema coverage, complete annotations, and an output schema, most burden is already carried elsewhere. However, the description spends its whole budget previewing return fields that the output schema already defines, while omitting scope information an agent would want, such as what 'tracked' searches mean and how fresh the data is.

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

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

Schema description coverage is 100%: the site parameter already documents the single-site-optional / multi-site-required rule and the fallback that lists sites, and cursor explains next-page usage. The description adds no parameter-level meaning 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?

The description names the resource (tracked Google searches) and enumerates exactly what data is returned: position bucket, change since last check, monthly searches, and alerts. An agent can distinguish this from generic siblings like get_google_overview or get_google_competitors without opening a schema. It stops short of an explicit verb statement or naming the sibling it differs from, keeping it at 4.

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

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

No when-to-use guidance, no prerequisites, and no alternatives are mentioned. Nothing tells the agent whether this is the right call versus get_google_overview or get_what_changed when the user asks about ranking movement. Usage is only inferable from the tool name and the returned-field list.

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

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

Annotations already establish that this is a read-only, idempotent, non-destructive operation. The description adds useful behavioral context beyond annotations: it discloses that results are 'latest' research, defines quick wins, and mentions the monthly research quota left, which helps an agent understand scope and freshness.

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

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

The description is a single dense sentence that front-loads the core resource and then lists the included data categories. It is efficient and every item earns its place, though the nested definitions make it slightly less scannable than a bulleted structure would be.

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 presence of an output schema, annotations, and complete schema descriptions, the definition provides enough context for correct invocation. It fully describes the returned data categories and quota context, though it could be slightly stronger with explicit usage guidance.

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

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

Schema description coverage is 100%, so both the site and cursor parameters are fully documented in the schema. The description adds no parameter-specific guidance, so the baseline score of 3 is appropriate.

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

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

The description clearly identifies the resource as the user's latest Google keyword research and enumerates the specific result categories: quick wins, keyword ideas, remaining research, and keyword gap. It is specific enough to distinguish this from sibling tools like get_google_rankings or get_competitors, though it does not explicitly name alternatives.

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

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

Usage is implied by the content — an agent can infer this tool is for retrieving keyword ideas and gap opportunities. However, the description does not state explicit when-to-use conditions, prerequisites, or which sibling tools to use instead.

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 readOnly and non-destructive annotations already covering safety, the description adds meaningful context: it returns the next open step plus five following steps, and it explains the distinction between 'done means confirmed by Goppa's data' and user-marked steps showing as 'reported by you'. This goes 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?

The description is two compact sentences and front-loads the core resource. It is mostly efficient, though 'the steps' is slightly vague against the longer phrase about what the step contains.

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 output schema exists and annotations cover safety, the description provides enough about the returned content: next open step plus five after, contents, and done-status semantics. It omits the site-selection behavior, but that is fully covered in the schema.

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

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

Schema description coverage is 100% and the single optional 'site' parameter is already well documented in the schema. The description adds no additional parameter meaning, 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?

It names a specific resource ('next open step in the Goppa guide and the five after it') and describes what that step contains ('what to do, why, the steps, and where to see the effect'). It is clear what the tool returns, though it does not explicitly distinguish itself from siblings like get_fixes_to_apply or get_seo_fixes.

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

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

The description implies this is used to see your next step, but it gives no explicit guidance on when to call it versus alternatives such as get_fixes_to_apply or get_seo_fixes. No exclusions or prerequisites are mentioned.

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, idempotentHint, openWorldHint, and destructiveHint, so the safety profile is covered. The description adds meaningful behavioral context by listing the fix statuses included and clarifying that approval is handled elsewhere, though pagination behavior is left to the 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?

The description is front-loaded and dense with useful categorization, with no filler. The first sentence is somewhat long and list-heavy, but every clause contributes to scope or 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 rich annotations, full schema descriptions, and an output schema, the description provides enough context to invoke the tool correctly. Minor gaps around pagination and sibling-tool routing are covered by structured fields or handled elsewhere.

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 site and cursor parameters are already well documented in the schema. The description adds no additional parameter semantics, which is acceptable given the complete 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?

The description states a specific resource and scope: SEO fixes prepared by Goppa, including pending, applied, and product-question items. It is clear what the tool returns, but it does not explicitly distinguish itself from related siblings such as get_fixes_to_apply or report_fixes_applied.

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

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

It clearly establishes that this is a read-only view and that approval happens in Goppa, which is a useful usage boundary. However, it does not explicitly say when to choose this tool over the closely related fixes/apply siblings, leaving that inference to the agent.

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 and closed-world, so the safety profile is covered; the description earns credit for characterizing the payload's shape (aggregate error-free count, per-problem page frequency plus rationale, delta vs. previous audit). It does not mention that results depend on a prior audit existing or how paging behaves, which are the remaining behavioral gaps.

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

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

One sentence, no filler, and the core deliverable is front-loaded before the enumeration of sub-results. Every clause maps to a distinct piece of returned 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 an output schema present the description needn't explain return values in detail, and annotations cover safety; two optional params are fully documented in schema. What is missing is the routing context — given five audit/change-adjacent siblings, an agent cannot tell from this text alone which one to reach for.

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 schema descriptions are unusually good — the optional 'site' parameter's fallback-to-list behavior and the 'cursor' pagination contract are fully spelled out. The description adds nothing about either parameter, 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?

The description names the resource precisely (page-by-page site audit) and enumerates what the caller receives: pages without errors as k of n, per-problem page counts with rationale, and the delta since the prior audit. It is clear what the tool yields, but it never distinguishes itself from the crowded sibling set (get_site_check, run_site_check, scan_site, get_what_changed), which overlap heavily with the 'what changed since the previous audit' framing.

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

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

There is no statement of when to call this versus get_site_check, run_site_check, scan_site, or get_what_changed, nor whether a prior audit must exist for the delta to be meaningful. The agent must infer the selection criteria from names alone.

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

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

Annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint=false), so the bar is lower. The description adds some useful framing about what the payload contains and that fixes are keyed to failing checks, but says nothing about freshness, staleness, or whether a check must exist before it can be read.

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

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

A single sentence that front-loads what the agent gets back, with no filler. It is a fragment rather than a sentence with an explicit verb, which is a minor structural weakness but costs no 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?

With an output schema present, the return values need not be spelled out, and the annotations plus a fully documented schema cover the rest. The one remaining gap is the absent explicit contrast with run_site_check, which matters in a sibling list that also contains run_ai_measurement and get_site_audit.

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 both parameters are fully documented, including the multi-site requirement and cursor paging. The description only says 'of your site', adding nothing the schema does not already state, 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?

The description names the specific resource (the latest AI readability check of your site) and its payload (checks passed k of n, the score, per-check fix guidance). The word 'latest' implicitly separates it from run_site_check, which starts a new check, but the sibling is never named, so differentiation is left to inference.

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

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

Usage is only implied: 'the latest ... check' suggests reading an existing result rather than triggering a fresh run. There is no explicit statement of when to call this instead of run_site_check, nor any mention of prerequisites such as whether a check must have been run first.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuinely useful context beyond that: the data is an aggregate study over 176 businesses, not tenant-specific results, which tells the agent the payload is a fixed dataset.

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

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

A single front-loaded sentence with the scope stated before the enumerated findings. The colon-separated list is dense but each clause names a distinct result dimension, so 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 an output schema present, return-value detail is unnecessary, and zero params means no input contract to explain. What is missing is only a note on whether the study is static or refreshes, but for a fixed published benchmark the description is otherwise 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?

Zero parameters, so there is nothing for the description to disambiguate and the baseline applies. The description does not misrepresent any inputs, and additionalProperties=false with an empty object leaves no ambiguity.

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 ('Return findings from Goppa's 2026 Q3 study of 176 businesses') plus the actual questions the data answers. That makes it immediately distinguishable from every sibling, all of which are scoped to a site or account rather than a fixed published study.

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 guidance, no exclusions, and no named alternatives. Usage is only implied by the content description — an agent can infer this is the benchmark/reference source rather than site-specific data, but it must make that inference itself.

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

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

The annotations already establish read-only, idempotent, non-destructive, and non-open-world behavior, and the description adds useful context about what the summary contains. It also discloses the important behavioral trait that the tool starts no new measurement, though it does not discuss auth requirements, caching, or freshness beyond the previous comparable measurement.

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 resource and then packs the section list densely into one long sentence without filler. It is efficient, but the single semicolon-heavy sentence makes it somewhat harder to scan than a structured list would.

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 tool's complexity, the description covers the full scope of the weekly summary, and the output schema handles return-value structure while annotations cover safety semantics. The schema fully documents the sole parameter, so there is no material 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?

Schema description coverage is 100% for the single site parameter, and the schema already explains the multi-site requirement and single-site omission. The description only reinforces the notion of 'one site' and adds no additional syntax or selection semantics beyond what the schema provides.

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

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

The description clearly defines the resource as a weekly summary of one site and enumerates the sections it contains, so an agent can tell it is a composite read-only report rather than a single metric. It also distinguishes itself from measurement-triggering tools by stating 'It starts no new measurement,' but it does not explicitly contrast itself with close siblings such as get_what_changed or get_next_steps.

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: it is a weekly summary and does not start a new measurement, which signals it is for reading an existing digest rather than triggering work. However, the description provides no explicit when-to-use guidance, no exclusions, and no named alternatives for cases where a more targeted tool would be better.

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 non-destructive behavior, so safety is covered. The description usefully adds the paired-test methodology and that results distinguish real change from normal variance. It does not say what happens when fewer than two measurements exist or how large the pair lists are.

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 that names the comparison, the methodology, and the two result categories with no filler. It is dense but each clause carries 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?

An output schema exists, so return values need not be explained, and the description gives a good conceptual model of the comparison. It still omits prerequisites such as needing at least two measurements and how this differs from the neighboring visibility tools, leaving gaps for a zero-required-parameter tool.

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

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

Schema description coverage is 100%, so site and the three cursor parameters are fully documented in the schema. The description adds no parameter meaning beyond what is already structured, which is the correct 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?

States a specific verb-plus-resource: it compares the two latest comparable measurements and reports gained/lost pairs plus whether the change is statistically real. An agent can tell it apart from get_ai_visibility or get_weekly_summary, though no sibling is named explicitly.

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

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

Usage is only implied by 'between the two latest comparable measurements'; there is no explicit when-to-use, when-not-to-use, or pointer to an alternative such as get_ai_visibility for absolute levels. The agent must infer the comparison scenario itself.

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

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

Annotations already declare a non-read-only, non-destructive, idempotent write. The description adds important context: it records in Goppa rather than changing the site, and the next site audit checks each page. That resolves the apparent tension between a write tool and 'changes nothing on the site'.

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 and uses only two sentences after it to state the audit consequence and the no-site-change guarantee. It contains 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 complete schema coverage, an output schema, and annotations covering safety traits, the description supplies the remaining workflow context: source of fixes, status meanings, and downstream audit behavior. Nothing essential for correct invocation 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%, so the schema already documents site, results, fix_id, reason, and status in detail. The description reinforces the status meanings and the source of fix_id, but it does not add much beyond the structured 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: recording in Goppa which approved SEO fixes from get_fixes_to_apply were applied, not applied, or undone. It names the source sibling tool explicitly, so an agent can distinguish it from retrieval tools like get_fixes_to_apply.

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

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

It clearly implies this tool is used after handling approved fixes from get_fixes_to_apply, with statuses for applied, not_applied, and undone/kept. It does not explicitly state when not to use it or name alternatives, but the workflow 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?

Beyond the annotations (which only flag a non-readonly, non-idempotent, open-world call), the description discloses that the preview runs nothing, that the approved call executes in the background for several minutes, that it consumes one of the account's allotted AI measurements, and that the site itself is unchanged. These are the exact quota, latency, and side-effect facts an agent needs and annotations cannot 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 purpose is front-loaded and the closing reassurance ('Nothing on your site changes') earns its place, but the middle sentences are long and pack the preview/approval/workflow rules into dense clauses that could be broken apart for faster scanning.

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

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

The tool has an output schema, full parameter documentation, and meaningful annotations; the description still covers the quota cost, async runtime, user-approval requirement, and next-step tool. Nothing an agent needs in order 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?

Schema description coverage is 100% and each parameter is thoroughly documented there, so the description only reinforces the approval parameter's preview-to-run relationship. With the schema doing the heavy lifting, the baseline 3 applies; the description adds no format or syntactic detail beyond it.

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

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

The first sentence states a specific verb and resource ('measure whether AI assistants name one of your sites') and names the five engines covered. It also explicitly separates this tool from the sibling that reports results ('get_ai_visibility shows the result'), so an agent can distinguish them without opening schemas.

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 an explicit two-call protocol: call without approval for a preview, show the questions to the user, then call again with the approval code only after they agree. It also names the follow-up tool (get_ai_visibility) for retrieving the outcome, leaving no routing decision 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?

Goes beyond annotations by reporting a concrete rate limit (10/hour/account), scoping the external effect ("reads your public pages; nothing on your site changes") and disclosing that a record is persisted in the account, which is consistent with readOnlyHint=false and idempotentHint=false. It does not say whether the check completes synchronously or must be polled via get_site_check, which is the main remaining behavioral gap.

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

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

Three short sentences, front-loaded with the action and result, then the safety scope, then the quota. Every sentence carries distinct information with no repetition of the title.

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?

Output schema exists so return values need no explanation, the single optional parameter is fully documented in schema, and quota plus non-destructiveness are covered. Missing is the run lifecycle: whether results arrive immediately or only via the get_site_check sibling after a delay.

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 schema already explains the domain format and the multi-site requirement in detail. The description only says "on one of your sites" and adds nothing about the parameter beyond the schema, so the baseline 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 ("Run a new AI readability check on ... your sites") plus the persistence effect ("save it to your Goppa account"). The word "new" implicitly separates it from get_site_check, which reads an existing check, but no sibling is named 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?

Timing ("now") and the per-account quota give a usable context, but there is no explicit statement of when to prefer this over get_site_check, scan_site or run_ai_measurement, nor when not to run a fresh check (e.g. if a recent one exists).

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 and openWorld, so the safety profile is covered. The description still adds real value beyond them: the 0-100 output range, that failing checks are returned alongside the score, and that no authentication or account is required. It stops short of saying whether the scan is instant or asynchronous, or whether it incurs cost/rate limits.

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 zero filler: capability first, output second, access constraint third. Every clause carries information and the key scoping fact (no account needed) is not buried.

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?

An output schema exists, so the description needn't detail return values, and the one-parameter surface is fully specified by the schema. What remains unaddressed is the operational profile — latency, rate limits, and how this differs from run_site_check — which matters for a network-bound openWorld scan.

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 description coverage including an example ("example.com"), so the schema carries the burden fully. The description adds nothing about accepted URL forms (scheme, trailing path, subdomains), 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 concrete verb and resource — "Score any website 0-100 on how readable it is to AI assistants" — and enumerates the four dimensions measured (crawler access, structured data, discovery files, agent protocols). An agent knows exactly what comes back. However, it never distinguishes itself from the very similar siblings run_site_check and get_site_check, which an agent could easily pick instead.

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?

"Public information only, no account needed" implies the tool works on arbitrary URLs not yet added via add_site, which is useful usage context. But there is no explicit statement of when to use this versus run_site_check/get_site_check, and no exclusion or prerequisite guidance despite three plausibly overlapping siblings.

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