Peak Answer

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

Annotations already declare readOnlyHint=false, idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds non-annotation context: tracked competitors cause answers to be checked for name mentions, and domain improves match reliability. It does not note any side effects like quota or sync delays, so it stops short of a 5.

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, the core action and its consequence front-loaded, with the parameter advice second. The trailing clause about common company names is slightly wordy but carries real information, so nothing is wasted.

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

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

For a two-parameter mutation tool with full annotation coverage and no output schema, the description covers purpose, effect, and parameter nuance adequately. It need not explain return values, though it could say more about what happens if the competitor already exists (beyond the idempotentHint).

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 genuine meaning beyond the schema: domain 'is what makes the match reliable for a common company name,' which explains why the optional parameter matters, and 'as buyers say it' semantics for name align with the schema text.

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 ('Track') and resource ('a competitor for the connected brand') and explains the effect of tracking ('every answer is checked for whether it is named'), so the agent knows what registering a competitor actually does. It does not explicitly name the sibling remove_competitor, but the inverse relationship is inferable from the tool name.

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 conditional guidance on a parameter ('Pass the domain when the user knows it'), which is useful, but never states when to reach for add_competitor versus adjacent tools like track_question or my_brand. Usage context is implied rather than stated.

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

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

Annotations already declare destructiveHint=true, openWorldHint=true, readOnlyHint=false and non-idempotence; the description adds the crucial context that this is the ONLY tool that mutates state outside Peak Answer, that publishing is immediate, and that user confirmation is required. It stops short of saying whether publishing is reversible or undoable, which is the main 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?

Two sentences, both load-bearing: the first front-loads the irreversible external effect in caps for emphasis, the second carries the safety instruction. 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 one-parameter, no-output-schema mutation tool the description covers purpose, precondition, and the destructive/external nature. An agent still lacks any statement of what a successful approval returns or how a partial-title match failure is surfaced, but nothing needed to decide whether to call it 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 schema already explains that the article parameter accepts a title or a partial identifier. The description's "Pass the article's title" largely restates that, adding no disambiguation or format guidance, so the baseline 3 applies.

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

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

States a specific verb (approve) and resource (drafted article) plus the concrete external effect (publishes it to the brand's connected website immediately). No sibling in the list does anything similar, so it is trivially distinguishable from add_competitor, audit_site, track_question, etc.

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 precondition (confirm with the user before calling) and an explicit when-not ("never call it to 'check' anything"), which is unusually strong guidance. It does not name an alternative tool, but none of the siblings offers a comparable publish action, so there is little routing ambiguity left.

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 openWorld, so the safety profile is covered. The description adds behavioral context annotations cannot: the call returns in seconds and slower checks are opt-in via extra_checks, which is genuine added value. It doesn't state auth requirements or failure modes, keeping it out of 5 territory.

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?

Front-loaded with the core purpose and scope in one sentence, followed by usage triggers and a documentation pointer. It is dense but every clause carries information; the long enumeration of checks is the only mildly costly element.

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 audit tool with no output schema, the description covers what is inspected, when to use it, latency behavior and where to learn what the report means. Return-value shape is deferred to an external doc rather than described inline, which is a minor gap.

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

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

Schema description coverage is 100%, so both parameters are already documented in the schema, including the per-check latency. The description's 'Add extra_checks for the slower ones' reinforces but does not deepen the schema's meaning. Baseline 3 is correct.

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 and then enumerates the exact dimensions covered (answer readiness, AI crawler access, robots.txt, sitemap, structured data, headings, meta description, readability, entities). An agent can tell this is a comprehensive single-URL audit rather than one of the many 'my_*' retrieval siblings. The only soft spot is that it never contrasts itself with geo_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?

Gives explicit trigger phrasing: any 'audit my site', 'check my site' or 'why am I not being recommended' question. That is clear, actionable routing guidance. It stops short of 5 because it names no when-not condition and does not distinguish itself from the sibling geo_audit.

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, openWorldHint=true, and idempotentHint=true, so the safety/idempotency profile is covered. The description adds only 'ready to ship' and defers the actual output shape to an external URL, so it contributes little behavioral context beyond what annotations provide; readOnly for a 'generate' tool is defensible since nothing is persisted.

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 that front-load the purpose and artifact list with zero filler. Ending on an external URL rather than return-shape content is economical, though it offloads information a reader may have expected inline.

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 low-complexity, 2-parameter tool with no output schema, the description covers what it produces but punts the return shape entirely to a documentation URL and omits error/edge-case guidance. Adequate but with a clear gap where a return-value summary would help.

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

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

Schema description coverage is 100% and both parameters are documented in the schema, so baseline is 3. The description's grouping of site-artifacts vs topic-artifacts loosely mirrors the input mapping already stated in the schema, adding no syntax or format 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?

States a specific verb ('Produce') and enumerates the five concrete artifacts it can generate, which lets an agent distinguish it from the auditing and my_* retrieval siblings. It stops short of explicitly naming a sibling it is not, but the resource set is unambiguous.

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 phrase 'One call per thing' gives operational guidance on batching, which is useful. However, there is no explicit when-to-use/when-not or alternative routing; usage is only implied by the artifact 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 cover the safety profile (readOnly, idempotent, openWorld), but the description adds the crucial non-obvious trait that this is an asynchronous background run requiring a second call with the same domain to poll for results, plus a latency warning ('Slow'). That is real behavioral value beyond the annotations, though it omits how long the run takes or how to detect readiness.

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?

Sentences are front-loaded and each earns its place: purpose, then result, then async behavior, then the alternative, then a docs link. The only mild weakness is deferring 'how the questions are chosen and how to read the result' to an external URL rather than stating it inline.

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

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

For a single-parameter tool with annotations and no output schema, the description covers purpose, async flow, the alternative tool, and roughly what the result contains. It is nearly complete, missing only timing/readiness detail for the polling loop.

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 defines 'url' as 'The domain to audit', so the baseline is 3. The description adds meaning beyond the schema by revealing the url doubles as a run key that must be re-supplied to collect the result, which is genuinely informative for correct invocation.

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 (runs 5 buying questions through ChatGPT to audit AI visibility) and names exactly what the agent learns back (brand presence, winning competitors, shaping sources). It is clearly distinguishable from siblings like audit_site and track_question.

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 gives the when-to-use condition ('Slow: it starts a background run and you call it again with the same domain to collect the result') and names the alternative with its selecting condition ('Use audit_site for anything that needs an answer now'). Nothing 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, openWorldHint and idempotentHint, so the safety profile is covered. The description adds genuinely new behavioral context beyond that: a per-property quota of ~2,000 inspections/day and the requirement that the URL belong to the property. It stops short of describing failure behavior (e.g. a URL outside the property) or latency.

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?

Front-loaded with the identity of the tool and its payload, then usage and constraints. The field enumeration is long, but it earns its place given there is no output schema and it is the only place the return contents are described. 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?

There is no output schema, so the description carries the return-value burden itself and does so by listing the fields returned. Combined with the usage trigger, the property-ownership precondition and the quota, an agent has everything needed to decide to call it and how to shape the call.

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 'url' and 'site' are already documented in the schema. The description contributes only a slight constraint via 'The URL must belong to the property', which is really a prerequisite rather than new parameter semantics. Baseline 3 is appropriate.

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

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

States a specific verb and resource ('Google's own record of one URL from the URL Inspection API') and then enumerates exactly what that record contains: index status, verdict/coverage state, crawl time, canonical comparison, robots/fetch state, mobile usability, rich results. This is clearly distinguishable from siblings like gsc_query (search analytics) or gsc_sitemaps, so an agent can tell them apart without opening a schema.

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

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

Gives explicit context for invocation — 'Use this when the user asks why a specific page is not showing up' — plus a hard precondition that the URL must belong to the property. It does not name a competing sibling or state when-not (e.g. use gsc_query for aggregate performance), so it is strong context without explicit 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?

Annotations already establish readOnly/idempotent/openWorld, so the description's job is to add substance, which it does by disclosing the payload contents (permission level per property, brand-connection flag). With no output schema, this is the agent's only signal about what comes back, and it covers the essentials but not the shape or ordering of the response.

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: the first declares what is returned, the second declares the intended use. No filler, and the resource description is front-loaded before the routing hint.

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

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

For a zero-parameter, read-only lookup with no output schema, the description adequately covers both the return contents and the reason to call it. A brief note on response format (e.g. that each property includes its verification/permission status keys) would close the remaining gap.

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

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

The tool takes zero parameters, so there is nothing to document and the schema/description cannot conflict. Baseline for a parameterless tool.

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

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

Names the specific resource (every Search Console property on the connected Google account) and states exactly what each entry carries: permission level and whether this brand is connected. This distinguishes it cleanly from data-reading siblings such as gsc_query and gsc_inspect_url.

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 tells the agent when to reach for it: to resolve the exact property string needed as the `site` argument by the other gsc_ tools. It sets up a clear prerequisite relationship, though it doesn't state any exclusions or conditions where it shouldn't be called.

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

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

Annotations already cover the safety profile (readOnly, idempotent, openWorld), and the description adds real operational context beyond them: 5,000-row cap with startRow paging, ctr expressed as a fraction, and roughly 2-day data lag. It does not mention quota or error behavior, but the freshness and paging details are exactly the kind of trait annotations cannot express.

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 and metrics are front-loaded, and the later sentences (paging, ctr scale, data lag) each carry a concrete fact. It is a dense run-on, and the enumerated dimension/search-type lists duplicate the schema enums, which is mild waste but also aids 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?

With 10 optional parameters and no output schema, the description carries the return-shape burden itself by naming the returned metrics, and it covers freshness, paging, row caps, and the ctr scale. An agent has everything needed to call this correctly and interpret the response.

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 and the schema already documents defaults, enums, and constraints. The description largely restates schema facts (5,000 row max, startRow paging, hour/dataState coupling, 2-day-default endDate); only the ctr-as-fraction note is genuinely new semantic guidance.

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

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

States a specific verb+resource: it returns the Search Console performance report with named metrics (clicks, impressions, ctr, average position) and the exact dimensions and search types it can break down by. An agent can distinguish this from search/inspection siblings such as gsc_inspect_url without opening a schema.

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

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

The description gives a strong usage clause: "Use this for any analysis of the customer's own Search Console data" followed by concrete scenarios (top queries, top pages, branded vs non-branded, regex filters). It does not explicitly name or exclude the closest alternatives (gsc_inspect_url for single-URL inspection, gsc_properties for listing properties), so routing still requires some 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 cover the safety profile (readOnly, idempotent, open-world), and the description adds valuable detail on return contents — sitemap type, last submitted/downloaded, warnings, errors, submitted vs indexed URL counts. It does not mention auth or rate limits, but for a read-only reporting tool that is acceptable.

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 waste, with the resource and returned fields front-loaded and the usage trigger immediately after. Every clause 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 no output schema, the description compensates by enumerating the returned fields precisely, and annotations cover the read-only safety profile. Nothing an agent needs in order to call this 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?

Only one optional parameter exists and the schema documents it fully (100% coverage), including the site format and omit-for-default behavior. The description adds nothing about the 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 specific resource (sitemaps) and enumerates exactly what is reported — path, type, submit/download timestamps, warnings, errors, URL counts. This clearly separates it from read siblings like gsc_query or gsc_inspect_url, though it does not explicitly name the sibling it is not.

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 usage trigger: 'Use this when the user asks whether Google has read their sitemap or why pages are not indexed.' That is concrete context, but there is no when-not guidance or named alternative (e.g. gsc_inspect_url for per-URL checks).

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 declare readOnlyHint=false, idempotentHint=true and destructiveHint=false, so safety is largely covered. The description adds genuinely non-obvious behavioral context: completing an action is what surfaces the next one, which no annotation conveys.

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

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

Three short sentences, front-loaded with the operation and its consequence, followed by the procedure and the trigger. 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 single-parameter mutation with no output schema, the description covers the operation, the side effect, the prerequisite lookup and the trigger condition. It could still note what happens on an ambiguous title match, which is why it is not a 5.

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 schema already explains that the value is the action's title or a partial match. The description's 'pass the action's title' merely restates this, so the baseline of 3 is correct.

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 (mark ... finished) and resource (brand's recommended action), and explains the effect that the item disappears and the next appears. It does not explicitly differentiate from the sibling skip_action, which is the obvious near-neighbor, so it stops short of a 5.

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

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

Gives an explicit workflow ('Call my_actions first ... then pass the action's title') and a clear trigger ('when the user says they have done something Peak Answer recommended'). The one gap is that it never names skip_action as the alternative for actions the user did not complete.

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, openWorldHint=false), so the description's job is to add context, and it does by disclosing the returned fields: reason, expected effect, and targeted engine. It omits freshness/recency, result limits, and whether an empty list means 'no recommendations' or 'not yet analyzed'.

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, and the content of the response is front-loaded before the usage cue. Every clause 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 no input parameters and no output schema, the description must carry the return-value burden, and it names the three fields the agent will see. Adequate for a simple read tool, though it leaves edge cases (empty results, staleness) unaddressed.

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

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

The tool takes zero parameters, so there is nothing for the schema to document and no description-side compensation is required. Baseline for a parameterless tool applies.

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

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

States a specific resource ('everything Peak Answer currently recommends for the signed-in brand') plus the payload shape (reason, expected effect, target engine), which clearly separates it from data-oriented siblings like my_visibility or my_questions. It never names a sibling explicitly, so differentiation is implied 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?

'Use this when the user asks what to do next' gives a concrete triggering condition, which is more than most tools in this set offer. There is no guidance on when NOT to use it or which sibling to prefer for adjacent questions (e.g. raw visibility data vs recommendations).

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 openWorldHint=false, so the safety profile is covered. The description adds that returned sources include those cited, consulted or linked, which is useful content context. With no output schema, it still omits anything about result shape or limits beyond what the schema states.

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. The payload description leads and the usage trigger follows, so both the what and the when are front-loaded.

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

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

For a simple read-only lookup tool with fully documented parameters, the description covers both what is returned (answers plus sources) and when to call it. Since there is no output schema, a sentence on return shape or pagination would round it out, but 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%, so limit, engine and question are fully documented in the schema (including the defaults and the engine enum list). The description adds no syntax or format detail for matching the question text. 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?

The description gives a concrete verb and resource: it returns the recorded answers for a tracked question, plus the sources each engine cited, consulted or linked. The title reinforces this. It is clear what the tool produces, though it only implicitly distinguishes itself from siblings like my_cited_sources or my_question_history rather than naming them.

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

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

It states explicit triggers: 'Use this when the user asks what an engine said, which pages it read, or why a competitor is being named.' That is strong affirmative guidance covering three real query patterns. It stops short of naming exclusions or the alternative tool to pick when the intent differs (e.g. my_cited_sources for aggregate source data).

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

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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint=false, so the safety profile is covered. The description adds the non-obvious sequencing behavior — that this is the entry-point lookup that resolves 'my site' ambiguity — which annotations cannot express. It stops short of any format/pagination detail, but the payload shape is already enumerated.

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, and the payload enumeration comes before the routing rule. Slightly dense, but every clause carries information — nothing restates the name or 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?

For a zero-parameter lookup with no output schema, the description compensates by enumerating the returned fields (domain, name, plan, question count, integrations) and by explaining when to call it. 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?

Zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The description correctly implies the call is parameterless by framing the result as scoped to 'this connection'.

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 exactly what the tool returns — the connection's brand: domain, name, plan, tracked question count, and connected integrations — which is a specific resource with an enumerated payload. It is clearly distinguishable from the my_* siblings (my_questions, my_visibility, my_search_console), which each cover a narrower slice.

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?

Explicit routing instruction: 'Call this first whenever the user says my site, my website or my domain, rather than asking them which site they mean.' It states both the trigger phrase and the behavior to avoid, which is exactly what an agent needs for tool selection among many my_* tools.

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

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

Annotations already declare readOnlyHint, idempotentHint and a closed-world scope, so safety is covered. The description adds genuinely new behavioral context: the data is observational ('have been seen citing') and includes citation frequency plus a brand-own-pages flag, which is not derivable from the annotations.

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

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

Two sentences, front-loaded with what the tool returns, followed by the use case. No filler and nothing repeated from the title or schema.

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 carries the burden of describing the return shape and does so — domains, frequency, and whether the brand's own pages appear. Combined with annotations and a fully documented parameter, an agent has everything needed 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?

There is only one optional parameter and the schema already documents it fully ('How many domains. Default 25, maximum 60.'). The description adds no syntax or format detail beyond that, so the baseline 3 for high schema coverage 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 (every domain the engines cite for this brand's questions) plus the shape of the answer (how often, whether the brand's own pages are included). It is clearly distinct from data siblings like my_links or my_traffic, which cover different surfaces.

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 concrete use cases — 'which sites do the models trust here' and link/PR targeting — which tells the agent when this tool is the right pick. It stops short of naming an alternative tool or a when-not-to-use condition, so it is clear context rather than full 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?

Annotations already declare readOnlyHint=true, idempotentHint=true and openWorldHint=false, so safety and determinism are covered structurally. The description adds the useful note that output mirrors a specific UI page, but says nothing about result shape, scope of competitors considered, or any limits — acceptable given annotations carry the risk profile.

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 core output meaning before the page reference and the usage examples. The phrase 'who beats me and where' partly restates the opening clause, which is mild redundancy rather than waste.

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

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

With no input schema fields and no output schema, the description carries the burden of conveying what comes back, and it does so qualitatively (winners, frequency, brand's relative position). For a zero-argument, read-only, closed-world tool this is close to complete; only the concrete return structure is unspecified.

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

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

The tool takes zero parameters, so the baseline is 4 and there is no parameter syntax for the description to explain. Nothing in the description misleads about 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?

States a specific analytic purpose — identifying which competitors win the brand's questions and where the brand ranks against them — which is more than a restated name. It does not explicitly contrast with near-neighbours like my_visibility or my_cited_sources, so an agent must infer the boundary from the 'Competitive Landscape page' 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?

Gives concrete invocation contexts in quoted user-intent form ('who are my competitors in AI answers', 'who beats me and where'), which maps cleanly onto when to reach for this tool. It offers no exclusions or named alternatives, so it stops short of full 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?

Annotations already declare readOnlyHint=true, idempotentHint=true and openWorldHint=false, so safety and side-effect behavior are covered. The description adds value beyond that by characterizing the returned content (ranked targets, reachability, required effort) and noting it mirrors the Links page, which is useful because there is no output schema.

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

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

Two tight sentences with the payload described first and the use cases second, no redundant restatement of the name. 'Mirrors the Links page' is slightly UI-dependent filler for an agent with no page context, which keeps it off a 5.

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

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

For a zero-required-param, read-only list tool with no output schema, the description covers what comes back and why an agent would call it. Only minor gaps remain, such as result ordering semantics and whether the list is exhaustive.

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 (kind filter and limit with default 15 / max 50) are already fully documented in the schema. The description adds no filter syntax, allowed values, or default behavior 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 concretely: a ranked list of link and placement opportunities (sites engines quote, directories, review sites) with reachability and effort. That is a specific, recognizable deliverable, though it is phrased as a noun rather than a verb and never explicitly distinguishes itself from near-siblings like my_cited_sources or my_landscape.

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 clear use cases: 'link building, PR targeting and directory submissions,' which tells the agent the right context to reach for this tool. It stops short of naming an alternative tool or stating when NOT to use it, so it does not reach the top band.

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 a closed-world scope, so the safety profile is covered. The description adds that the output is a before/after delta mirroring the Proof page, but says nothing about the default/maximum window behavior, result size, or freshness beyond what the schema states.

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

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

Two short sentences: the first front-loads what the tool returns, the second routes usage. No filler, no restatement of the title or name.

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, single-optional-param tool with no output schema, the description covers purpose and usage adequately and the schema covers the parameter. It stops short of clarifying the window's effect on results or how this delta view relates to neighboring visibility tools.

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

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

Schema coverage is 100% and the single 'days' parameter is fully documented with default (60) and maximum (180) in the schema itself. The description adds no meaning about the window, 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 states a specific resource (questions that started or stopped naming the brand) and a specific output shape (before and after), which is far more concrete than the bare name 'my_proof'. It does not name or contrast any sibling, so an agent must infer how it differs from my_visibility, my_question_history, or my_landscape.

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 usage contexts via example questions ('is it working', 'what have we won', 'what did we lose'), which tells the agent when this tool is appropriate. It offers no exclusions or named alternatives, which matters here given the many overlapping my_* analysis tools.

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

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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint=false, so safety is covered. The description adds real behavioral context beyond that: a fixed 90-day window, per-engine granularity, and the specific analytical dimensions returned. It stops short of mentioning rate limits, auth, or result size/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, front-loaded with what is returned before the alternative routing. Every clause carries information: the window, the breakdown, the fields, the sibling, the trigger. 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 no output schema, the description carries the return-value burden and does so by naming the four data dimensions. Combined with annotations covering the safety profile and a fully documented single parameter, an agent has everything needed to call this 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?

Only one parameter and schema coverage is 100%, so the schema already documents that fuzzy question text is accepted. The description reinforces 'single tracked question' and 'by name' but adds no syntax, matching rules, or format detail beyond what the schema states. Baseline 3 applies.

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

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

States a specific resource (per-engine history for one tracked question) with the concrete payload enumerated: presence rate, volatility, competitor substitution, daily trend. It also explicitly distinguishes itself from the sibling my_answers, so an agent can separate the two without opening either schema.

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

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

Gives both a positive trigger ('when the user asks about one specific question by name') and an explicit alternative ('For the answer text and the sources each engine cited, call my_answers'), which is the exact routing decision an agent faces among this large 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=true, idempotentHint=true and openWorldHint=false, so safety and idempotency are covered structurally. The description adds useful scope and payload context — results are scoped to the signed-in brand and report competitor ownership and answer volatility. However, it says nothing about result size, ordering, or pagination, so it goes only modestly beyond the annotations.

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

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

Two sentences, front-loaded with what the tool returns and followed by the usage trigger. No filler, no repetition of the title or annotations.

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

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

For a single-optional-parameter read tool with full annotations and no output schema, the description adequately covers scope and returned fields. It is slightly thin on volume/ordering behavior and on how it relates to my_question_history, which an agent might need to choose correctly between the two.

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

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

There is one optional boolean parameter and schema description coverage is 100%, so the schema fully explains only_losing. The description's phrase 'what they are losing' loosely hints at that filter but adds no syntax or behavioral detail beyond the schema; baseline 3 is appropriate.

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

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

States a specific resource (every buying question tracked for the signed-in brand) plus the three things returned: whether the brand is named, who wins instead, and how volatile the answer is. It is clearly distinguishable from generic siblings like my_brand or my_visibility, though it never contrasts itself with the closely related my_question_history.

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 an explicit trigger: use when the user asks what they are losing or which questions are worth attacking. That is a clear context, but there are no exclusions or named alternatives (e.g., when to prefer my_question_history or my_actions instead), so it stops short of full 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?

Annotations already declare readOnlyHint=true, idempotentHint=true and openWorldHint=false, so the safety profile is covered. The description adds the data provenance ('their connected Search Console'), which implies the tool reads the signed-in user's own authenticated property rather than arbitrary data, plus the ranking-window scope. Return shape is not described, but there is no output schema and no parameters.

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

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

Three compact sentences with no filler: definition first, then when to use, then the explicit hand-off to gsc_query. Each sentence carries a distinct, load-bearing piece of information.

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

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

For a read-only, parameterless, output-schema-less tool, the description covers what the data is, how it is scoped, when to call it, and which sibling to call otherwise. Nothing an agent needs to select and 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?

Zero parameters, so there is no parameter semantics to convey and no risk of misleading argument guidance; the baseline for a parameterless tool applies. The description usefully pins the implicit filtering (positions 5–15, signed-in brand) that would otherwise be mistaken for configurable arguments.

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

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

States a specific resource (Google queries for the signed-in brand) with a concrete qualifying threshold (positions 5–15) and names the data source. It is immediately distinguishable from gsc_query and the other 'my_*' tools because it owns the striking-distance niche.

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 both sides of the routing decision: use it for 'quick SEO wins' or 'close to page one', and for every other Search Console question (top queries, pages, countries, devices, filters, daily trend) use gsc_query. The alternative is named with the condition that selects 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 declare readOnlyHint=true, idempotentHint=true, and openWorldHint=false, so the safety profile is covered. The description adds the data provenance (Search Console) and that results match the Traffic page presentation, which is useful orientation but no rate limits, freshness lag, or granularity details.

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

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

Two tight sentences with zero filler; the resource definition is front-loaded and the sibling routing follows immediately. Nothing to cut.

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?

There is no output schema, and the description does supply the key return content (clicks and impressions over time). For a one-optional-parameter read-only tool this is nearly sufficient, though granularity (daily vs. weekly aggregation) and timezone/date-basis are left 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% and the single 'days' parameter already documents its default (90) and maximum (180) inline. The description adds nothing about the window 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?

States the specific resource and metric set ('clicks and impressions over time from Search Console') rather than restating the name, and explicitly positions itself against the sibling my_search_console by contrasting trend metrics with query reporting. An agent can distinguish the two without opening a schema.

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

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

Explicitly names the alternative and its scope: 'Use this alongside my_search_console, which reports the queries.' This tells the agent these are complementary, not competing. It stops short of stating when-not to use it (e.g., for query-level or page-level breakdowns), so a 4 rather than 5.

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

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

Annotations already declare readOnly, idempotent, and closed-world, so the safety profile is covered. The description adds meaningful scope beyond that: the result is scoped to the signed-in brand and includes trend/movement data, which tells the agent what kind of read this is.

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

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

Two sentences with no redundancy: the first states the payload, the second states the trigger conditions. Content is front-loaded with the returned data rather than preamble.

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 input parameters and no output schema, the description is the only source describing what comes back, and it does so at a useful level (index, per-engine presence, movement). A little more on freshness/period or comparison basis would fully close the gap, but it is largely complete.

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

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

The tool takes zero parameters, so there is no parameter semantics burden to carry; the baseline of 4 applies. Nothing in the description misleads about 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?

Names a specific resource (the signed-in brand's visibility index) and enumerates what the response contains: per-engine presence and movement over time. This is clearly distinguishable from siblings like my_brand or my_questions, which cover brand identity and question lists respectively.

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 explicit triggering conditions: 'when the user asks how they are doing, whether anything changed, or how they compare to their category.' That is solid when-to-use guidance, though it never names an alternative sibling tool for the comparison case, which other tools in this server may cover.

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 openWorldHint=false, so the safety profile is fully covered. The description adds a meaningful behavioural detail — this is the customer-facing rendering, mirroring the Weekly Report page — but says nothing about freshness, period boundaries, or return shape.

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

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

Two short sentences, front-loaded with what the artefact is before the parity note. Every clause carries information; the 'Mirrors the Weekly Report page' sentence is only marginally load-bearing but does orient the agent to the UI equivalent.

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 carries the burden of conveying what comes back. The three-item summary (what moved, what was published, what to do next) gives a useful sketch of the sections, but the format, granularity, and whether the content is per-brand or cross-brand are left unspecified.

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

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

The tool takes zero parameters, so the baseline of 4 applies; there is nothing for the description to disambiguate. It is silent on parameters, which is harmless here.

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-free but concrete resource — the weekly report as the customer receives it — and enumerates its contents (what moved, what was published, what to do next). It also anchors it to the Weekly Report page. It does not name or contrast any sibling, but none of the listed siblings (my_traffic, my_visibility, generate) is a close substitute, so the lack of differentiation costs little.

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 prerequisites, and no statement of when an agent should prefer this over neighbours like my_traffic or my_actions. Usage is only implied by the tool name and the 'as the customer receives it' framing.

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

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

Annotations already declare destructiveHint=true and idempotentHint=true, so the safety profile is covered. The description adds real behavioral insight beyond them: the reason is consumed by a discovery pass, and omitting it causes the competitor to be re-added on the next monthly run. It does not cover permissions or irreversibility.

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?

Front-loaded with the core action in one short sentence, then the reason guidance. The trailing clause ('which is the difference between removing it once and removing it every month') is rhetorically padded but does reinforce the consequence, so it earns its place only marginally.

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 2-parameter, no-output-schema tool with safety annotations already present, the description covers purpose, the required parameter, and the side effect of the optional parameter. It omits edge cases like unmatched names, but nothing an agent needs in order to call 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%, so baseline would be 3, but the description adds semantics the schema lacks: the reason field feeds the discovery pass and materially changes the outcome ('removing it once vs every month'). That justifies a point above 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+resource ('Stop tracking a competitor'), which is unambiguous against the sibling add_competitor. It does not explicitly name a sibling or contrast with similar untrack-style tools, so it stops short of a 5.

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

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

Gives a conditional instruction for the reason parameter ('always pass the reason when the user gives one') but says nothing about when to choose this tool over alternatives such as untrack_question, or what predecessors are required. Usage is implied rather than specified.

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 the mutation profile (readOnlyHint=false, idempotentHint=false, destructiveHint=false), and the description adds useful downstream context — the content engine reads saved text when it writes. However, it doesn't address the practical consequences of idempotentHint=false (e.g., whether repeated saves accumulate duplicates) or what persistence/reversibility looks like, so it adds moderate value rather than rich detail.

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, front-loaded with the core purpose and followed by the usage trigger. The example list is a bit long but each item clarifies scope rather than padding.

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

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

For a one-parameter write tool with no output schema, the description covers purpose, trigger, and downstream effect. The only mild gap is not clarifying whether repeated saves append or overwrite, which matters given the non-idempotent annotation.

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

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

With a single parameter at 100% schema coverage, the schema already documents 'text' as 'What to remember, in the user's own words.' The description goes beyond that by enumerating the kinds of content worth saving, which meaningfully guides what to put in the parameter.

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

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

The description gives a specific verb ('Save') plus the resource ('something about the business that the crawl cannot see') and concrete examples of what qualifies (buyer identity, product limitations, positioning decisions). This is clearly distinguishable from siblings like add_competitor, generate, or track_question.

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

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

It states an explicit trigger: 'Use this whenever the user explains something about their business in conversation that the product would otherwise be guessing at.' That tells the agent both the when and the rationale, though it names no alternative tool or explicit when-not condition.

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

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

Annotations already declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false, so the safety profile is covered. The description adds real behavioral context beyond that: the action 'stops being offered and the next one takes its place,' telling the agent the visible side effect on the recommendation queue.

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 effect and followed by the trigger condition. Every sentence carries distinct information with no redundancy.

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

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

For a one-parameter, no-output-schema mutation tool whose destructive/idempotent traits are already in annotations, the description covers what the tool does, the resulting state change, and when to invoke it. Only the relationship to mark_action_done is left unspecified.

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 single 'action' parameter is fully documented in the schema as 'the action's title, or enough of it to identify one.' The description adds no matching or formatting detail beyond that, so the baseline 3 applies.

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

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

The description gives a concrete verb+resource: 'Turn down one of the brand's recommended actions,' which an agent can distinguish from mark_action_done (completing) and my_actions (listing). It stops short of naming a sibling explicitly, so it falls just under the top mark.

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

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

It states a clear trigger condition: 'Use this when the user says an action is not relevant or they do not want to do it.' That is explicit when-to-use guidance, but it never mentions the alternative (mark_action_done) for the opposite intent, so it is not a full routing instruction.

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 establish it is a mutation (readOnlyHint=false) and idempotent, but the description adds genuinely new behavior: the question is swept weekly across every engine, re-adding restores prior runs, and the call is refused with the limit named when the plan is full. That is real context the 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?

Three short sentences, front-loaded with the core action, then trigger, then edge-case behavior. Every sentence carries information an agent needs; none is 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 single-param mutation with no output schema and clear annotations, the description covers purpose, trigger, side effect (weekly sweep), idempotent re-add semantics, and the refusal path. An agent has everything needed 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?

Only one parameter and schema coverage is 100%, so the schema already documents the argument and gives an example. The description adds no syntax or format constraints beyond the schema (baseline 3 for a fully-covered single param).

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 ('Start tracking a buying question') and adds scope the siblings need ('for the connected brand, so it is asked of every engine on the next weekly sweep'). This separates it cleanly from untrack_question, my_questions, and my_question_history.

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 an explicit trigger ('Use this when the user says they want to track, add, watch or measure a question') plus a state-dependent rule for re-adding a removed question. It also names the failure condition (plan full). Nothing 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?

Beyond the annotations (destructive=true, idempotent=true), the description adds the crucial nuance that the measured history is retained and the question can be re-added later, and it discloses the ambiguity-refusal behavior. This meaningfully softens the destructiveHint and is exactly the extra context the 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?

Three tight sentences, front-loaded with the action, each carrying distinct information (scope, reversibility, matching semantics) with no waste.

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

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

For a one-parameter mutation tool whose annotations already cover safety and idempotency, the description fully covers reversibility, input-matching rules, and error behavior; nothing an agent needs to call 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%, so the baseline is 3, but the description goes further by explaining that the question text should be given as the user says it, that an exact match or unique fragment both work, and that ambiguous inputs are refused with candidates listed.

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 precise verb+resource ('Stop tracking a question') scoped to the connected brand, and it is unambiguously the inverse of the sibling track_question. An agent can identify it without opening the schema.

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

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

It establishes the context of use (stopping tracking for the connected brand) and how to identify the target question, but does not explicitly point to track_question as the way to reverse the action or state a when-not condition.

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