seo-analytics-mcp

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds useful behavioral context beyond annotations: the tool proactively names a command for the user to run, and it should be invoked as a first-line diagnostic after permission failures.

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 crisp sentences, front-loading the tool's outputs and then giving a concrete usage directive. Every word serves a purpose; no redundancy or 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?

The tool is simple, has no parameters, has an output schema, and is well-annotated. The description covers what it reports, when to call it, and what value the response provides, leaving no practical gap for an agent deciding to invoke it.

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

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

The tool has zero parameters and 100% schema coverage, so parameter documentation is irrelevant. Per the rubric, a zero-parameter tool gets a baseline of 4; the description correctly implies no inputs are needed.

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

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

The description uses a specific verb ('Report') and identifies the exact diagnostic resource: active profile, token scopes, and reachable Google APIs. This clearly differentiates it from the reporting and analytics sibling tools, which focus on data, not authentication state.

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 instructs the agent to call this tool first after a permission error and notes that the response names the exact terminal command. This provides an unambiguous trigger condition and practical guidance, which is more than enough for a zero-parameter diagnostic tool.

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

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

Annotations already mark the tool read-only, so the description correctly focuses on added behavioral detail: the join to Search Console and the path normalization rules (no host, no trailing slash, no query string). This goes beyond what the schema or annotations provide, though it does not discuss sampling or property selection.

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 dense, efficient sentences with no redundancy. The metric set and identity come first, and the path-normalization behavior earns its place as the key differentiator.

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

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

With an output schema and read-only annotations, the description covers core identity and join behavior well. However, with five undocumented optional parameters, the agent is left guessing about filtering, date handling, and property selection, and the description does not guide away from siblings like ga4_run_report.

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 0% and all five parameters are undocumented. The description only mentions the output path key and never explains top_n, start_date, end_date, property_id, or path_contains, so it fails to add meaning 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 names a concrete report — sessions, engagement rate, conversions, and revenue by landing page — and identifies it as the preset that joins to Search Console. It also distinguishes itself from gsc_search_analytics by explaining the shared normalized path key.

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 clearly implies this tool is for GA4 data joined with Search Console and that its path key is directly comparable to gsc_search_analytics rows. It stops short of explicitly naming sibling alternatives or saying when not to use it, but the join context is strong 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 and openWorldHint, so safety is covered. The description adds useful behavioral context: results are limited to what the Google account can read, and Universal Analytics properties will not appear because they are absent from the API.

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 tightly written sentences. The first states purpose and value; the second removes a common misunderstanding. No filler or repetition.

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

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

Complete for a parameterless list tool: it explains what is returned, the authorization scope, the ID-resolution purpose, and the exclusion of Universal Analytics. The existing output schema covers return structure.

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

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

The tool has zero parameters and schema coverage is 100% by default, so the description need not explain parameters. Baseline 4 applies for parameterless tools.

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 ('List') and resource ('GA4 accounts and properties'), and clarifies the purpose: resolving a property name to the numeric ID required by other GA4 tools. It also distinguishes itself from GA4 reporting tools and from Universal Analytics, which is explicitly excluded.

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?

Clear context: use this when you need to discover readable GA4 properties and map names to IDs. It does not explicitly name alternative tools or say when not to use it, but the purpose and scope strongly imply the correct usage.

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

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

Beyond the readOnlyHint and openWorldHint annotations, the description adds valuable non-obvious behavioral context: 400 errors mean incompatible metric/dimension pairs, dimension_filter and order_by require GA4 object dicts, and reports are generated in the property's timezone. This is precisely the kind of information an agent needs to interpret results correctly.

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?

Six sentences each carry distinct, necessary information: purpose, API-name caveat, compatibility error semantics, object formats, date formats, and timezone behavior. The description is front-loaded with the purpose and contains no repetition or 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?

The description covers the main non-obvious failure modes and formatting requirements, and the output schema means return values need no explanation. It could be more complete by addressing pagination and property_id selection, but these are minor given the schema defaults and the presence of an output schema.

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

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

With zero schema description coverage, the description compensates well by explaining GA4 API-name conventions, listing valid metric and dimension examples, specifying date formats, and clarifying filter/order_by object formats. It does not mention the limit or property_id parameters, but those are either self-evident or have schema defaults, so the compensation is strong but not complete.

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

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

The opening sentence uses a specific verb ('Run') and resource ('GA4 report'), explicitly names the underlying runReport method, and the word 'arbitrary' distinguishes it from more targeted sibling tools like ga4_landing_pages. An agent can immediately tell what this tool does and roughly how it differs from specialized report tools.

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

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

The description clearly frames this as the general-purpose/custom GA4 reporting tool, and the timezone note contrasts it with Search Console tools. It does not explicitly name sibling alternatives or provide a 'when not to use' statement, 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?

Beyond the readOnlyHint and openWorldHint annotations, the description discloses concrete behavioral details: window anchoring via offset_days, the direction caveat for position, and the fact that query rows are anonymized and will not sum to totals. This materially helps the agent interpret results correctly.

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 focused sentences convey purpose, window mechanics, and the key metric/dimension caveats without repetition or filler. The most important behavioral details 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?

Given the annotations, existing output schema, and the description's coverage of window semantics and special cases, an agent has enough information to select and invoke the tool correctly. The remaining implicit parameters are minor and inferable.

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 0% schema coverage, the description compensates well by explaining period_days, offset_days, metric values, and dimension caveats. top_n and site_url are left implicit, but their titles and defaults make them reasonably self-explanatory.

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: compare two consecutive Search Console periods and return the biggest movers in both directions. The 'what changed' framing clearly distinguishes it from siblings like gsc_search_analytics, which does not compare periods.

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

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

The description explicitly frames this tool as answering the 'what changed' question, giving a clear use case. It does not name specific alternatives or exclusions, but the intended context is clear relative to the sibling 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?

Beyond the readOnlyHint and openWorldHint annotations, the description discloses quota limits (2,000 calls/day/property), caching behavior (1 hour), and input validation constraints. This is meaningful behavioral context that materially affects when and how an agent should call the tool.

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

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

Two compact sentences front-load the tool's purpose and output, then provide constraints and quota/caching context. No filler or redundant restating of schema fields.

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

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

The description is largely complete given the output schema and annotations: it covers input constraints, expected output categories, rate limits, and caching. The main small gap is the undocumented site_url parameter, which prevents a perfect score.

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 0%, so the description must compensate. It explains that inspection_url must be a full URL belonging to site_url, but it leaves site_url's format, meaning, and optional/default behavior ambiguous. Partial compensation, with a clear gap on the site_url 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 states a specific verb and resource ('Inspect one URL's index status in Google') and enumerates the exact verdicts returned. This clearly distinguishes it from aggregate tools like gsc_search_analytics or sitemap tools.

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

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

The description provides clear usage context by warning that this tool has the tightest quota in the set and that results are cached, signaling it should be used judiciously. It does not explicitly name alternatives or state when not to use it, but context is sufficient.

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 readOnlyHint annotation already establishes this is a safe read operation. The description adds behavioral detail beyond that by revealing that the tool surfaces undownloaded sitemaps and reports warning/error counts, which helps the agent interpret the results. No contradiction with annotations.

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

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

Two sentences, each earning its place. The first identifies the tool's core action and result fields; the second adds practical diagnostic value. Information is front-loaded and there is no wasted text.

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 is simple and the output schema exists, so return-value documentation is not the description's burden. However, the one input parameter is undocumented in both the schema and the description, leaving an agent unsure how to specify the property. This is a clear completeness gap for a tool with a single important argument.

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

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

The schema has one parameter, site_url, with no description and 0% schema description coverage. The description only says 'for a property' and never explains that site_url is the property identifier, what format it should take, or whether it is required. The description fails to compensate for the schema's complete lack of parameter documentation.

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

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

The description names a specific verb and resource: 'List the sitemaps submitted for a property.' It further specifies the output content (last downloaded date, warnings, errors), which makes the tool's purpose unambiguous and distinguishes it from siblings like gsc_list_sites or gsc_submit_sitemap.

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 diagnostic context: a sitemap never downloaded by Google or one with errors is likely the answer to 'why isn't this indexed.' This tells the agent when the tool is useful, though it does not explicitly name alternatives or state when not to use 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 establish readOnlyHint=true and openWorldHint=true. The description adds useful behavioral context beyond annotations: it lists the permission-level-inclusive return, the need to pass the returned string to sibling tools, and the distinct string formats for domain versus URL-prefix properties.

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 three purposeful sentences with no filler. It front-loads the core action, then the critical 'call this first' guidance, then the property format details. Every sentence contributes directly to correct invocation and downstream use.

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

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

Given the tool has no parameters, a read-only annotation, and an output schema, the description is complete. It covers what the tool does, why it must be called first, how its output feeds other tools, and how to recognize the two property types.

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 schema makes parameter semantics moot. The description still adds relevant semantic detail about what will be returned and how those return values will be used as site_url parameters elsewhere, which compensates well for the empty 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 names a specific verb and resource: 'List the Search Console properties this Google account can read, with the permission level held on each.' It clearly differentiates this tool from siblings like gsc_list_sitemaps and gsc_search_analytics by focusing on property enumeration and access level.

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

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

The description explicitly instructs agents to 'Call this first in any session' and explains that the exact string returned is required by every other Search Console tool as site_url. This is strong, practical guidance on when and why to use the tool before alternatives.

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

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

Beyond the readOnlyHint annotation, the description discloses important behavioral details: date range echoing in summary.date_range, data_state 'all' being fresher but unstable, and the critical anonymization caveat that query-dimension rows do not sum to property totals. This last warning prevents a real misuse of the data and adds significant value beyond annotations.

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

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

The description is dense but every sentence contributes: metrics, date handling, dimensions, filters, search_type, data_state, and the aggregation caveat. It is front-loaded with the core purpose and avoids filler or repetition.

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

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

Given the tool's 8 optional parameters and existing output schema, the description covers all critical usage aspects: date formats, dimension values, filter syntax, search_type options, data freshness semantics, and a non-obvious data-caveat. The only lightly covered parameters are row_limit and site_url, but they are self-evident or covered by sibling tools like gsc_list_sites.

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 0% schema description coverage, the description carries the full explanatory burden and succeeds. It explains date formats, default dimensions, filter syntax with an example, valid search_type values, and the meaning of data_state values. These semantics go far beyond the bare property titles in 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 opens with a specific verb and resource: 'Query Search Console performance data: clicks, impressions, CTR, position.' It clearly identifies what the tool returns and the metrics involved, making it easy to distinguish from siblings like gsc_list_sites or gsc_inspect_url. The mention of dimensions and search types further sharpens the tool's identity.

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 clearly establishes the context for using this tool: querying Search Console performance data with configurable dates, dimensions, filters, search types, and data states. It does not explicitly name alternatives or state when not to use it, but the intended use is unambiguous given the detailed parameter 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?

The description goes well beyond the annotations by disclosing that it writes to the user's live property, requires a non-default write scope, performs a dry run unless confirm=true, and must be preceded by user agreement. These are critical behavioral details that annotations alone do not provide.

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

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

Every sentence earns its place: the action, the live-write warning, the scope prerequisite, the dry-run confirmation flow, and the feedpath format requirement. The most important warning is front-loaded in all caps, and there is no filler.

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

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

The description covers the destructive nature, auth requirement, dry-run behavior, confirmation process, and feedpath format, which is strong for a write operation. It only omits guidance on the optional site_url parameter, but the output schema likely clarifies return shape and the tool remains safely usable without that detail.

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 0% schema description coverage, the description adds meaning for feedpath by requiring it to be the full sitemap URL, and it clarifies confirm's role in gating the real write. However, site_url is not explained, leaving one parameter undocumented.

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 verb and resource: submit or re-ping a sitemap to Search Console. It does not explicitly contrast with sibling tools like gsc_list_sitemaps, but the action and target are 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 description gives clear context and a concrete usage workflow: run as a dry run first, show the user, then call again with confirm=true after explicit agreement. It also warns that the write scope is not granted by default, though it does not list alternatives or when-not-to-use conditions.

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 critical behavior beyond annotations: it 'ACTS ON THE LIVE WEB and cannot be undone,' the token is bound to a precise URL list, and per-endpoint HTTP statuses are returned verbatim because different statuses have different meanings. This complements the destructiveHint annotation rather than contradicting it.

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

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

Every sentence earns its place: live-web danger, dry-run flow, token binding, engine coverage, and status-code semantics. The most important operational constraint 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?

Given the complexity and the presence of an output schema, the description covers the main invocation path well. The only notable gap is the lack of guidance for host and endpoint, but these have defaults and are not required, so the overall definition is still highly usable.

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 0%, so the description must compensate. It explains confirm, submission_token, and urls through the dry-run/confirmed workflow, but host and endpoint are left undocumented in both schema and description. This is partial compensation for a five-parameter 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?

The description states a specific verb and resource: 'Submit URLs to IndexNow so participating search engines recrawl them.' It also distinguishes this from siblings like indexnow_verify_key by describing the actual submission action and live-web effect.

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 workflow instructions: call without confirm for a dry run, show the dry run to the user, then call with confirm=true and the exact submission_token. It also warns that Google does not participate, clarifying when this tool will not help.

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

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

Annotations already provide readOnlyHint=true, and the description adds useful non-obvious behavior: the key comes from configuration, is never passed in, and the tool verifies several specific HTTP/content conditions. It does not overstate behavior or contradict 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?

Three tightly packed sentences with no filler. The purpose is front-loaded, followed by usage guidance and a valuable parameter-related clarification.

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

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

For a two-parameter read-only diagnostic tool with an output schema, the description covers purpose, behavior, and usage context well. However, the semantics of host and key_location remain undocumented, which leaves ambiguity for an agent deciding whether to pass them.

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 0%, so the description must compensate. The only useful clue is that the key is read from configuration, but the two parameters host and key_location are never explained, including whether they override the configured defaults or how they interact with each other.

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 ('Check') and resource ('this host's IndexNow key file'), plus concrete success criteria (reachable, HTTP 200, served as text, exactly configured key). This clearly differentiates it from the submission-oriented sibling indexnow_submit.

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 says to use this tool to diagnose a rejected submission and notes that submissions already run this check and abort on failure. It gives clear context but does not name an alternative tool or state when not to use 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 declare readOnlyHint=true and openWorldHint=true, and the description adds valuable behavioral detail beyond that: GA4 and index status are best-effort, and if GA4 is unauthorized or the property is unknown, the Search Console half is still returned with a note. This partial-failure behavior is not present in 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 compact and front-loaded: the first sentence summarizes what the tool returns, the second gives a concrete use case, and the second paragraph explains the only important caveat. Every sentence 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?

An output schema exists, so return values are covered, and the description explains fallback behavior. However, with four parameters and zero schema descriptions, the lack of any parameter semantics is a clear gap: an agent cannot confidently know why site_url and property_id are needed or how days affects the report.

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 0%, so the description must compensate, but it does not define any of the parameters: url, days, site_url, or property_id. The only indirect clue is 'one page,' which does not meaningfully explain the required url param or the optional disambiguation params.

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 exactly what the tool does: aggregates Search Console clicks/impressions trend, top queries, GA4 engagement, and index status into one call. It also gives a concrete trigger example ('how is /pricing doing?'), which clearly distinguishes it from narrower siblings like gsc_search_analytics or ga4_run_report.

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

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

The description explicitly says when to use this tool ('Use this for...'), providing clear context. However, it does not explicitly say when not to use it or name alternative sibling tools, leaving some routing decisions to inference.

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