CalmSEO

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

The annotations already convey that the tool is not read-only, not idempotent, and destructive. The description adds meaningful behavioral context by specifying that it 'consumes 5 CalmSEO credits' and that it 'avoids full-site crawl task queues', which explains the resource impact and execution model beyond what annotations offer. It does not contradict 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 compact sentences, each carrying essential information: the core function and the key distinguishing constraints (avoids full-site crawl, consumes 5 credits). There is no redundancy or filler. The main purpose is 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 selection and invocation, the description is sufficient: it identifies the input (URL), the cost, and the execution context. However, there is no output schema and the description does not indicate what kind of audit report is returned or how the results are structured. An agent would need to discover the output format after calling or rely on separate documentation. Given the tool's moderate complexityholistic, this is a notable gap.

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

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

Schema coverage is 60%; the boolean parameters are well-described in the schema, and the description clarifies the sole required parameter (`url`) by emphasizing 'Single URL'. However, the `accept_language` parameter remains undocumented in both schema and description, and the description adds no further parameter-level guidance beyond what the schema already provides. This is adequate but not exceptional.

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 states a specific action ('on-page SEO audit') on a specific resource ('Single URL') and identifies the underlying service ('DataForSEO Instant Pages'). It distances itself from 'full-site crawl task queues', which differentiates it from a broader audit workflow and from the unrelated sibling tools (keyword, GSC, SERP tools). This is unambiguous and immediately distinguishes the tool's purpose.

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

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

The description provides clear context for when to use the tool: for a single URL audit, avoiding the overhead of a full-site crawl. It also mentions the credit cost, which is relevant for decision-making. However, it does not explicitly name an alternative tool or state 'use X instead', leaving the contrast with a full-site crawl tool implicit rather than explicit.

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

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

The description discloses the credit consumption (15-50 CalmSEO credits), which is a behavioral trait not covered by annotations. However, it does not address the destructiveHint=true annotation; it neither confirms nor explains what destructive action may occur. With annotations present, the description adds some value but leaves ambiguity about side effects.

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 concise, two sentences, with the primary purpose stated first and the credit consumption as a secondary detail. It avoids fluff and is easily scannable. It earns its place by communicating the core function and a key operational constraint.

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

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

For a tool with 7 parameters, no output schema, and low schema coverage, the description is insufficient. It does not explain what the response looks like, how to use limit/offset, what closely_variants does, or how to interpret results. An agent would lack critical information to invoke the tool correctly, especially with destructiveHint=true remaining unexplained.

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 only 29% (only language_name and location_name have descriptions). The description does not explain key parameters like limit, offset, keywords, closely_variants, or include_serp_info. The only implicit reference is to 'result limit' in credit consumption, which hints at the limit parameter but provides no concrete syntax or semantics. This fails to compensate for the low 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 clear purpose: 'DataForSEO Labs keyword ideas for expanding seed keywords into a research set.' It identifies the specific resource (keyword ideas) and the action (expanding seed keywords). It does not explicitly differentiate from siblings like search_serp or get_keyword_search_volume, but the function is distinct enough that an agent can infer its role.

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 guidance is provided on when to use this tool versus alternatives. It does not mention specific use cases, prerequisites, or conditions that would lead an agent to choose it over siblings like search_serp or get_keyword_search_volume. The purpose is clear but the decision context is absent.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description does not need to restate safety. It adds that the result is query-level data associated with clicks and impressions, but it does not disclose aggregation behavior, date-boundary semantics, or any other operational quirks.

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, front-loaded sentence with no filler or repetition. It is concise and easy to scan, though its brevity comes at the cost of parameter and routing guidance.

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 should explain what the tool returns and any important result details. It only says 'queries that drove impressions and clicks,' leaving out ordering, grouping, and exact returned fields. The schema covers parameter types and limits, but the absence of return-structure guidance makes this incomplete for a 6-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 only 17%, with only site_url documented in the schema. The description adds no meaningful explanation for start_date, end_date, row_limit, type, or page_url beyond names and obvious context. Since low schema coverage places a heavier burden on the description, this is a clear gap.

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

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

The description uses a specific verb ('Get') and resource ('Google Search Console queries') and narrows scope to 'one page URL,' which clearly conveys intent. It differentiates from siblings like get_gsc_top_pages and get_gsc_top_queries through the page-level focus, though it does not explicitly name those 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?

The phrase 'for one page URL' provides a clear context for when this tool is appropriate. However, the description does not explicitly contrast it with query_gsc_search_analytics or get_gsc_top_queries, so usage guidance is implied rather than stated as a routing rule.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety behavior is covered. The description adds some transparency by naming the returned metrics, but it does not clarify ordering, date handling, row limits, or response 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?

A single sentence that is front-loaded with the core action and resource. No filler or repetition; it is appropriately sized for its role.

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 gives a minimal sense of what is returned but omits sorting behavior, date-range semantics, and the meaning of 'top'. It is adequate for a simple read-only retrieval but leaves several operational details 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 only 20%; site_url is documented but start_date, end_date, type, and row_limit are not. The description mainly restates 'property' and mentions output metrics, adding little semantic meaning for the parameters beyond what the schema already 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?

States a specific verb and resource: gets Google Search Console pages for a property. It also lists the output metrics (clicks, impressions, CTR, average position), which distinguishes it from siblings like get_gsc_top_queries or get_gsc_page_queries.

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 purpose implies use when page-level GSC performance is needed, but the description does not explicitly say when to choose this over alternatives such as get_gsc_top_queries or query_gsc_search_analytics. Context is clear but routing guidance 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=true and destructiveHint=false, so the safety profile is covered. The description adds that results include clicks, impressions, CTR, and average position per query, which gives some behavioral context, but it does not mention grouping/sort semantics, date-window behavior, row-limit effects, or response 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?

The description is a single front-loaded sentence with no filler or repetition. Every word contributes to the core purpose, which is exactly what this dimension rewards.

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

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

With no output schema and only 20% schema parameter coverage, the description carries a heavy burden that it does not meet. It omits necessary context about required date ranges, what 'top' means, how type affects results, and what output to expect, leaving a 5-parameter tool under-specified.

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 only 20% (site_url only), yet the description adds no parameter-level meaning for start_date, end_date, type, or row_limit. 'For a property' and 'by clicks...' do not compensate for the missing date-range and type semantics, so an agent must infer key meanings from names and patterns.

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 names the resource (top queries) and metric dimensions (clicks, impressions, CTR, average position), so an agent can tell it targets query-level GSC data. It does not explicitly differentiate it from siblings like get_gsc_page_queries or query_gsc_search_analytics, 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?

There is no guidance on when to prefer this tool over get_gsc_page_queries, get_gsc_top_pages, or query_gsc_search_analytics, nor any exclusions or prerequisites. The only usage signal is the phrase 'top queries,' which essentially restates the tool's name.

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 description mentions the 15-credit cost, which is a side effect, but it contradicts the annotations: destructiveHint is true and readOnlyHint is false, yet the tool is described as a data lookup. There is no disclosure of any destructive action or non-read-only behavior, so the description directly contradicts the annotation set. This is a serious inconsistency.

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 concise sentences with no redundancy. The primary purpose is stated first, and the credit cost is a valuable extra detail. Every word 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?

The tool has 5 parameters and no output schema, yet the description does not clarify the return format (e.g., per-keyword objects, aggregate metrics). It also fails to reconcile the contradictory annotations. For a moderately complex batch tool, this is incomplete; an agent would need more detail on response structure and the meaning of the boolean flags.

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 descriptions cover 60% of parameters (keywords, language_name, location_name), providing some meaning. However, the description itself adds no parameter-level details, and the boolean parameters (search_partners, include_monthly_searches) are undocumented in both the schema and the description. With coverage in the mid-range, the description does not compensate for the missing guidance on these flags.

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 states the tool's function: retrieving Google Ads keyword search volume, CPC, and competition for a batch of keywords. This is specific and distinct from sibling tools like find_keyword_ideas or get_ranked_keywords, which focus on idea generation or ranking data. The verb 'get' is implied, and the resource is explicitly named.

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

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

The description provides no guidance on when to use this tool versus alternatives. It does not mention scenarios like 'when you need volume/CPC metrics' or compare with find_keyword_ideas or search_serp. The agent must infer the appropriate context from the tool's purpose alone, which is insufficient.

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 carry readOnlyHint=false and destructiveHint=true, and the description adds a useful cost side-effect: 'Consumes 5-20 CalmSEO credits depending on the result limit.' It does not explain what destructive behavior might occur beyond credit consumption, but it does not directly contradict 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?

The description is short and mostly front-loaded: the core function comes first and the cost warning is a useful second sentence. The grammatical issue in the first sentence hurts clarity slightly but does not hurt conciseness or structure.

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 7 parameters and no output schema, the description leaves significant gaps: no pagination/ordering details, no explanation of item_types or historical_serp_mode, and no sense of the response shape. The credit-cost disclosure is helpful but not enough for a tool of this complexity.

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 only 43%, so the description needed to compensate. It only adds meaning for the 'limit' parameter by linking it to credit consumption; item_types, historical_serp_mode, and offset remain unexplained in both the schema and the description.

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

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

The description names the resource (keywords a domain ranks for in Google) and the target shape (domain, subdomain, or URL), which is specific enough to distinguish from keyword-idea or search-volume tools. It lacks a crisp imperative verb and does not explicitly contrast sibling tools, so it misses 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?

The description implies the core use case: look up the Google keywords a specific domain currently ranks for. It gives no explicit 'use this when...' guidance and never names alternatives or exclusion conditions, so it only reaches the implied-usage level.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows this is a safe read operation. The description adds that it lists 'submitted' sitemaps, which clarifies the scope. However, it doesn't disclose what happens if no sitemaps are submitted, whether the response includes sitemap status/details, or any rate-limit considerations. With annotations covering the safety profile, a 3 is appropriate.

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, concise sentence that front-loads the action and resource. There is zero waste, and every word earns its place. The parameter schema carries the additional context, keeping the description appropriately minimal.

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 list tool with one parameter, the description plus schema is nearly complete. The schema covers the parameter fully, and annotations cover the safety profile. The only minor gap is that the description doesn't mention what the output looks like (e.g., list of sitemap URLs, statuses), but since there is no output schema, a bit more detail on return values could help. Still, the tool is simple enough that this 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 the schema already documents the single parameter (site_url) with a clear example and a pointer to list_gsc_sites. The description itself doesn't add parameter-level detail beyond what the schema provides. Baseline 3 is correct when the schema does the heavy lifting.

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 ('List') and resource ('submitted Google Search Console sitemaps') for a connected property. It is clear about what the tool does, though it doesn't explicitly distinguish itself from sibling tools like list_gsc_sites or query_gsc_search_analytics. The title and description align well.

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 usage context: it is for listing sitemaps for a connected property. The parameter description for site_url explicitly says 'Use list_gsc_sites to choose an available property,' which provides a clear pointer to a sibling tool for selecting the property. However, it doesn't explicitly state when not to use this tool or mention alternatives for other sitemap-related operations.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, lowering the bar. The description adds genuine behavioral context beyond annotations by disclosing that the result set includes both sc-domain and URL-prefix property types. It doesn't cover pagination or authentication details, but for a zero-parameter read-only tool with annotations carrying the safety profile, this is solid coverage.

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

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

A single front-loaded sentence with no filler: the verb and resource come first, and the 'including...' clause earns its place by clarifying the scope of returned property types. Appropriately sized for a zero-parameter tool.

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

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

For a zero-parameter, read-only list tool with safety annotations, the description adequately states what is returned and at what scope. There is no output schema, so some description of return content is needed, and naming both property types gives the agent a reasonable expectation of the response. Minor omissions like return format and empty-result behavior are acceptable at this complexity level.

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

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

The tool has zero parameters, so the baseline of 4 applies. There are no parameter semantics for the description to document, and the input schema is trivially complete at 100% 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 uses a specific verb-resource pair ('List Google Search Console properties connected to this CalmSEO account') and further specifies the scope by naming both property types returned (sc-domain and URL-prefix). This clearly differentiates it from the closest sibling, list_gsc_sitemaps, which targets sitemaps rather than properties.

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 'connected to this CalmSEO account' implies a selection context (enumerate the account's linked GSC properties before choosing one to query), but the description never explicitly states when to prefer this tool over siblings or when not to use it. No exclusions or alternative routing are provided, so usage guidance is only implied.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds one behavioral trait: data is delayed by 2-3 days, which is useful. However, it does not disclose other behaviors like pagination, rate limits, aggregation effects, or how the data_state parameter affects results. With annotations covering the read-only nature, the description adds some but not rich context.

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 extremely concise: two short sentences, with the core purpose front-loaded and the delay note appended. Every word earns its place. There is no fluff or repetition, and it is easy to parse quickly.

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?

This is a complex tool with 10 parameters (4 required), no output schema, and only 10% schema description coverage. The description does not explain how to construct valid queries, what the dimensions and filters options mean, the significance of aggregation_type, or the meaning of data_state. It also lacks information about response format or pagination behavior. For an agent to use this correctly, it would need substantial external knowledge. The description is severely inadequate.

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 only 10% (only site_url has a description). The description mentions the metrics returned (clicks, impressions, CTR, average position), which indirectly hints at what the tool returns, but it does not explain how parameters like dimensions, filters, aggregation_type, or data_state work. The schema has enums but no descriptions for most properties, and the description does not compensate for this gap. It adds minimal semantic value beyond the schema.

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

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

The description clearly states the tool queries Google Search Console Search Analytics for clicks, impressions, CTR, and average position. It names the resource (GSC Search Analytics) and the specific metrics, distinguishing it from generic tools. However, it does not explicitly differentiate it from sibling tools like get_gsc_top_queries or get_gsc_top_pages, which are more specialized, so it doesn't fully clarify when this general query tool is preferred.

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

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

The description provides no guidance on when to use this tool versus alternatives such as get_gsc_top_queries, get_gsc_top_pages, or get_gsc_page_queries. It does not mention any exclusions or conditions that would route an agent to a different tool. The only contextual note is the data delay, but that is about data freshness, not usage selection.

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

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

Annotations provide destructiveHint=true and readOnlyHint=false, but the description adds the concrete consequence of consuming 1-3 CalmSEO credits depending on depth. This is valuable beyond the structured hints, as it warns the agent about a resource cost. It does not elaborate on the destructive hint, but the credit consumption is a meaningful disclosure in itself, so the bar is met.

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, zero filler. The core action and resource are front-loaded, followed by a concise note on what it returns and the credit cost. Every word earns its place; no restructuring would improve it.

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 6-parameter tool with no output schema, the description is minimal. It states the return type ('compact ranking results') but does not hint at the result fields or any pagination/error behavior. The main parameters are covered by the schema, but the overall context for an agent deciding how to interpret the response is thin. Adequate but not comprehensive.

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 67% (4 of 6 parameters have descriptions). The description mentions keyword, location, language, and depth, which aligns with the schema, but it does not provide additional semantics for the two uncovered parameters (device, search_engine). The phrase 'Google or Bing' does hint at search_engine, but not enough to fully compensate for the missing schema descriptions. This sits at the baseline for moderate 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 opens with 'Live Google or Bing organic SERP search', a specific verb and resource, and goes on to say it returns compact ranking results. This clearly distinguishes it from sibling tools like get_gsc_top_queries or find_keyword_ideas, which focus on analytics or keyword suggestions. No ambiguity remains about what the tool does.

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

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

The description implies real-time use ('Live') and names the supported engines, but gives no explicit guidance on when to choose this tool over alternatives. It does not mention any exclusions or point to siblings, so the agent must infer the context from the stated behavior. This is adequate but not explicit.

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