Rank by Ouroboros Apps

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

Annotations already declare readOnlyHint/idempotentHint/destructiveHint=false, so the safety profile is covered. The description adds real scope information beyond that: it clarifies the tool performs no Search Console query (a meaningful nuance given openWorldHint=true) and that no pricing data is returned, heading off a plausible misconception about a billing/status tool.

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

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

Two tight sentences, zero waste, with the substantive content (what it reports) front-loaded and the disambiguating caveats trailing. The 'no price' note is short and earns its place by preventing a wrong expectation.

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

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

With an output schema present, return values need no prose, and with zero parameters and full annotation coverage there is little else to document. The description covers what the tool reports and what it does not touch, which is sufficient for an agent to call it correctly.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The description's field enumeration (connected / trial end / Pro access) usefully frames the response shape even though no inputs exist.

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 (account status) and enumerates exactly what it returns: connection state, trial end date, Pro access. The sentence 'Does not query Search Console' cleanly separates it from all eight siblings, which are Search Console data-query tools, so an agent can pick it without opening a schema.

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

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

The exclusion ('does not query Search Console') implicitly tells the agent when NOT to use this tool, but there is no positive when-to-use guidance, no mention of prerequisites, and no named alternative. Usage is inferable from purpose but not 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 establish the safety profile (readOnly, idempotent, non-destructive), and the description adds real behavioral context beyond them: it reports both API metric objects, states that differences are derived from the returned numbers, and documents the default comparison window when compare dates are omitted. This is meaningful disclosure for a read tool.

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

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

Four short sentences, front-loaded with the core purpose and scope before the default-behavior detail. Slightly dense but no filler; 'Reports both API metric objects' borders on redundant given the output schema but still adds a useful hint about the shape of the comparison.

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

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

With an output schema and full annotations present, the description needn't explain returns or safety, and it covers the comparison default well. But for an 8-parameter tool with 0% schema description coverage, the filter parameters (device, country, searchType) are left completely undocumented, which is a real completeness gap.

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

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

Schema description coverage is 0% across 8 parameters, so the description must carry the burden, and it largely does not. It alludes to compareStartDate/compareEndDate via the default-window sentence and implies siteUrl via 'for a property', but device, country, searchType, startDate, and endDate are never explained in either place.

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 date ranges using the Search Console totals for a property') and adds the scope qualifier '(no dimension grouping)', which implicitly distinguishes it from dimension-grouping siblings like top_queries and top_pages. It does not name a sibling explicitly, but the differentiator is clear.

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 final sentence 'Omit compare dates to use the previous window of the same length' gives a useful default-behavior cue for when compare params can be skipped. However, there is no explicit guidance on when to choose this tool over performance_trends or other comparison-capable siblings, so usage is only implied.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), so the bar is lower. The description nevertheless adds a genuine behavioral disclosure: it will not fabricate zeros for pages absent from the current response, which tells the agent how missing data is handled. It stops short of explaining the comparison mechanics or pagination/limit 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?

Two sentences, front-loaded with the defining condition, and the second sentence earns its place by clarifying an edge case. No filler or restatement of the name.

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

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

With 9 parameters at zero schema coverage and no explanation of how 'worse' or 'fell' is computed, the agent cannot confidently supply the required comparison dates. The existing output schema covers return values, but the input-side gap is large for a derived analytics 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 0% across 9 parameters, so the description carries the full burden. It explains none of them: no mention of startDate/compareStartDate/compareEndDate, device, country, searchType, or limit. Only a faint implication of comparison exists.

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 defines the resource (pages) by a precise three-part condition: worse position, falling clicks, or disappearance from the current response. This distinguishes it from siblings like top_pages and quick_wins, though it never names an alternative 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?

There is no when-to-use or when-not-to-use guidance, and no mention of how it relates to compare_periods or top_pages. The agent must infer that a comparison window is needed to produce 'worse' or 'fell'.

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 and idempotency profile is fully covered. The description adds that results are conditional ('when the API sent them'), which is useful behavioral context, but it doesn't address auth needs, rate limits, or error 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?

Two efficient sentences, front-loaded with the purpose and followed by the return value. No filler, though it could be slightly more actionable.

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

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

With an output schema present, the description needn't document return fields, and annotations cover safety. However, the total absence of parameter explanation and usage guidance leaves gaps for an agent deciding how to call it correctly.

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

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

Schema description coverage is 0%, so all three parameters (siteUrl, inspectionUrl, languageCode) are undocumented. The description adds no meaning beyond field names; it doesn't explain what siteUrl and inspectionUrl should contain or how languageCode affects the response.

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 (Inspect) and resource (URL), and describes the return (Search Console inspection response with verdict, coverage, last crawl). It does not explicitly differentiate itself from siblings, but its scope is clear enough to distinguish it from list_properties and top_queries.

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

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

No when-to-use guidance, no exclusions, and no mention of alternatives. The description implies this is for checking a single URL but does not state when to choose it over other tools.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, covering the safety profile. The description adds the 'connected Google account' auth scope and a fidelity note that fields are returned 'exactly as the sites.list API returned them,' which is modest added value but not deep behavioral context (no pagination, no empty-account 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?

Two sentences, no filler, and the core action is front-loaded before the return-value note. Every sentence earns its place.

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

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

With zero parameters, rich annotations, and an output schema present, the description does not need to explain return values, and it does not overreach. The only gap is the missing framing of this as the discovery step that supplies siteUrl inputs to sibling tools.

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

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

The tool takes zero parameters, so per the rubric the baseline is 4. There is nothing for the description to disambiguate, and it correctly implies a no-argument call.

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 (List) and resource (Search Console properties on the connected Google account), which is unambiguous. It does not explicitly contrast with siblings, but none of the listed siblings (top_queries, inspect_url, account_status, etc.) also enumerate properties, so the distinction is reasonably clear from the resource 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?

Usage is only implied: an agent can infer this is the discovery step for finding which siteUrl values to pass to the other Search Console tools, but the description never states that. There is no explicit when-to-use, when-not-to-use, or alternative named.

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 safety is covered. The description adds genuine behavioral context beyond them: rows are only dates the API returned, missing dates are not backfilled, and ctr is an unfractioned API value rather than a percentage. It omits row limits/pagination, which is the remaining gap.

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

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

Three short sentences, each carrying distinct information (what the rows are, gap semantics, unit semantics), with the core output description front-loaded. No filler or restatement 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?

An output schema exists, so return-value explanation is not needed, and the gap/unit notes are useful. However, with 6 parameters at 0% schema coverage the description leaves the agent guessing about the date range and filter parameters, which is a material omission for a trends 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 0% across 6 parameters, so the description carries the full burden, yet it documents none of them. Only 'for a property' loosely gestures at siteUrl and 'daily' implies a date range; startDate, endDate, device, country and searchType are never mentioned, and the description does not clarify whether the date range is required.

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

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

States the resource (daily Search Console metrics for a property) and the granularity (one row per date), which is a clear verb-less but specific purpose. It does not distinguish itself from close siblings like compare_periods or top_queries, leaving the agent to infer the boundary.

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

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

There is no explicit when-to-use guidance and no named alternative, even though compare_periods and top_queries are plausible overlaps. Usage must be inferred entirely from the phrase 'Daily ... for a property'.

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, so safety is covered. The description adds real behavioral value on top: it discloses the default thresholds and clarifies the ctr fraction semantics. The note that it does not estimate missed clicks usefully bounds the result semantics, though it doesn't discuss ordering or how many rows appear absent an explicit limit.

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, zero filler, and the defining filter is front-loaded ahead of the tuning defaults. Every sentence earns its place, including the scope-limiting final clause.

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

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

An output schema exists, so return values need no explanation, and the description correctly focuses on the filters that define the query. The main remaining gap is the default date window and defaults for device/country/searchType, which an agent would need to know 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% across 9 parameters, so the description must compensate. It does so well for the two trickiest thresholds (minImpressions default 100, maxCtr default 0.02 and its fraction interpretation) but says nothing about limit, device, country, date range, searchType, or siteUrl. Partial compensation, so a 3 rather than higher.

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 (Search Console queries) and the precise filter that defines the set: high impressions, low ctr. An agent understands the shape of the output without opening the schema. It doesn't explicitly name a sibling (e.g. top_queries) to contrast against, so it stops short of 5.

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

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

The description supplies the operative defaults (>=100 impressions, ctr <=0.02), which tells the agent how to invoke it, but gives no when-to-use vs alternatives such as top_queries or top_pages, and no exclusion guidance. Usage context is implied by the topic 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 read-only/idempotent/non-destructive, so safety is covered. The description adds real value beyond them: data provenance ('Metrics are copied from Search Console rows') and a unit clarification ('ctr is the API fraction from 0 to 1') that prevents a common misinterpretation of the metric.

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 resource and scope, followed by metric semantics and the default-window rule. No filler, though the 'copied from Search Console rows' clause is somewhat incidental.

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?

Output schema exists, so return values needn't be explained, and annotations cover the safety profile. Still, for a 7-parameter tool with 0% schema coverage, most filter parameters (device, country, searchType, limit) remain unexplained, leaving a real gap 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% across 7 parameters, so the description carries the full burden. It only addresses the date parameters and ctr; limit, device, country, searchType, and siteUrl are left entirely undocumented 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+resource: 'Top pages for one property and date range.' The resource (pages) is clear enough to distinguish it from the sibling top_queries, though the description never names that alternative 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 line 'Omit dates to use the default 28-day window' gives a concrete usage rule for the date parameters, which is helpful. However there is no when-to-use-this-vs-siblings guidance (e.g. vs top_queries, performance_trends, or quick_wins), so the agent must infer selection from the resource 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, openWorldHint and destructiveHint=false, so safety is covered. The description adds real behavioral context beyond them: metrics are copied verbatim from Search Console, ctr is a 0-1 fraction rather than a percent, and omitting dates triggers a 28-day default window.

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 purpose, then the metric semantics, then the default-window rule. No filler and every sentence carries 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?

An output schema exists, so return structure needn't be explained. However, with 7 parameters and zero schema descriptions, several filter parameters (device, country, searchType, limit) are left undocumented by both the schema and the description, leaving gaps for an agent building a call.

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

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

Schema description coverage is 0% across 7 parameters, so the description carries the burden and only partially compensates. It clarifies date defaults and the ctr unit, but says nothing about siteUrl format, limit bounds, device, country, or searchType values.

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: 'Top search queries for one property and date range,' which is clearly distinct from the sibling top_pages. It does not explicitly name or contrast with siblings, but the resource is unambiguous.

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

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

The description gives one conditional behavior ('Omit dates to use the default 28-day window'), which is useful, but offers no guidance on when to choose this tool over top_pages, compare_periods, or quick_wins. Usage is implied rather than stated.

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