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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is fully covered. The description adds only 'paginadas desde 0', which duplicates the schema's page default/minimum of 0, and says nothing about page size, result caps, or how to detect the last page.

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

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

A single short sentence with zero filler, and the core purpose is front-loaded. It is arguably too terse for a paginated listing tool, but nothing is wasted.

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

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

Low complexity (2 params, no nesting, no output schema) and annotations cover the safety profile, so the bar is modest. Still, a paginated listing tool should state the page size or termination condition so the agent knows how to iterate, and the description omits both.

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 50%: siteUrl is documented in the schema, page is not. The phrase 'paginadas desde 0' does confirm zero-based paging, which slightly reinforces the page parameter, but it adds nothing the schema's default/minimum doesn't already imply and gives no page-size or offset semantics.

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

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

States a specific resource and filter: site pages that receive inbound links, sourced from Bing. It is understandable without opening the schema, but it never distinguishes itself from the close sibling bing_backlink_sources (sources of links vs. pages receiving them), leaving the agent to infer the difference.

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

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

There is no when-to-use guidance, no mention of prerequisites (a verified property), and no reference to any alternative such as bing_backlink_sources or bing_url_info. The agent must guess which backlink tool to pick.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description's only added context is the data source (Bing rather than GSC), which is genuinely useful, but it says nothing about result caps, pagination depth, or whether the two URL inputs must match.

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 compact sentence with no filler. It is efficient but arguably under-specified rather than truly concise, since nothing about usage or paging 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?

With no output schema, the description should clarify the shape and volume of results (backlink URL + anchor per row) and the paging contract, but does neither. For a three-parameter, open-world reporting tool, this leaves the agent guessing about result limits.

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% and the undocumented parameter is `page`, which controls pagination with a 0–32767 range — the description says nothing about paging or how many link sources are returned per call. It adds no meaning beyond the schema's own siteUrl/link descriptions.

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

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

The description names a specific resource — the URLs and anchor texts that link to a given site page, per Bing — so an agent knows what data comes back. It is a noun phrase rather than a verb-led statement and never contrasts itself with the close sibling bing_backlink_pages, so the purpose is clear but not fully disambiguated.

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 call this versus bing_backlink_pages, bing_url_info, or any GSC equivalent. No prerequisites (verified property, Bing Webmaster auth) or exclusion conditions 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 readOnly, idempotent, openWorld, non-destructive, so the safety profile is covered structurally. The description adds nothing beyond that: no mention of what the listing contains, whether results are capped by limit or paginated, or the ordering of returned issues.

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

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

It is a single short sentence with no filler, so nothing is wasted—but it is under-specified rather than genuinely concise, and it is not front-loaded with any actionable scope or 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?

No output schema exists, so the description must carry the burden of explaining what is returned (issue types, per-URL detail, truncation behavior at the limit). It does none of that, leaving an agent guessing about the result shape.

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 only 50% schema coverage, the description should compensate for the undocumented 'limit' parameter (default 100, max 1000) but says nothing about it. 'siteUrl' is documented in the schema, so the description adds zero parameter meaning.

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 ('Problemas de rastreo detectados por Bing') essentially restates the tool name bing_crawl_issues, only adding that the source is Bing. It does not specify what a 'crawl issue' includes (errors, blocked URLs, redirects) or how it differs from sibling diagnostics like bing_crawl_stats or gsc_inspect_url.

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

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

No guidance on when to use this versus bing_crawl_stats, seo_audit_site, or gsc_inspect_url, and no prerequisites (e.g., verified property) are stated beyond the schema field. Usage is only implied by the 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?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is fully covered elsewhere and the description needed to add something else. It adds nothing: no time-range behavior, no aggregation semantics, no note on what the stats cover or whether results are fresh. Purely a label.

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 short, front-loaded sentence with zero filler — but the brevity here is under-specification rather than economy. There is nothing to trim; the problem is that almost nothing is there.

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?

No output schema exists, so the description carries the full burden of explaining what these statistics contain (crawl requests, errors, latency, date windows). Given a crowded sibling set with an adjacent tool (bing_crawl_issues), the definition is not complete enough for reliable selection.

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 (siteUrl) with 100% schema description coverage, so the schema alone explains that the exact URL of a verified property is required. The description adds no additional meaning, but the high coverage baseline makes 3 appropriate.

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

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

The description is essentially the tool name rendered in Spanish: 'estadísticas de rastreo de Bing' restates 'bing_crawl_stats' without adding a verb, scope, or data shape. It does confirm the domain (Bing crawl data) but an agent gets no more signal than the name alone already provides, and it does not distinguish the tool from siblings like bing_crawl_issues.

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

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

There is no when-to-use guidance, no prerequisite (beyond the required verified property URL), and no mention of when to prefer bing_crawl_issues or gsc_search_performance instead. The agent must infer selection from the name alone.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds nothing beyond that — no indication of what 'detalle' contains, whether it errors for an unverified property, or how it behaves if feedUrl is a sitemap index versus a child sitemap.

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

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

One short sentence with no filler, which is efficient, but the brevity here reflects under-specification rather than disciplined concision. There is no structure to front-load because there is only a single noun phrase.

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 schema and annotations cover parameters and safety, but for a tool whose entire value is the returned feed detail, the description leaves the agent guessing what distinguishes it from bing_sitemaps and what 'detail' includes (submitted URLs, crawl status, last read date). There is no output schema, so the description was the only place to convey this.

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% — both siteUrl ('URL exacta de la propiedad verificada') and feedUrl ('URL completa que pertenece al sitio') are documented in the schema. The description adds no additional meaning about their relationship or format constraints, so the baseline of 3 applies.

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

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

The description names the resource ('sitemap o índice de Bing') but uses only a noun phrase ('Detalle oficial') rather than a verb, so the operation is inferred rather than stated. It does clarify that a 'feed' is a sitemap or sitemap index, which is more than the name alone provides, but it does not distinguish this tool from siblings such as bing_sitemaps (listing) or gsc_sitemap_details (the Google equivalent).

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

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

There is no statement of when to use this tool versus bing_sitemaps, gsc_sitemap_details, or the other Bing tools in the sibling set. The agent must infer from the name alone that this retrieves a single feed's detail rather than enumerating feeds.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is covered. The description adds the useful fact that each entry carries a verification status, but says nothing about authentication requirements against Bing Webmaster Tools or how many sites come 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?

A single sentence with the resource front-loaded and no filler. Every clause (Bing Webmaster Tools + verification status) carries information the agent needs.

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 parameterless list tool with no output schema, telling the agent what the records contain (site + verification status) is adequate. However, nothing is said about auth requirements, result volume, or whether an empty list is possible, which are real gaps given openWorldHint=true.

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 zero parameters at 100% coverage, so there is nothing for the description to disambiguate. Baseline 4 applies; no parameter semantics are needed or missing.

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

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

Names a specific verb ("Lista") and resource ("los sitios de Bing Webmaster Tools") plus what is returned ("su estado de verificación"). The explicit "Bing" qualifier separates it from the sibling gsc_list_sites without needing to reference it by name.

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

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

The description never says when to call this versus the Google counterpart (gsc_list_sites) or when site data should be fetched another way. It offers no prerequisites, no ordering guidance, and no exclusions, leaving the agent to infer that this is a discovery entry point.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true and destructiveHint=false, so the safety profile is fully covered by structured data. The description adds nothing beyond that — it says nothing about what data comes back, whether results are aggregated by query, time-range limitations, or Bing API quotas.

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 short sentence with zero padding and the key resource front-loaded. It is efficiently structured, though the brevity borders on under-specification rather than optimal conciseness.

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 should say something about the returned data (queries with impressions/clicks? ranked list?) and disambiguate it from the many sibling query tools. Neither is present, so an agent cannot fully predict the result or confirm it picked the right sibling.

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%, with both pageUrl and siteUrl documented in the schema itself, so the baseline of 3 applies. The description does not clarify the relationship between the two parameters (that pageUrl must belong to siteUrl) beyond what the schema already states.

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 one-line description names a specific resource relationship (queries associated with a page) plus the data source (Bing), so an agent can tell it retrieves search-query data for a given URL. However, it never distinguishes itself from near-identical siblings such as bing_query_pages (the inverse relation) or bing_top_queries, leaving the agent to infer the difference from the tool names alone.

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

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

The description gives no when-to-use guidance, no prerequisites (e.g., a verified Bing property is required, implied only by the schema), and no mention of when to prefer bing_query_pages or bing_top_queries instead. The agent has to derive usage from the tool name and required parameters.

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

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

Annotations already declare readOnly/idempotent/openWorld/non-destructive, so the safety profile is covered. The description adds the crucial behavioral fact beyond annotations: this returns only URLs and cannot actually execute a scan, setting correct expectations about what the agent will receive. It could go further on the exact return shape, but the key limitation is disclosed.

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

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

One tight sentence with the resource front-loaded and the API caveat following. Nothing extraneous; the semicolon-joined clause is slightly telegraphic but earns its place by explaining the tool's existence.

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 one enum parameter, no output schema, and full annotation coverage, the description supplies nearly everything needed: what it returns (official links), why it exists (no API), and which two destinations are available. Only the concrete response shape (single URL vs. list) is left unstated.

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

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

Schema coverage is 0%, so the description carries the burden for the single 'tool' parameter. It names the two options ('Robots.txt Tester' and 'Site Scan'), which maps usable concepts onto the enum values robots_tester and site_scan — adequate compensation, but no detail on what each option yields or how the two differ in output.

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 resource — official links to Bing's Robots.txt Tester and Site Scan — rather than a data operation. The clause 'no tienen API pública' implicitly separates it from all the API-backed bing_* siblings that return metrics, so an agent can tell this is a link-provider, not a data-fetcher.

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

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

Usage is implied rather than stated: because no public API exists, this tool is the fallback when a user wants the robots tester or site scan. It never explicitly says when to choose it over a sibling like bing_crawl_issues or bing_sitemaps, nor does it say these links must be opened by the human user.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so safety and idempotency are covered. The description adds nothing further — no note on data freshness, whether the siteUrl must be a verified property, or how results are bounded. It does not contradict the annotations, but it earns no credit above the annotation baseline.

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 short sentence with no filler, so it is certainly concise. However, it is terse to the point of under-specification rather than being front-loaded with useful information; there is no structure to speak of.

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 lookup tool with no output schema, the description should at minimum say what a returned 'page' is and how results relate to the query. Annotations cover the safety profile, but the semantic gap around the query parameter and the sibling ambiguity leaves the definition incomplete.

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 50%: siteUrl is documented in the schema but query is a bare string. The description gestures at 'una consulta' but does not explain whether query is a keyword, a URL, or a Bing query syntax expression, and it adds nothing about the siteUrl scoping requirement that would 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?

The Spanish phrase 'Páginas asociadas a una consulta en Bing' identifies the resource (pages) and its link to a query, but uses no action verb and never says whether these are ranking pages, crawled pages, or indexed pages. It also fails to distinguish itself from the near-mirror sibling bing_page_queries, which appears to be the inverse relationship.

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

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

There is no statement of when to use this tool, no prerequisites, and no exclusions. With bing_page_queries and bing_top_pages sitting right next to it in the sibling list, the agent is left to guess which of the three answers a 'which pages relate to this query' question.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is fully covered. The description adds only that status information is returned alongside the list; it says nothing about scope, filtering, or result shape, which is acceptable but not enriching.

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

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

One short, front-loaded sentence with no filler. It is efficient, though its brevity leans toward under-specification rather than disciplined concision.

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-only tool with full annotation coverage and a documented param, this is close to sufficient. It still leaves unclear what the returned sitemap entries contain (counts, index status, warnings) and how it differs from the GSC equivalent.

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

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

Schema coverage is 100% and the single required parameter siteUrl is documented as "URL exacta de la propiedad verificada." The description adds no syntax, format, or constraint details beyond that, so the baseline 3 applies.

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

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

States a specific verb and resource ("Lista los sitemaps enviados a Bing") and adds the returned attribute ("su estado"). Naming Bing implicitly separates it from the sibling gsc_sitemaps, though the contrast is never made explicit.

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

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

Usage is only implied by the tool name: it is the Bing counterpart to gsc_sitemaps, but the description never says when to pick this over that sibling or what prerequisites apply beyond the schema's "propiedad verificada".

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

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

Annotations already declare readOnly, idempotent, openWorld, and non-destructive behavior, so safety is covered. The description adds one genuinely useful behavioral fact beyond annotations: the source refreshes weekly, implying data may be up to a week stale. It says nothing about result caps, ordering, or auth requirements for the verified property.

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

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

Two short sentences with zero padding and the resource statement front-loaded. It is efficiently sized, though efficiency here partly reflects under-specification rather than disciplined editing.

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 must convey what "top pages" returns and over what period, and it does not. An agent cannot tell the fields, ordering, or whether the weekly refresh means lagged data, which matters for a reporting tool with an undocumented limit parameter.

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 50%: siteUrl is documented in the schema, but limit (1-1000, default 100) has no description anywhere. The tool description adds no meaning about either parameter, 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?

"Páginas principales de Bing" essentially restates the tool name (bing_top_pages) without a verb or stating what data is returned (clicks, impressions, ranking?). It does not differentiate from close siblings like bing_page_queries, bing_top_queries, or gsc_page_performance.

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

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

No when-to-use guidance and no named alternatives among the many sibling page/query tools. The only extra information is a freshness note (weekly refresh), which is context rather than usage 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 readOnly, idempotent, non-destructive, open-world behavior, so the safety profile is covered. The description adds one piece of genuinely new behavior, the weekly data refresh cadence, but says nothing about ordering, row semantics, or what happens when limit exceeds available data.

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

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

Two short sentences with no filler and the resource stated first, so structure is fine. But the brevity comes from omission rather than discipline — the second sentence is the only substantive content and the rest is a bare label.

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

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

For a read-only reporting tool with no output schema, an agent still needs to know the ranking basis (clicks? impressions? average position?), the time window, and how it differs from bing_page_queries/bing_query_pages. None of that is present, leaving the tool under-specified for correct selection and 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 coverage is 50%: siteUrl has a description, but limit has only a default and min/max bounds with no stated meaning. The description contributes nothing about either parameter, not even that limit caps the number of returned queries, 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?

"Consultas principales de Bing" identifies the resource (top search queries) but only implies the verb (list/retrieve) and gives no notion of what makes a query "top" or over what period. It does not distinguish this from siblings such as bing_page_queries or bing_query_pages, which also return query data.

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

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

There is no when-to-use or when-not-to-use guidance and no mention of the nearby alternatives (bing_top_pages, bing_page_queries, bing_query_pages). The only contextual hint is the weekly refresh cadence, which does not tell an agent when this tool is the right pick.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is fully covered. The description contributes only the fact that data comes from the Bing API, without disclosing what fields are returned (index status, canonical, crawl date), whether the site must be verified, or any quota 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?

A single well-formed sentence with no redundancy, but it is undersized for the task: it front-loads the domain rather than the action, and stops before anything actionable is said. Brevity here reads as under-specification rather than economy.

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 must convey what comes back, yet it only says 'tracking and indexing information' without naming any returned concept. For a read tool in a dense SEO sibling set, that leaves the agent unable to predict whether results answer an indexation question or a crawl question.

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%, with both 'url' and 'siteUrl' documented as full URL and verified-property URL respectively, so the baseline is 3. The description adds no further semantics about the relationship between the two parameters or format constraints.

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 and domain ('Información de rastreo e indexación de una URL según la API de Bing'), so an agent can tell it returns per-URL indexing/crawl data from Bing. However, it never distinguishes itself from close siblings like gsc_inspect_url, bing_crawl_stats, or bing_crawl_issues, leaving the agent to infer scope from the name alone.

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

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

There is no explicit when-to-use or when-not-to-use guidance, and no alternative tool is named. The agent must guess whether to reach for this versus gsc_inspect_url (Google inspection) or the aggregate bing_crawl_stats, which is the main ambiguity given the crowded SEO sibling set.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds one genuinely useful behavioral fact — it operates on the *last* imported CSV, implying results reflect the most recent local import rather than live data — but says nothing about what happens when no CSV exists, how fresh the snapshot is, or whether the summary is per-property.

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. It is efficient, though the brevity edges into under-specification because the one clause it does contain ('CSV generativo') is the least self-explanatory part.

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

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

With no output schema, the description carries the burden of telling the agent what the summary contains — metrics, dimensions, time range — and it does not. For a report/summary tool the agent cannot judge whether the result answers its question, nor anticipate the empty-import case.

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 (siteUrl) and schema coverage is 100%, with the schema itself stating 'URL exacta de la propiedad verificada.' The description adds no extra meaning, such as whether siteUrl must match an imported CSV's property exactly or how mismatches are handled, so the baseline of 3 applies.

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

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

The description names a resource ('Resumen del último CSV generativo de Google importado localmente') but the phrase 'CSV generativo' is ambiguous — it never states what the CSV contains (Search Console export? GA4?) or what the summary reports on. It implicitly distinguishes itself from live-API siblings like gsc_search_performance by saying the data is 'importado localmente', but an agent must infer that distinction rather than being told it.

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

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

No when-to-use, when-not-to-use, or alternative is given. The precondition that a CSV must already have been imported locally is hinted at only inside a noun phrase, not stated as a requirement, and nothing tells the agent whether to prefer this over gsc_search_performance for the same siteUrl.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description contributes genuinely new behavior: Bing data latency for newly added sites. It does not address freshness of existing data, 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?

Two tight sentences with no filler, and the core scope is front-loaded. The latency caveat is properly placed as a secondary note.

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

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

For a read-only, no-output-schema, three-required-parameter tool, the essentials are present, but it never names the returned metrics or the per-day granularity implications (row volume per date range) that an agent would want before calling. The Spanish-language description amid otherwise English siblings is also a minor consistency 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 100%, so siteUrl and both dates are already fully documented in the schema, making 3 the baseline. The phrase 'rango inclusivo' does add a small clarification that both endpoints are counted, which the schema does not state explicitly.

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 says it returns daily Bing metrics for an inclusive range, which is a specific resource and scope, but the actual metrics (clicks and impressions) are only inferable from the tool name, not stated in the text. It also does not distinguish itself from near-siblings like gsc_search_performance or bing_top_pages.

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

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

There is no statement of when to use this tool versus the many sibling analytics tools (bing_top_pages, gsc_search_performance, bing_page_queries). The second sentence addresses data latency, which is behavioral context rather than usage routing.

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

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

Annotations already cover read-only, idempotent, non-destructive, open-world behavior. The description adds one genuinely useful trait beyond them: the data is Google's registered index state, not a live test, so results may be stale. It says nothing about what status fields come back, coverage/verdict values, or quota considerations.

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 with no filler, and the primary purpose is front-loaded before the clarifying caveat. Slightly terse — the important 'not a live test' qualifier sits after a semicolon rather than leading.

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

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

There is no output schema, so the description carries some burden for explaining what an 'indexing status' result contains, and it doesn't. The safety profile is covered by annotations and the parameters by the schema, so it is adequate but leaves the return value undefined for an inspection tool.

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

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

Schema description coverage is 100%, so both parameters (url, siteUrl) are already documented in the schema as a full URL and an exact verified property URL. The description adds no further detail on the relationship between the two, so baseline 3 applies.

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

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

States a specific verb and resource: querying the indexing status of a URL as registered by Google. It also distinguishes itself from a live-fetch/crawl operation, which separates it from live-URL tools. It doesn't name a specific sibling (e.g., gsc_page_performance, bing_url_info) it should be chosen over.

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 clause 'no ejecuta una prueba en vivo' implies usage context — pick this when you want Google's recorded state rather than a live crawl — but no alternative tool is named and there are no explicit when-to-use or when-not-to-use conditions. 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 declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds one useful piece of context — that only properties 'accesibles' (accessible to the authenticated account) are returned — but says nothing about the return shape or ordering.

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. It is arguably too terse rather than padded, which is not penalized under conciseness.

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 trivial no-param lister with full annotation coverage this is close to sufficient, but with no output schema the description never indicates what a site entry contains or that this is the entry point for the GSC tools. Minor but real gap.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate. Baseline 4 applies.

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

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

States a specific verb and resource ('Lista las propiedades accesibles en Google Search Console'), so the agent knows it enumerates Search Console properties. It implicitly distinguishes itself from the sibling bing_list_sites by naming the GSC product, though it does not explicitly call out that distinction.

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

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

Usage is only implied: as a zero-parameter lister it is presumably the discovery step before gsc_search_performance or gsc_inspect_url, but the description never says so or names an alternative. No exclusions or prerequisites are given.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so safety is covered. The description adds genuinely non-obvious context: results are heuristics, not official errors, which sets the right expectation about reliability. It stops short of describing ranking/ordering or what fields come 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?

A single tight sentence with no filler, front-loading the core criteria (low CTR in top 10, position 10-20) and appending the heuristic caveat. Efficient, though the caveat could be integrated more cleanly.

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 five parameters, no output schema, and sparse schema descriptions, the definition leaves too much unexplained: no return shape, no ordering, no interaction between minImpressions and the position bands, and no note on how limit applies. For a diagnostic tool that returns a ranked opportunity list, this is insufficient context.

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

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

Schema description coverage is only 60%; limit and minImpressions carry no schema descriptions and are never mentioned in the description at all, leaving their purpose (result cap, impression floor) unexplained. The description also adds nothing about siteUrl, the date range, or how the position-band criteria interact with minImpressions, 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 recognizable analytical purpose: surfacing queries worth investigating due to low CTR in the top 10 or average position 10-20. The verb is implicit (an analysis/diagnostic query) rather than explicit, and it never names the sibling analytical tools (gsc_query_advanced, gsc_search_performance) it should be distinguished from, but the criteria are concrete enough that an agent can identify the tool's job.

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 scenario (finding under-performing queries within certain CTR/position bands) but offers no explicit when-to-use vs when-not guidance and no reference to alternatives. An agent must infer that this is the tool for heuristic opportunity discovery rather than raw performance retrieval.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds the scope of the returned data (daily series + top queries) but says nothing about row limits on 'consultas principales', date-range constraints, or data 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?

A single efficient sentence with the key scoping element ('página exacta') and the return content front-loaded. No waste, though it is terse enough to leave gaps.

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 four-required-parameter read tool with no output schema, the description does convey what data comes back (daily series, top queries). It omits practical details an agent needs, such as how many top queries are returned or whether the URL must be an exact canonical match, leaving it merely adequate.

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

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

Schema description coverage is 100%, so all four parameters are documented in the schema (siteUrl as verified property, url as belonging to the site, ISO dates). The description adds no parameter-level meaning beyond that, so the baseline 3 applies.

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

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

The description names a specific resource (an exact page in Google Search Console) and states what it returns: a daily series plus top queries. That distinguishes it reasonably well from the broader gsc_search_performance sibling, though it never names that sibling explicitly.

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

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

Usage is only implied by the phrase 'página exacta' — an agent can infer this is the page-scoped variant versus the site/query-level siblings, but there is no explicit when-to-use or when-not-to-use guidance and no mention of prerequisites like property verification or data-freshness limits.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds one genuinely useful behavioral fact — that Google may cap returned rows — but says nothing about auth requirements, quota/rate limits, or how the cap manifests.

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 zero filler and the row-limit caveat placed last. It is efficient, though for an 8-parameter tool the terseness borders on under-specification rather than pure conciseness.

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

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

Given the tool's complexity (8 params, filter array, enums, no output schema) the description is too thin — it never explains what rows are returned or how dimensions shape output. Annotations cover safety, but a complex analytics query deserves more than one clause.

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 38%, so the description should compensate, and it partially does by mapping to dimensions (capped at 1-3), filters, and pagination (startRow/limit). But it leaves the enum values, filter operators, and site/date requirements entirely to the schema, so it adds only partial meaning over structured fields.

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 ('Search Analytics') and its key capabilities (1-3 dimensions, filters, pagination), so an agent knows exactly what it does. However, it does not distinguish it from close siblings like gsc_search_performance or gsc_page_performance, leaving ambiguity about when this advanced variant 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 only guidance is a caveat ('Google puede limitar filas'), which is behavioral, not a when-to-use rule. There is no mention of prerequisites, no exclusions, and no routing to alternatives such as the simpler sibling performance tools.

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

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

Annotations already establish readOnly/idempotent/non-destructive/openWorld, so the safety profile is covered. The description adds nothing about Search Console's data lag, API quota behavior, the 1000-row cap, or whether the default 1000-row limit silently truncates results — all things an agent needs to know when calling this.

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 efficient sentence with the resource and dimensions front-loaded and no filler. It is under-specified rather than verbose, so brevity here is real but comes at the cost of information.

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

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

There is no output schema and annotations already cover the safety/idempotency profile, so completeness is judged on the description alone (correct baseline 4). For a read-only reporting tool with 5 parameters that the schema mostly documents, the definition is sufficiently complete and correctly invocable — the only soft spot is behavioral guidance, which is scored separately.

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%: siteUrl and both dates are documented in the schema, but limit (default/max 1000) and the dimension enum carry no description. The description re-lists the five dimension values but adds no semantics beyond the enum itself, and says nothing about how dimension drives the aggregation or about the row limit.

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

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

The description names the specific metric set (clics, impresiones, CTR, posición) and the breakdown dimensions, so the resource is identifiable. But it is a bare noun phrase with no verb indicating retrieval/reporting, and it does not distinguish itself from heavily overlapping siblings such as gsc_page_performance, gsc_query_advanced or get_bing_clicks_and_impressions.

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 choose this tool over the many sibling performance tools, and no stated prerequisites. An agent must infer from the sibling names alone that this is the generic dimension-driven variant.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds only the words 'oficial' and 'enviado', which hint at data provenance but say nothing about what is returned or what happens when the sitemap is not found. Against annotation coverage the bar is low, yet almost no extra context is supplied.

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 short sentence with no padding, but it is a bare fragment rather than a front-loaded structured statement. Nothing is wasted, yet the few words present do little work.

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?

No output schema exists, so the description should indicate what a 'sitemap detail' contains (submitted vs. indexed counts, last download time, errors/warnings, sitemap type). It also fails to say what happens for an unsubmitted sitemap. For a lookup tool with two mandatory parameters, this leaves the agent under-informed.

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% with only two required string parameters, so the schema already carries the burden of documenting siteUrl and sitemapUrl. The description adds no additional meaning about their relationship or format, so the baseline 3 applies.

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

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

It names a specific resource (a sitemap submitted to Search Console) and implies a detail/retrieval operation, so the agent can guess the general intent. But it is a noun phrase with no verb, and it never distinguishes itself from the sibling gsc_sitemaps, which plausibly lists the same resource. Purpose is inferable rather than stated.

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

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

There is no statement of when to use this tool instead of gsc_sitemaps, or of any precondition such as the sitemap having been previously submitted or the property being verified. The agent must infer the distinction from the name alone.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and openWorld, so safety is covered structurally. The description adds nothing beyond that – no mention of what a sitemap entry contains, whether errors/warnings per sitemap are included, or any rate/auth considerations.

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

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

One short sentence, front-loaded with the verb and resource, with no filler. It is efficient, though its brevity is part of why guidance is missing.

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 one-parameter read tool with rich annotations, a minimal description is almost sufficient. However, with no output schema, the agent gets no hint about what the returned sitemap listing contains or how it differs from gsc_sitemap_details.

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

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

There is a single parameter with 100% schema description coverage ('URL exacta de la propiedad verificada'), so the schema carries the semantics. The description adds no extra meaning such as format examples or where to obtain the exact URL.

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 ('Lista') and resource ('sitemaps') scoped to a Google Search Console property. It is clear on its own, but it never distinguishes itself from the sibling gsc_sitemap_details, which an agent could easily confuse for sitemap-level information.

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 no condition for when to use this versus gsc_sitemap_details, nor any prerequisite beyond what the schema already requires. Usage is only inferable from the verb 'Lista'.

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

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

Annotations already declare readOnly/openWorld/idempotent/non-destructive, but the description adds context annotations cannot: no credentials required, js render spawns an installed browser, performance=true sends the target URL to Google (with optional PAGESPEED_API_KEY), and nothing is written to disk. The caveat that 'cero acciones no implica revisión exhaustiva' usefully frames how to read results.

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

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

Front-loads the audited surface, then the two behavior toggles, then the caveat and privacy note — a sensible order with dense, low-waste clauses. Minor duplication with the schema (render=js / performance=true are also described in the schema), but the sentences earn their 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 9-parameter tool with no output schema it covers the essentials: no auth, optional providers, no persistence, and a warning about result completeness. It does not explain why startDate/endDate exist (presumably scoping provider data) or point to the natural follow-on siblings seo_audit_save / seo_audit_report / seo_audit_history, which an agent needs to make the output useful.

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 high (78%), so the baseline is 3, but the description adds real meaning for two of the nine parameters: render switches between static fetch and a real browser, and performance triggers an external PageSpeed call with an optional API key. date range, maxPages and the gsc/bing site URL parameters are only alluded to via 'Proveedores opcionales', leaving some schema documentation to carry them.

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

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

States a specific verb+resource (audit a public URL) and enumerates exactly what is inspected: crawl, canonical, hreflang, headers, images, social metadata, JSON-LD. It never names the closest sibling (seo_audit_site) or the save/report siblings, so an agent must infer that this is the single-URL audit vs. a whole-site crawl. Clear purpose, but no explicit sibling differentiation.

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

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

Gives concrete activation conditions for two options (render=js launches a browser; performance=true queries PageSpeed Insights) and states that no credentials are needed, with GSC/Bing as optional providers. It does not say when to prefer render=static vs js, when the extra PageSpeed call is warranted, or when to use seo_audit_site instead. Usage is implied rather than prescribed.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the bar is lower. The description still adds real value by defining the comparison semantics: an omitted URL or a failed rule never counts as a correction, which an agent could not infer from the schema. It does not cover output size or pagination.

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

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

Three short sentences, front-loaded with the operation and scope, followed by the correction-semantics rule and the read-only guarantee. No filler and nothing redundant.

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 partially compensates by enumerating the four result classes (nuevos, persistentes, resueltos, no comparables). Still missing is anything about the shape of the returned report or how the IDs and output format are chosen, which an agent needs before calling.

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, and it largely doesn't. It implies that the two inputs are saved audit identifiers, but never distinguishes baselineId from currentId or explains how to obtain them, and the 'format' enum (json/markdown, default json) is not mentioned at all.

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 (compare) plus the resource (two saved audits from the same origin) and the axis of comparison (per rule and per URL). It doesn't explicitly differentiate itself from neighboring tools such as seo_audit_site, seo_audit_history or seo_audit_report, but the operation is unmistakable.

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?

'Dos auditorías guardadas del mismo origen' implies the prerequisite that both audits already exist and share an origin, and 'No modifica informes' signals a safe read. However, it never says when to use this tool instead of seo_audit_history or seo_audit_report, nor how the IDs are obtained.

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

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

Annotations already cover read-only, idempotent and closed-world behavior; the description adds concrete value by enumerating the returned fields and confirming no network access or file writes. It does not describe ordering or the meaning of 'estado', but for a simple listing tool that is a minor gap.

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

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

Two brief sentences, front-loaded with what it returns and followed by the scoping constraint. No filler and nothing left dangling.

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

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

For a read-only local listing with one optional param and no output schema, the description covers purpose, returned fields and side-effect profile. The only missing piece an agent needs is what 'limit' controls.

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 the description never mentions the single optional 'limit' parameter, its default of 20 or the 100 cap. The one parameter the agent must reason about is fully undocumented in both structured and natural-language form.

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 (lists saved audits) plus the identifying fields returned (id, date, URL, status). It implicitly separates itself from seo_audit_site/seo_audit_save by noting it neither hits the web nor creates files, though it never names a sibling 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 negative clauses ('no consulta la web ni crea archivos') give useful when-not context, steering the agent away from it for running or saving audits. However, no alternative tool is named and no prerequisite is stated, so the routing is implied 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false. The description adds useful safety context by stating it does not write a file or read arbitrary paths, but it does not describe error behavior, missing-id handling, or the exact return shape beyond 'el contenido'.

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 compact sentence that front-loads the core action and format options. Every clause adds relevant information without unnecessary padding.

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

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

For a simple two-parameter read-only retrieval tool, the description covers the essential action, format choice, return content, and no-side-effect caveat. Minor gaps remain around missing-id behavior, but the annotations carry safety and idempotency context.

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

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

Schema description coverage is 0%, so the description must compensate. It mentions the 'id' lookup and the two accepted format values (json/markdown), but it does not explain the expected id format or add constraints 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 specific action and resource: retrieve a saved report by id, with format json or markdown. It distinguishes itself from write-oriented siblings like seo_audit_save, though it does not explicitly name alternatives such as seo_audit_history or seo_audit_compare.

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 'informe guardado' implies the tool is used after a report has been saved, but there is no explicit when-to-use guidance versus siblings like seo_audit_history or seo_audit_compare. The usage context is inferable but not 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 declare readOnlyHint=false and openWorldHint=true but give no detail, and the description fills that gap meaningfully: it specifies that the write is confined to local history ('No modifica la web'), notes the returned id, and warns that the report may contain private provider data. Non-idempotency and rate/scope limits of the audit run itself are not addressed.

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 clauses, front-loaded with the primary action, followed by two genuinely load-bearing caveats (no site mutation, private data). No filler and no repetition of the title.

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

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

With 9 parameters, openWorld network calls, and no output schema, the description supplies the one structural fact the schema cannot — the returned id for later retrieval/comparison. It is only slightly short of complete in not signaling the cost/scope of a run (maxPages up to 500, optional PageSpeed calls).

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 78%, so most parameters (render, performance, gscSiteUrl, bingSiteUrl, dates) are already self-documenting in the schema and the description adds no parameter-level detail. The two undocumented fields (maxPages, performanceStrategy) are partly covered by defaults and enums, so the description's silence is a minor but real gap. Baseline 3 applies.

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

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

The description states a specific compound action (run an audit AND persist the report to the user's local history) plus the returned id, which clearly separates it from non-persisting audit siblings like seo_audit_site or seo_audit_advanced. It stops short of naming any sibling explicitly, so the differentiation is inferential rather than stated.

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

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

The word 'explícitamente' implies the persistence is opt-in versus other audit tools, and 'para consultar o comparar después' hints at seo_audit_report/seo_audit_compare as follow-ups. However, it never says when to prefer this over seo_audit_site or seo_audit_advanced, leaving the agent to infer the 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 read-only, idempotent, non-destructive, open-world behavior, so the safety profile is covered. The description adds one genuinely useful trait: results can contain 'errores parciales' (partial errors), warning the agent that a response may be incomplete rather than a total failure. It omits auth/verification requirements and any statement about which sources are actually queried when only one property is supplied.

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 zero padding, which is good. But it is undersized for a five-parameter, multi-source tool with seven closely related siblings—brevity here is under-specification rather than economy.

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, five parameters across two distinct data sources, and a dense sibling cluster to disambiguate. The description does not say how the two sources are combined, what 'hallazgos priorizados' contains, or what 'errores parciales' look like, leaving the agent without enough to invoke it confidently versus seo_audit_advanced.

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

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

Schema coverage is 100% and each parameter carries its own Spanish description, so the schema fully documents the inputs. The tool description adds no semantics beyond that—it does not explain how url, gscSiteUrl and bingSiteUrl interact or what scope each defines. Baseline 3 applies.

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

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

States a verb+resource ('Auditoría ... de Bing y/o Search Console') and names output elements (evidencia, hallazgos priorizados, errores parciales). However, it never distinguishes itself from the crowded seo_audit_* family (seo_audit_advanced, seo_audit_report, geo_report_summary); 'resumida' hints at a lighter variant of seo_audit_advanced but leaves the agent to infer it.

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 indication of when to choose this over seo_audit_advanced, seo_audit_report, or the individual bing_*/gsc_* tools. Nothing says whether a verified property is a prerequisite or what happens if only one source is configured.

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