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

Annotations already mark this as read-only and closed-world, and the description adds useful behavioral context: no model calls, no automatic recommendation labeling, and separation of prompt types and failures. It does not contradict the annotations, though it omits any return-format 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?

The description is two tightly written sentences with the core scope front-loaded. There is little waste, though 'transparent' is slightly vague and the second clause could be clearer.

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 a complex nested observations input, no output schema, and 0% schema description coverage. The description explains high-level scope and safety but says nothing about what the analysis returns or how the required inputs are structured, leaving too much implicit for reliable invocation.

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 carry parameter meaning. It hints at aliases, citations, prompt types, and failures, but leaves brandName, brandDomain, and most nested observation fields unexplained, which is insufficient for a four-parameter tool with a complex observations array.

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

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

The description uses a specific verb and resource ('Analyze caller-supplied answers') and clearly distinguishes the tool from model-querying siblings by stating it 'does not call models.' It also names concrete checks (brand alias and citation checks) that define the analysis scope.

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

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

The phrase 'caller-supplied answers' and 'does not call models' tells the agent to use this tool only when answers already exist, not to generate them. It does not explicitly name edgeo_query_model as the alternative for fetching answers, so it falls short of full when/when-not/alternative 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 and network reach are covered. The description adds genuinely useful behavioral boundaries the annotations cannot convey — no JS rendering, no CWV measurement, no indexing verification — which directly shapes interpretation of results. It does not describe the shape or size of what comes back.

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, with the core action and scope front-loaded and the limitations following immediately. Every clause carries distinct 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 single-parameter read tool with full annotations and schema coverage, the description covers what it does and what it explicitly does not do. The remaining gap is that there is no output schema and the description says nothing about the response structure, leaving the agent to discover the result shape at call time.

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 the schema documents it fully at 100% coverage ('Public HTTP or HTTPS page URL to inspect'), so baseline is 3. The description reinforces the public HTTP/HTTPS constraint but adds no format or validation detail beyond the schema's `format: uri`.

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 pair and resource: 'Fetch and audit one public HTTP/HTTPS HTML page,' with the signal domain (technical SEO, page structure) named. The 'one ... page' scope implicitly separates it from edgeo_crawl_site, but no sibling is named, so routing still requires a small inference.

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

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

The closing sentence gives explicit negative scope — no JavaScript rendering, no Core Web Vitals, no indexing verification — which tells an agent when this tool will under-deliver. It stops short of pointing to an alternative (e.g., use edgeo_crawl_site for multiple pages), so the when-to-use-instead half is missing.

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 openWorldHint=false, so safety is covered. The description adds real behavioral context beyond that: it only pairs 'complete' answers, it reports sample counts, and it explicitly does not infer causation or call AI providers — useful scope limits that prevent misuse.

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 matching precondition and followed by what is returned and what is out of scope. Dense but every clause carries information; 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?

Returns are summarized (paired mention and citation changes with sample counts), which is needed since there is no output schema. Still missing for a 5-parameter comparison tool: how before/after records are paired (id? normalized prompt?), what happens to unmatched records, and the role of aliases and brandDomain.

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 carries the burden, and it only partially does. It enumerates the matching keys (prompt, source, provider, model, surface, locale, search mode, prompt type) which map to fields inside the before/after items, but brandName, aliases, and brandDomain are never mentioned — an agent must guess how alias expansion or a brand domain affects mention matching.

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 — compare two sets of supplied AI answers — and specifies the gating condition (complete answers with matching normalized prompt, source, provider, model, surface, locale, search mode, prompt type). That distinguishes it from siblings like edgeo_analyze_visibility or edgeo_query_model, though it never names those siblings explicitly.

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

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

The description gives a validity precondition ('only when ... match'), which implies when a comparison is meaningful and implies that mismatched records are excluded. It does not state when to prefer this over edgeo_analyze_visibility or edgeo_query_model, nor what happens if no pairs match (error vs empty result).

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

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

Goes well beyond the readOnly/openWorld annotations by disclosing robots.txt compliance, crawl-delay application, no JavaScript rendering, no cross-host following, and bounded page count. These are exactly the behavioral traits an agent needs to anticipate results; only the crawl bounds and delay defaults themselves are left vague.

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 no filler, and the crawl scope is front-loaded before the behavioral caveats. Nothing redundant, though it could have carried a few more parameter words at no real cost.

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

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

For a tool with no output schema, the description says nothing about what a crawl returns (page records, issues found, statuses), and the two tuning parameters are unexplained. The behavioral framing is solid, but key call-shaping details are 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 only 33% – delayMs and maxPages have no descriptions at all. The description mentions 'bounded' and 'crawl-delay' but never explains that maxPages/delayMs control those bounds, whether delayMs overrides the robots.txt crawl-delay, or the default values, so it fails to compensate for the coverage 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?

States a concrete verb+resource ('bounded same-host HTML crawl') and defines the seed set (start URL plus same-host sitemap URLs). The 'same-host' scope cleanly separates it from edgeo_audit_page, which handles a single page.

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 scope constraints (same-host, HTML only, bounded) imply when it applies, but there is no explicit when-to-use or when-to-prefer-a-sibling statement, e.g. crawl here vs. audit_page for one page. Usage is inferable 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 cover read-only and closed-world safety; the description earns credit by adding what annotations cannot: processing happens in memory, files are neither uploaded nor persisted, and headers are auto-recognized in English and Indonesian. It does not cover behavior on unrecognized headers or size limits (only in schema), so not 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, no filler, and the core action is front-loaded ahead of the privacy caveat. Every clause contributes information.

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

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

With no output schema, the description should at least characterize the returned 'transparent summary' — it does not say what fields or counts come back. Combined with the undocumented columnMap and delimiter parameters, an agent has enough to call the tool but not to anticipate results or override parsing.

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% across three parameters, including a nested columnMap object with nine keys, so the description must carry the load. It hints that headers are auto-detected (implying columnMap is an override) but never mentions columnMap or the delimiter enum, leaving the two optional parameters unexplained.

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: parse a user-provided CSV/TSV Search Console export and return a summary. The 'user-provided ... in memory' framing implicitly separates it from API-backed siblings like edgeo_search_console_sites and edgeo_summarize_search_console, though it never names an alternative outright.

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 'user-provided CSV or TSV export' implies the case where the agent already has a local file rather than live API access, which is useful routing signal. But there is no explicit when-to-use/when-not or named alternative, so an agent must infer the boundary with the other Search Console 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 declare readOnlyHint and openWorldHint, so the safety profile is already covered; the description adds real value beyond them by disclosing that the Gemini path makes an external request requiring consent and a configured key. The caveat that provider output is not equivalent to a consumer AI app or Google AI Search result, with no citations assumed, sets correct expectations for downstream interpretation.

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 and providers before the consent condition and the interpretability caveat. Each sentence earns its place, though the final disclaimer is slightly compressed to the point of being cryptic ('no citations are assumed').

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 does sketch the return value as an observation for visibility analysis, which helps. But for a slow network-dependent model call with seven parameters and low schema coverage, it omits failure modes, timeouts/rate limits, expected prompt construction, and what the observation actually contains.

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 14% (just consentToExternalRequest is documented), so the description carries most of the burden, and it only clarifies the provider dimension (local Ollama versus external Gemini). The promptType enum values, locale, maxOutputTokens, and model naming conventions go entirely unexplained in both schema and 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 states a specific verb and resource ('Send one prompt to a configured local Ollama model or ... Google Gemini API') and names both provider paths, so the agent knows exactly what the tool does. It positions the result in the pipeline ('observation ready for EdGEO visibility analysis') but does not explicitly distinguish itself from siblings like edgeo_analyze_visibility, which consumes these observations.

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

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

Usage preconditions are stated for the Gemini path (explicit consent plus GEMINI_API_KEY configured), which is genuinely useful routing guidance. However, there is no explicit statement of when to call this versus edgeo_analyze_visibility or edgeo_crawl_site, and no guidance on how many prompts constitute a run. Usage is implied rather than spelled out.

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 the bar is lower, and the description still adds real value: it names the auth mechanism (OAuth read-only) and the required connect step, and warns that AI feature labels are never inferred from generic search rows, which sets expectations about what results will and will not contain. It stops short of describing row-count/limit behavior or data freshness/lag.

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 and followed by the prerequisite and the data-quality caveat; nothing is redundant. The multi-surface enumeration is slightly listy but each item earns its place by mapping to searchType values.

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 seven parameters, no output schema, and sparse schema descriptions, the description should carry more weight. It covers auth and one behavioral caveat but leaves an agent unable to reason about result shape, how dimensions combine, what aggregationType changes, or how rowLimit interacts with 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 only 14%, so the description must compensate for six undocumented parameters, and it largely doesn't. It implicitly covers searchType by naming the six surfaces, but dimensions, aggregationType, rowLimit, and the start/end date semantics (no timezone, no freshness, no range limits) are left unexplained in both schema and 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?

States a specific verb (query) and resource (the user's authorized Google Search Console property) and enumerates the search surfaces it covers (web, image, video, news, Discover, Google News), so the agent knows the shape of the returned data. It does not explicitly distinguish itself from close siblings such as edgeo_search_console_sites or edgeo_summarize_search_console, which leaves ambiguity about which Search Console entry point to pick.

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 prerequisite 'Requires `edgeo-mcp search-console connect`' is useful, and the mention of OAuth read-only access frames the operating context. However, there is no guidance on when to prefer this raw-rows query over edgeo_summarize_search_console or edgeo_search_console_sites, and no exclusions are 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 readOnlyHint=true and openWorldHint=true. The description adds useful context beyond annotations: the OAuth scope is read-only and results are limited to properties the authorized Google account can access. It does not mention return format, pagination, or failure behavior.

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 definition is a single tight sentence that front-loads the core action and then adds the setup prerequisite and scope constraint. 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?

For a zero-parameter listing tool with no output schema, the description covers the important call prerequisites and access scope. It could additionally describe the shape of returned properties, but the annotations already cover the safety profile and the tool is otherwise straightforward to invoke.

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

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

There are zero parameters, so the schema imposes no parameter-semantics burden. The description appropriately does not invent parameter details.

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

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

The description uses a specific verb-resource pair: 'List Google Search Console properties.' It scopes the result to the user's locally authorized account, making it distinguishable from query-oriented siblings like edgeo_search_console_query and edgeo_summarize_search_console.

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

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

It clearly states the prerequisite: prior setup with `edgeo-mcp search-console connect`. It does not explicitly name alternatives or exclusion conditions versus sibling tools, so it falls 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 establish read-only and closed-world behavior, and the description usefully adds that no Google connection is made and no AI feature is inferred from unlabeled data. It also discloses that position is impression-weighted, though it does not discuss validation limits or edge cases.

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-loaded with the core action and immediately followed by the key limitation. No wasted wording.

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 explains the broad input and output metrics, but with no output schema and a complex nested rows array, it leaves return shape and row-field semantics under-specified. It is adequate for tool selection but not fully complete for correct invocation.

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 carry more of the parameter burden. It adds useful semantics by indicating grouping by provided feature label and impression-weighted average position, but it does not explain the row structure, required fields, or behavior when feature labels are absent.

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: summarize user-supplied Search Console rows. It also distinguishes the tool from live-query siblings by saying it does not connect to Google and does not infer unlabeled AI features.

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

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

It clearly implies use when rows are already supplied and explicitly rules out live Google connection or inference from unlabeled data. It does not name specific sibling alternatives such as edgeo_import_search_console_csv or edgeo_search_console_query, so it falls short of fully explicit routing.

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