SEOMonster

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.9.2
Disambiguation4/5
Each tool targets a specific SEO function, and the descriptions clearly differentiate them. However, with 70 tools, some overlap exists between convenience wrappers and their generic counterparts (e.g., gsc_top_queries vs gsc_search_analytics), which could cause minor confusion for an agent.
Naming Consistency4/5
Tool names follow a consistent pattern: lowercase with underscores, mostly using a service prefix (gsc_, ga4_, cf_, etc.) or descriptive compound names for standalone tools. The naming is predictable and readable, though a few tools lack a clear prefix.
Tool Count3/5
70 tools is high for a single server, but the broad SEO domain justifies the count through coverage of multiple services and specialized utilities. The number may be overwhelming for agents, but the tools are well-organized.
Completeness4/5
The tool surface covers major SEO areas: Search Console, Analytics, Cloudflare, PageSpeed, Core Web Vitals, redirects, robots, sitemaps, schema, internal links, content opportunities, and keyword research. Minor gaps include lack of Google Search Console sitemap deletion or GA4 property management, but these are outside typical scope.
Average 4.3/5 across 70 of 70 tools scored. Lowest: 3.5/5.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 1 community issues answered or closed in the last 6 months
- 81 commits in the last 12 weeks
- Last stable release on June 20, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, etc. The description adds that it returns window totals and day-by-day trends, but doesn't disclose data freshness, rate limits, or auth requirements beyond annotations. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with clear information: first sentence defines output, second adds context about underlying reports. No fluff, but could be slightly more structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple two-parameter, read-only tool with no output schema, the description covers the key aspects: metrics returned, aggregation type, and trend. Edge cases like empty results are not mentioned, but acceptable for this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters. The tool description reiterates the lookback window but adds no new semantic meaning beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it provides organic-search health metrics for a window plus daily trends, and specifies the metrics (sessions, engaged sessions, etc.). It distinguishes from sibling GA4 tools like ga4_traffic_by_channel by focusing on organic search overview.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives (e.g., ga4_run_report, ga4_traffic_by_channel). Does not mention prerequisites or exclusions. The note 'Two GA4 reports under the hood' is vague.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, idempotentHint, and destructiveHint. The description adds minimal behavioral context beyond what is in the schema (e.g., mentioning data_state). It does not add new details about rate limits or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two clear, front-loaded sentences with no wasted words. The first sentence conveys the core action and output; the second adds a useful label. Efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 11 parameters and no output schema, the description is brief but covers the essential purpose. It does not explain return format or pagination, but these are implied by the parameters. Adequate for a general query tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description adds no additional parameter meaning beyond restating the dimensions, date range, and filters already documented in the schema. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it queries Search Console search analytics (clicks, impressions, CTR, position) for a property, with specific parameters. It brands itself as 'the workhorse GSC tool', distinguishing it from sibling tools that focus on specific subsets like top queries or pages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The description does not mention when not to use it or suggest sibling tools for specific needs, leaving the agent to infer usage from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false. The description adds minimal behavioral context beyond being a convenience wrapper, such as potential limitations compared to ga4_run_report. With strong annotations, the description adds some but not substantial transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loading the key metrics and purpose. Every sentence is essential, with no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (3 optional parameters, strong annotations, no output schema), the description covers the core purpose and relationship to a sibling. It could include more on output format or default channel groups, but overall it provides sufficient context for a quick analytics tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with each parameter (days, limit, property_id) having descriptions. The description mentions 'last N days' which aligns with the days parameter but adds no new semantic meaning beyond what the schema provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves sessions, engaged sessions, and conversions broken down by default channel group over a specified period. It also notes it separates organic from paid/referral/direct and positions itself as a convenience wrapper over ga4_run_report, distinguishing it from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for quick channel breakdowns and mentions it's a convenience wrapper over ga4_run_report, but does not explicitly state when to use this tool vs alternatives like ga4_organic_search_overview or ga4_top_landing_pages. Lacks explicit when-not or alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only and idempotent behavior. The description adds the key behavior of comparing two windows and filtering for zero prior impressions, which is beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence followed by a use-case statement, with no redundancy or filler. It is front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description omits what the output contains (e.g., query strings, metrics like impressions/clicks). Since there is no output schema, the description should provide this context to help the agent use the results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 80%, so the schema itself explains most parameters. The description does not add additional meaning beyond what's in the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns queries with impressions in the current window but none in the prior window, which is a specific verb+resource. It distinguishes from sibling tools like gsc_top_queries by focusing on new queries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions utility for spotting emerging topics, which implies when to use. However, it lacks explicit exclusions or comparison to alternatives like gsc_compare_periods or gsc_query_opportunities.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, covering safety. The description adds behavioral context by specifying SEO migration use cases, which goes beyond the annotations and helps the agent understand the tool's role.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no fluff: first sentence defines the operation, second lists practical use cases. Every word earns its place; it is as concise as possible without sacrificing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
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 compensate with details about the return format (e.g., fields like name, type, TTL, content). It omits this and does not mention pagination or limits, making it somewhat incomplete for a list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already describes both parameters ('type', 'zone') adequately. The description does not add any additional meaning or examples beyond what is in the schema, meeting only the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'List DNS records for a zone (read-only)' – a specific verb and resource. It further clarifies use cases like verifying canonical host, CNAME flattening, and TXT records during SEO migrations, distinguishing it from sibling tools that manage zones or analytics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for verification tasks but does not explicitly state when to use this tool vs alternatives like cf_list_zones or cf_zone_info. No when-not-to-use or alternative naming is provided, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations confirm read-only, idempotent, non-destructive. The description adds that the tool fetches the URL, analyzes the canonical tag, and follows one 'canonical hop' to confirm 2xx, providing behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence covering all key actions and outputs without redundant words. It is front-loaded with the main action. However, it could be slightly more structured (e.g., listed items) for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a single required parameter, no output schema, and comprehensive annotations, the description adequately explains the tool's functionality and expected output (reporting on canonical issues). It mentions following one hop, which is a key detail. Missing is explicit mention of return format or error handling, but overall sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'url' is fully described in the schema as 'Absolute http(s) URL to inspect.' The tool description adds that it fetches and analyzes, but no additional parameter meaning is needed. Schema coverage is 100%, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool fetches a URL and analyzes its canonical link tag, listing specific issues (self-referential, cross-host, protocol-mismatched, trailing-slash drift, missing canonical) and mentions following one hop. This uniquely identifies its function among many SEO analysis siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies its purpose for canonical analysis but does not explicitly state when to use it versus alternatives like inspect_meta or mixed_content_check. No when-not-to-use or alternative names given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows it's safe. The description adds that it returns specific fields (status, plan, id) but doesn't disclose potential rate limits or pagination. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is front-loaded with the verb 'List'. No extraneous information. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a parameterless read-only tool. It states the action, resource, and output fields. However, it lacks guidance on potential large result sets or limits, which could be relevant. Overall, it is mostly complete given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so schema coverage is 100%. The description adds value by specifying the output fields (status, plan, id) that go beyond the empty schema. This context helps the agent understand the return format without an output schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists Cloudflare zones with specific fields (status, plan, id). It uses a specific verb and resource, distinguishing it from sibling tools like cf_zone_info (which targets a single zone) and cf_list_dns (DNS records).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance is provided. The description implies it is for listing zones accessible by the API token, but lacks comparison to alternatives like cf_zone_info for detailed info. However, given the tool's simplicity, the omission is minor.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, destructiveHint, idempotentHint, openWorldHint. Description adds value by listing specific output fields (status, plan, paused, name servers, created/modified).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence of 12 words, front-loaded with purpose. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with no output schema, description covers core functionality and output fields. Could mention output format (e.g., JSON), but not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage for the single optional parameter 'zone', including example and default. Description adds no additional parameter details beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states verb+resource: 'Zone overview' for a hostname. Describes specific fields (status, plan, etc.), distinguishing it from sibling cf_list_zones which lists all zones.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage when needing overview of a specific zone, but does not explicitly state when to use vs alternatives or provide preconditions. No exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, not destructive. The description adds that it's a convenience wrapper but no additional behavioral traits (e.g., rate limits, pagination). With annotations covering safety, a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no wasted words. First sentence covers purpose and metrics; second adds the key filter and wrapper context. Efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool with 100% schema coverage and annotations, the description is fairly complete. It mentions returned metrics. Without an output schema, more detail on results would be helpful but not critical for this straightforward tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with each parameter documented. Description reinforces the organic_only default and the wrapper nature. Baseline 3 is correct when schema does the heavy lifting, and description adds limited extra meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns top landing pages with sessions, engagement rate, and conversions over N days, defaulting to organic search. It distinguishes itself from ga4_run_report by being a convenience wrapper, and from other GA4 tools by its specific focus.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates when to use (SEO view, organic default) and that it's a wrapper over ga4_run_report, implying ga4_run_report for more flexibility. However, it doesn't explicitly exclude other siblings like ga4_organic_search_overview, which could overlap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the description adds value by elaborating on the specific data returned (index verdict, coverage state, crawl info, canonicals, mobile/rich-results). No contradictory information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the purpose ('Inspect a single URL') and efficiently lists the returned data types. No waste or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite lacking an output schema, the description compensates by listing key return fields. However, it uses terms like 'index verdict' without explanation and omits prerequisites (e.g., valid property) or error conditions. Still fairly complete for a read tool with rich annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters. The description does not add any meaning beyond what the schema provides for the parameters themselves.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool inspects a single URL via the URL Inspection API and lists the specific information it returns (index verdict, coverage state, crawl info, canonicals, mobile/rich-results). It distinguishes from the sibling tool gsc_batch_inspect_urls which operates on multiple URLs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for detailed inspection of a single URL, but does not explicitly state when to use this tool versus alternatives like gsc_search_analytics or gsc_batch_inspect_urls. No exclusion criteria or context are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so safety is clear. Description adds value by specifying the output includes submission and indexing status. Does not mention pagination or limits, but for a simple list tool this is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence of 15 words front-loads the action. Every word earns its place; no redundancy. Highly concise and structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no required parameters, no output schema), the description covers the key purpose and output. Annotations provide safety context. Could mention whether multiple site_url calls are needed for different properties, but overall adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (site_url described as optional with default). Description adds no additional information beyond the schema. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb (list), resource (sitemaps), scope (for a property), and includes what is reported (submission and indexing status). It distinguishes from sibling tools like gsc_submit_sitemap and sitemap_validate by focusing on listing known sitemaps.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description does not explicitly state when to use this tool versus alternatives (e.g., sitemap_validate, sitemap_health). It implies use for retrieving Google's view of sitemaps, but lacks explicit context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the safety profile is clear. The description adds that the tool compares two time windows and sorts by delta impressions descending, providing behavioral context beyond annotations but not extensive details on rate limits or data freshness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first states the function concisely, second provides a use case. No extraneous words, front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with 3 parameters, clear annotations, and an explicit equivalence hint, the description covers the purpose and usage well. It lacks explicit mention of return format, but the equivalence partially compensates.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description adds no extra meaning beyond the schema, only implicitly relating 'days' to the window length. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns pages with the most impression growth over two windows, explicitly distinguishing itself by referencing equivalence to gsc_compare_periods with specific parameters. It differentiates from siblings like gsc_decaying_pages and gsc_top_pages by focusing on growth over time.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: 'Use this for lifecycle triage (find pages to invest in or rescue).' It also hints at an alternative (gsc_compare_periods) for more flexibility, though it does not list explicit when-not-to-use scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false. The description adds valuable behavioral details: the specific checks performed (missing reciprocity, broken URLs, etc.) and the return format (per-URL and global findings). No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: three sentences. The first states the purpose, the second lists checks, the third describes return types. No redundant information; every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one well-documented parameter and safety annotations, the description covers purpose, checks, and return format. It could explicitly state that the tool performs cross-URL validation (implied by 'across a set of URLs'). Overall, fairly complete for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers the single parameter 'urls' with 100% description coverage, including constraints (max 50, min 2, must be absolute URLs). The description does not add additional parameter semantics beyond what the schema provides, so baseline score applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Validate hreflang link tags across a set of URLs.' It lists specific checks (reciprocity, broken targets, duplicates, missing self-link, missing x-default), making the verb-resource combination distinct from sibling tools like check_canonical or redirect_chain_audit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for hreflang validation but provides no explicit guidance on when to use this tool versus alternatives (e.g., check_canonical, robots_txt_validate). It does not mention exclusions or prerequisites. The context of sibling tools is large, making this a gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false. The description adds that it uses HTTP GET and returns specific fields, but does not disclose limitations like JavaScript rendering or authentication needs. With annotations covering safety, the description adds moderate behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the action and explicitly lists the returned fields. No extraneous information, every part earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is simple (one required parameter, no output schema, no nested objects), the description adequately covers its purpose and output. Annotations handle behavioral traits. It could mention limitations like no JS rendering, but overall it is complete enough for this tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes the single parameter 'url' as an absolute http(s) URL. The description reinforces that it fetches a single URL and is HTTP GET, but does not add new semantics beyond the schema. Schema coverage is 100%, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches a single URL and returns specific on-page SEO elements (title, meta description, meta robots, canonical, Open Graph + Twitter Card tags, hreflang list, H1 count). This differentiates it from sibling tools like gsc_inspect_url which are Google Search Console specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions it is a read-only HTTP GET and lists the returned SEO surface, implying use for general URL inspection. However, it does not explicitly state when to use versus alternatives like gsc_inspect_url or check_canonical, nor does it mention when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. Description adds behavioral context: uses lab-only data, returns specific audits, defaults to mobile. No contradictions. Could mention potential quota limits or output size.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence is efficient and front-loaded. Each clause adds distinct value (lab data, audit types, alternative tools, default strategy). Could be slightly restructured for readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Purpose and parameters are well-covered. However, with no output schema, the description only vaguely describes return types ('estimated load-time savings', 'severity grades'). Lacks concrete output structure for an agent to parse programmatically.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both url and strategy. Description only adds that strategy defaults to mobile, confirming existing schema info. No additional semantic depth beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool runs PageSpeed Insights lab data and returns two specific audit types (opportunity savings, SEO severity). It distinguishes from siblings by emphasizing lab-only data and naming alternatives (crux_snapshot, crux_history) for field metrics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states that this tool uses lab data only and recommends field-data alternatives (crux_snapshot/crux_history). Also notes default mobile strategy. Could be more explicit about when to prefer this over sibling psi_analyze.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate safeness (readOnlyHint, idempotentHint), but the description adds valuable behavioral details: 'without auto-following 3xx', the type of issues flagged (loops, mixed-protocol, etc.), and the default hop cap. This goes beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each contributing distinct information: primary action, return data and flags, and default limit. No fluff, efficiently front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema, the description sufficiently covers return fields and issue flags. It explains behavior (no auto-follow) and defaults. Minor gap: does not specify output format (e.g., array of objects) but still adequate for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions for both parameters. The description reiterates the default value for max_redirects and the URL type, adding minimal new meaning. Baseline score applies since no contradiction and schema handles most semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Walk the redirect chain') and specifies the resource ('a URL'). It lists exact return data (status, location, elapsed_ms) and issue flags, making it distinct from sibling tools that manage redirect rules.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for auditing redirect chains but does not explicitly contrast with alternative sibling tools like cf_list_redirects (listing existing redirect rules) or cf_create_redirect. No explicit 'when to use' or 'when not to use' guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false. The description adds 'Read-only; no ranking guarantee' and explains the fallback behavior (refresh-vs-new, not full SERP), providing context beyond the annotations. There is no contradiction between description and annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the main purpose and outputs, then covers parameters and fallback behavior. It is dense but not overly long; every sentence adds value. Slightly verbose due to parenthetical clarifications, but overall well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description adequately explains the return value (heading union, median word count, schema types, entity coverage, GEO directives). It also covers the two operational modes and parameter nuances. For a tool with 5 parameters, it is reasonably complete, though it could briefly mention the format of the return value.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds context for how parameters interact (e.g., 'competitor_urls' vs fallback, 'days' as GSC window) but does not provide additional semantic meaning beyond the schema descriptions for individual parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Gather the hard evidence for a content brief' and lists specific outputs (heading union, median word count, schema types, entity coverage, directives). It uses specific verbs ('fetch', 'return') and distinguishes itself by focusing on content brief evidence, which differentiates it from sibling tools like gsc_search_analytics or content_opportunities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly explains when to use each mode: 'Pass competitor_urls for a true brief; with none it falls back to your own ranking pages via GSC (refresh-vs-new, NOT the full SERP).' It also provides context about integration with other components ('The host writes the brief prose from this; SEOMonster supplies rules + evidence'). However, it does not explicitly state when not to use this tool or mention alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds value by specifying that findings are severity-graded with reasons and benign exceptions, and explicitly states it is read-only. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose and read-only nature, then concisely enumerates checks. It is somewhat verbose but every sentence provides useful detail. No redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool complexity (multiple checks, severity output) and simple schema, the description adequately covers what the tool does and the nature of its output. It does not detail the exact return format but that is partially covered by mentioning severity-graded findings, which is sufficient for an audit tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with the parameter description already stating format and default behavior. The tool description does not add additional semantics beyond the schema, so no extra benefit.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool audits a GA4 property's configuration for SEO-measurement readiness. It lists specific checks (web data stream, key events, data retention, custom dimensions, enhanced measurement, Google Signals) and clearly answers a specific question ('can this property actually measure my organic outcomes?'). This distinguishes it from sibling tools like ga4_run_report or gsc_coverage_audit, which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for assessing GA4 property readiness for organic measurement, and clarifies it checks hygiene, not business events. It does not explicitly state when not to use it or provide alternatives, but the context of answering a specific question gives reasonable guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, idempotentHint=true, destructiveHint=false, and openWorldHint=true. The description adds the auth requirement and availability, but does not explain behavior like error handling or confirmation of submission. With rich annotations, the description provides adequate but not exceptional additional context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loading the core purpose and essential requirements. Every sentence adds crucial information without redundancy. It is efficiently structured and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description could mention what the user can expect after submission (e.g., success confirmation or asynchronous processing). It covers auth, availability, and parameter choice, but misses result transparency. This is a moderate gap for a write operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description's contribution is additive. It explains the relationship between sitemap_url and feedpath, recommending sitemap_url as the friendly name. This adds value beyond the schema descriptions, which already include the alias information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Submit a sitemap') and the target system ('Search Console'). The verb-submit is unique among sibling tools, and the description distinguishes it from read-only tools like gsc_list_sitemaps by implying a write operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides useful guidance: required scope ('writable webmasters'), availability ('routine SEO task; not gated'), and preferred parameter ('sitemap_url' vs. 'feedpath'). It does not explicitly contrast this tool with siblings, but the unique action makes context clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral context beyond the annotations: classification into quadrants, cannibalization flagging, and the limitation that GSC hides ~47% of queries. This helps the agent understand the tool's constraints and outputs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is 4-5 sentences, front-loaded with the core purpose, and includes essential details without excessive fluff. Slightly verbose with 'Free, GSC-only' but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 params, no output schema) and rich annotations, the description covers input definition, processing logic, output content (quadrants, create queries), and limitations (GSC data gaps). It is fairly complete for a read-only analysis tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 6 parameters have schema descriptions covering 100%. The description does not add new per-parameter details but provides overall context on how parameters relate (e.g., cluster_path vs pillar_url). Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool maps a content cluster and surfaces missing subtopics, with specific actions and outputs. It clearly distinguishes from siblings focused on general GSC analysis or performance measurement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the tool (for mapping a content cluster using your own Search Console data) and how to define the cluster (via cluster_path or pillar_url). It lacks explicit exclusions or comparison to alternatives, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructiveHint=true; description adds valuable context about preflight target validation, loop/duplicate checks, and dry_run capability. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no redundancy. Front-loaded with core purpose, then safety features. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters, no output schema, the description explains key behaviors (validation, loop/duplicate prevention, dry_run) and gating. Could mention return value structure, but overall sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds minimal extra meaning beyond schema, primarily mentioning dry_run's purpose. Does not significantly enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a single dynamic redirect at the Cloudflare edge, with an example (301 for renamed/migrated URL). It distinguishes from siblings like cf_bulk_redirect_upsert (bulk) and cf_list_redirects (list).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit gating condition (requires SEO_MCP_ALLOW_DESTRUCTIVE=true) and mentions validation, loop/duplicate refusal, and dry_run support. However, no explicit when-not-to-use or comparison with alternative tools like cf_bulk_redirect_upsert.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide destructiveHint=true and readOnlyHint=false. The description adds the crucial gating requirement (SEO_MCP_ALLOW_DESTRUCTIVE) which is important behavioral context. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two concise sentences: the first states the purpose and the second notes the gating requirement. No extraneous text; every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the annotations and lack of output schema, the description covers the core purpose and access control. It does not detail success/error responses or rate limits, but for a simple cache purge tool, the completeness is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptive parameter descriptions. The tool description does not add any additional semantic information about the parameters beyond what the schema already provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Purge' with the resource 'Cloudflare cache' and explains the purpose ('so crawlers refetch updated content'). It clearly distinguishes from the sibling tool 'cf_purge_cache_all' which purges all cache, making the scope explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates when to use the tool ('gated: requires SEO_MCP_ALLOW_DESTRUCTIVE=true') and implies it is for specific URL purging after content updates. However, it does not explicitly state when not to use it or compare with 'cf_purge_cache_all', though the sibling name provides context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, and non-destructive behavior. The description adds that it returns data at p75 for specific metrics and a fixed number of periods (25), but does not elaborate on potential rate limits or data freshness. The value added beyond annotations is moderate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: the first states the core purpose and scope, the second connects it to a companion tool. Every word earns its place, with no redundancy. Highly efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 omits the return format (e.g., JSON structure) or pagination details. However, given the input schema is comprehensive and the tool has only 4 optional parameters, the description covers the primary usage scenario adequately. A small gap in output transparency.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description's extra guidance on the mutual exclusivity of url and origin ('Use this OR origin.') adds practical value. It also clarifies that metrics are snake_case CrUX names, which is not fully explicit in the schema. This improves usability beyond the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns the last 25 weekly collection periods of Core Web Vitals at p75 for a URL or origin via the Chrome UX Report History API. It distinguishes itself from psi_analyze by adding the trend axis, making its purpose specific and distinct from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a direct usage context by stating it complements psi_analyze with a trend axis. It also implies when to use (historical trend) vs. snapshot tools. However, it could explicitly mention not to use it for single-point data or when other siblings like crux_snapshot are more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false; the description adds behavioral details (sort order, default filter) beyond those annotations, with no contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero waste: first sentence delivers core function and key details, second adds wrapper context. Every part is essential.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the tool's output (landing pages with conversions, breakdown, sort) adequately for a simple read-only tool with 100% schema-covered params. No output schema exists, but the description covers the basics; minor gap in explicit column listing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description repeats default values that are also in schema, adding no new meaning beyond what the schema provides—baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists landing pages with conversions/key events, broken down by channel group, sorted descending, and defaults to organic search. It calls itself a 'convenience wrapper over ga4_run_report,' which distinguishes it from siblings like ga4_top_landing_pages or ga4_run_report.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for SEO analysis by stating 'the SEO view' and default organic filtering. It provides context but does not explicitly state when not to use or compare to alternatives, though siblings hint at differences.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, open-world, and idempotent. The description adds value by specifying date format support (ISO and GA4 relatives) and default values (dimensions, metrics, start_date), enhancing beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose. Efficient but could be slightly expanded to include more usage hints without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 10 parameters, no output schema, and annotations present, the description covers key behavioral aspects and parameter defaults. Lack of return value explanation is a minor gap, but overall fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds significant meaning: explains 'days' as convenience alias, 'limit' alias for row_limit, details on date formats, and structure for dimension_filter and order_by objects. This greatly assists parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it runs a GA4 report with arbitrary dimensions, metrics, date range, filter, and ordering. It is labeled as 'the workhorse GA4 tool', distinguishing it from specialized siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies general-purpose use but does not specify when to use alternatives or when not to use this tool. No explicit guidance on filtering to other GA4 tools like ga4_top_landing_pages.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds value by disclosing that the tool honestly reports absence of site-search data rather than implying zero demand, a behavioral trait beyond annotations. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences front-load the core purpose, add context (content-gap signal), and note edge-case behavior. No wasted words; every sentence is informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with 3 optional parameters and no output schema, the description adequately covers return fields (event count, sessions) and error handling (no data). Could mention pagination or result ordering, but limit parameter mitigates this.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All three parameters are fully described in the schema (100% coverage). The description adds minimal additional meaning beyond 'last N days', providing no new details about parameters. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves internal site-search terms, specifying the metric (searchTerm), dimensions (event count and sessions), and positions it as a content-gap signal. It also distinguishes itself from ga4_run_report as a convenience wrapper, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for site search data and mentions honest reporting when no data exists, but lacks explicit guidance on when to use this tool versus other GA4 tools (e.g., ga4_top_landing_pages). However, its specificity to site search and wrapper nature provide sufficient context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnly, idempotent), description adds specifics: cap of 25 URLs, per-URL results and failure lists, and graceful error handling. Does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences front-loading key info (cap, results, error handling) with no extraneous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately covers return structure (results per URL, list of failures) for an agent to understand usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. Description does not add extra parameter-level meaning beyond what schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it inspects multiple URLs in one call with a cap of 25, distinguishing it from the single-URL sibling 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.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implied usage for batch inspection; mentions per-URL error handling which guides appropriate use, but lacks explicit when-not-to-use scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds sorting behavior (by impressions descending) and selection criteria beyond the readOnlyHint and other annotations. It does not contradict annotations and provides useful context without major gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted text. Directly states purpose, selection criteria, and sorting. Front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters, no output schema, and many sibling tools, the description is fairly complete. It explains what is returned and the sorting, though it could mention typical use cases for output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 80% (4 of 5 parameters described). The description does not add significant extra meaning for parameters beyond what the schema provides, and it does not clarify the undocumented site_url parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool returns queries with high impressions but low clicks, identifying content opportunity signals. It uses a specific verb-resource combination and implicitly distinguishes from sibling tools like gsc_top_queries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description implies when to use: to find content opportunities where impressions exist but clicks are lacking. However, it does not explicitly state when not to use or mention alternatives, though the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly and idempotent. The description adds behavioral details: sorting by impressions descending and rationale for CTR lift, which is valuable beyond annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no waste, front-loaded with purpose. Every word contributes value, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description explains return format (rows sorted by impressions) and rationale. It covers filtering criteria (position, CTR, impressions min) but omits mention of limit parameter or pagination. Overall fairly complete for the complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with descriptions. Tool description does not add new meaning beyond the schema, only references 'top N positions' and 'below-target CTR' which align with existing parameter descriptions. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool identifies queries ranking in top positions with below-target CTR for optimization, using specific verbs and resource. It distinguishes itself from siblings like gsc_query_gaps (queries not ranking) and gsc_top_queries (all top queries, no CTR filter).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for title/meta-description optimization candidates, providing clear context. However, it does not explicitly state when not to use or compare to alternatives, leaving some implicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is clear. The description adds behavioral context: filtering by exact query match and returning rows by page dimension. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first provides clear purpose, second adds contextual relevance. No unnecessary words. Very concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given rich annotations (readOnlyHint, idempotentHint) and complete schema, the description provides sufficient context. The real-world cannibalization audit example adds completeness. No output schema, but standard rows are implied.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% coverage with descriptions for all parameters. The description adds minimal value beyond emphasizing 'exact query match', but schema already covers parameter semantics adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool returns pages ranking for a specific query with a specific use case (cannibalization audit). It uses a specific verb-resource combination and distinguishes itself from sibling tools like gsc_top_queries and gsc_top_pages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly frames the tool as input for a decannibalization audit and explains the action to take if multiple pages rank for the same query. While it does not state when not to use it, the context is clear enough for appropriate selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive. Description adds behavior: sampling, HEAD-checking, histogram generation, listing non-2xx. No contradictions. Could detail 'first few' but acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two precise sentences. Front-loaded with verb and resource. Every word adds value. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple sampling tool, the description sufficiently covers purpose and output (histogram, non-2xx list). No output schema, but description compensates. Could specify output format, but not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline 3. Description does not add significant meaning beyond the schema's parameter descriptions. Merely restates the sampling action.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb (sample, HEAD-check, aggregate) and resource (sitemap URLs) are clearly stated. Distinguishes from sibling 'sitemap_validate' which likely validates sitemap structure, not URL health.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage for triaging broken entries in sitemaps. Does not explicitly mention when not to use or compare to alternatives, but context with sibling tools makes it reasonably clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral context beyond annotations: it explains the render-blindness check, evidence-backed signals, and mentions that schema.org/FAQ are informational and not scored. This complements the annotations (readOnlyHint, openWorldHint) without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficient and front-loaded with the core purpose. It is concise but could benefit from clearer sentence breaks or bullet points for readability. Currently, it reads as a single dense paragraph.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given one parameter and no output schema, the description adequately explains what the tool does and its limitations (no guarantee of citation). However, it does not describe the return format or score range, which might be needed for an agent to interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with a clear description for 'url'. The tool description does not add additional meaning or usage tips for the parameter, so it meets the baseline for full schema coverage without extra detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: scoring a page's readiness for LLM citation. It lists specific checks (render-blindness, statistics, etc.) and distinguishes itself from siblings like 'ai_citation_track' by focusing on readiness assessment rather than tracking.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implicit usage context by explaining the methodology (leads with render-blindness check) and notes that it does not guarantee citation. However, it does not explicitly list scenarios when not to use or compare with alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds valuable behavioral context: the undercount disclaimer (~70% land as Direct) and the fact that AI-Overview clicks are excluded. This goes beyond what annotations provide but does not cover all potential edge cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact at two sentences with a semicolon, covering all necessary points without fluff. It is front-loaded with the main purpose and ends with an important caveat. Minor improvement: could use structured bullets for the two components, but current structure is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, prerequisites, and limitations well, but lacks any mention of return values or output format. Since the tool has no output schema, the description should at least hint at what the agent can expect (e.g., a JSON object with referral stats and crawl status). Parameters and annotations are well-covered, but output is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with parameter descriptions, but the tool description adds default behaviors (days defaults to 28, site_url defaults from GSC default site, property_id defaults to configured property) and functional grouping (days for GA4 referral, site_url for crawl coverage). This significantly enhances meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it provides a 'First-party view of AI traffic' with two specific components: AI referral sessions via GA4 and AI-crawler coverage via robots.txt. It names specific AI apps and bots, making the resource scope explicit. This verb+resource+scope structure distinguishes it from sibling tools like robots_ai_posture or ga4_organic_search_overview.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear prerequisites (GA4 property for referral, site_url for crawl coverage) and defaults for parameters. It includes an explicit honest bound about undercounting and AI-Overview clicks counting as Organic. However, it does not explicitly state when not to use this tool or mention alternative tools for similar tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnly, openWorld, idempotent, non-destructive) are consistent with description. Description adds behavioral details: chunking in batches of 25 (due to GSC limits), cap of 200 URLs, and heuristic nature. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is three concise sentences with no redundancy. Front-loaded with 'heuristic coverage audit', explains the gap, and ends with output utility. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, description adequately explains output (verdicts: PASS/PARTIAL/FAIL plus coverage_state frequencies) and how it can be used for further inspection. Covers input limits and purpose fully.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% description coverage; both parameters (urls, site_url) are described in schema. Description does not add new semantic information beyond schema, but the schema coverage is high, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool performs a heuristic coverage audit of URLs, acting as a substitute for the GSC Index Coverage report which is not available via API. It specifies the input is a user-supplied URL list and output is a rollup of verdicts. Differentiates from sibling tools like gsc_inspect_url by focusing on bulk audit and rollup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context that the tool fills a gap (missing Coverage API) and mentions how the AI host can use the rollup to decide on deep-inspection. Does not explicitly state when not to use or compare with alternatives, but the context is sufficiently clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate idempotent and non-destructive, but the description adds critical constraints (host restriction, HTTP 422 rejection, cap at 10000) that annotations don't cover. This provides valuable behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with purpose, followed by critical constraints. No unnecessary words, highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 2-parameter tool with full schema coverage and no output schema, the description is complete. It covers purpose, constraints, and limits, leaving no obvious gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already explains both parameters. The description adds host constraint context but doesn't elaborate parameter semantics further, meeting the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool submits multiple URLs in one batched request. It distinguishes from sibling 'indexnow_submit' by emphasizing batching and host constraint.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit constraints (same host, max 10000 URLs) and mentions IndexNow rejection behavior. Implicitly suggests use for bulk vs single, but lacks explicit alternatives or when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive. Description adds valuable behavioral details: BFS algorithm, same-host constraint, hard caps (max_depth ≤4, max_pages ≤200), and exact outputs. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences packed with essential information: algorithm, scope, outputs, constraints, and usage caveat. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description fully explains what the tool returns (per-page metrics, orphans, broken links, depth distribution) and its constraints (max depth, max pages). Sufficient for an agent to understand behavior and expectations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are well-documented. Description repeats the hard caps but adds no new semantic meaning beyond what the schema provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it performs a small BFS crawl within the same host and returns specific link metrics (in-degree, out-degree, orphans, broken links, depth distribution). This distinguishes it from sibling tools like GSC, GA4, or SEO audit tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states 'Not a replacement for a full crawler; sized for in-session triage,' providing clear context for appropriate use. Does not name alternative tools, but the sibling set is diverse enough that this guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnly, openWorld, idempotent, non-destructive. Description adds context about mixed content blocking scripts and triggering warnings, and the no-op behavior, which helps the agent understand consequences.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. First sentence explains the action, second adds context and edge case. Highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple one-parameter tool with no output schema, the description covers the action, edge case, and behavioral implications adequately. No missing information for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
One parameter 'url' with schema description 'Absolute https:// URL to inspect.' Schema coverage is 100%, so description adds minimal value beyond stating 'HTTPS page' and handling of http://. Baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool 'fetch[es] an HTTPS page and report[s] any sub-resource references that use plain http://', listing specific element types. This distinguishes it from sibling tools like gsc_*, cf_*, or robots_txt_validate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description explicitly says it's a no-op for HTTP pages (returns 'not_https'), implying usage on HTTPS pages. It does not explicitly state alternatives, but the purpose is distinct.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint, idempotentHint, etc. The description adds useful behavioral context (per-entity verdict, list of missing fields) and covers a fixed set of types, but doesn't contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences that front-load the primary action, then list return details and coverage. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite lacking an output schema, the description adequately explains what the tool returns (per-entity pass/fail verdict and lists of missing fields) and covers a broad set of rich result types, making it complete for its expected use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, meaning the schema already describes both parameters. The tool description adds no additional parameter information beyond what's in the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool validates JSON-LD blocks on a page against Google Rich Results required fields. It lists 10 specific schema.org types covered, which differentiates it from siblings like inspect_schema that may have a broader or different validation focus.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when checking structured data compliance and lists the supported types, but does not explicitly state when to avoid using it or mention alternative tools for other validation tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnly, openWorld, non-idempotent, non-destructive. Description adds 'Paid + non-deterministic', 'results are directional and dated', and warns about API-UX discrepancies, providing behavioral context beyond annotations without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is a single cohesive paragraph that front-loads the core function. It's dense with useful information but could be slightly improved with structured formatting. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Description covers input (managed prompt set, brand, engines, samples, competitors, brand domains), process (sampling, confidence interval, share-of-voice, volatility), and limitations (directionality, datedness, API differences). With no output schema, it adequately explains expected results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and description adds valuable context for parameters: 'freeze it across cycles' for prompts, 'default 7 (>=7 recommended)' for samples, and 'Your domain(s) to detect in citations' for brand_domains, enhancing schema descriptions meaningfully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool tracks brand mention and citation share-of-voice across AI answer engines for a managed prompt set. It specifies the action (track), resource (brand mentions/citations), and scope (compared to competitors), distinguishing it from all sibling tools which focus on different domains like GSC, GA4, or Cloudflare.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description provides explicit context on when to use ('NOT an AI rank', 'single runs are statistically meaningless') and limitations (developer-API vs consumer UI, AIO has no API). It doesn't explicitly state when not to use or list alternatives, but the tool's uniqueness among siblings makes these implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses all-or-nothing validation, async addition, and dry_run support beyond what annotations provide. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no wasted words. Purpose upfront, followed by gating and behavior, then async note.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, gating, validation, dry_run, async. Lacks description of return value or response structure, but overall adequate for a complex bulk operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so description adds little beyond schema. It reinforces the confirm and list_name relationship but no new parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates or appends many redirects via a bulk redirect list for site migrations. It distinguishes from siblings like cf_create_redirect (single) and cf_delete_redirect.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit gating conditions (destructive env variable and confirm value) and mentions dry_run. Does not explicitly list alternatives, but the context implies when to use single vs bulk tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructive and non-readonly nature. Description adds context: gating via environment variable and string confirmation, plus global impact. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficient sentences: first states purpose and effect, second explains gating. No superfluous words. Front-loaded with key action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, scope, and gating. Does not detail post-purge behavior (e.g., cache rebuild), but for a destructive tool with annotations, this is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover both parameters (zone with default, confirm must equal hostname). The description reinforces the confirm requirement in the usage context, adding value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states specific verb ('Purge') and resource ('entire Cloudflare cache for a zone'), with scope ('affects all visitors'). Clearly distinguishes from sibling cf_purge_cache (likely partial purge).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly describes gating conditions (env var + confirm value) needed to invoke the tool. Does not mention alternatives or when not to use, but the safety mechanism is well communicated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, non-destructive, etc. Description adds that it returns declining pages, providing behavioral context beyond annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: first defines output, second gives use case and sibling equivalence. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 parameters with full schema coverage and no output schema, the description is complete enough. It could mention return fields but sibling tools provide context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% description coverage, so baseline is 3. Description does not add extra meaning beyond what the schema already provides for each parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns pages whose impressions fell over two periods, and explicitly equates it to a sibling tool with specific parameters, distinguishing it from similar tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states the use case: 'lifecycle triage (find pages to invest in or rescue)'. Also notes equivalence to gsc_compare_periods, helping the agent choose between them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate idempotentHint=true and destructiveHint=false, so the safety profile is clear. The description adds value by disclosing the need for an API key and a verification file, which is important context beyond what annotations provide. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the core purpose and engines, followed by essential requirements. Every word adds value; no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple mutation tool with no output schema and only two parameters, the description provides sufficient context: what it does, when to use it, and what is required. It could optionally mention success/error behavior, but that is not critical for basic usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so both parameters ('url' and 'skip_preflight') are fully described in the schema. The description does not add new semantic information about the parameters; it merely reinforces that a single URL is submitted, which is already stated.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('submit a single URL to IndexNow') and lists the target search engines (Bing, Yandex, Naver, Seznam, Yep). It also distinguishes itself from the sibling tool gsc_request_indexing by specifying it covers non-Google engines.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states that this tool complements gsc_request_indexing for non-Google engines, providing clear guidance on when to use it versus the alternative. It also lists prerequisites (SEO_MCP_INDEXNOW_KEY and a key-verification file), aiding proper invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description provides detailed behavioral information beyond annotations, including specific checks (oversize, missing lastmod, host mismatch) and handling of .gz. Annotations already confirm read-only and idempotent, so the description adds valuable transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with three sentences that front-load the core action and efficiently detail specific checks and .gz handling. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers input, actions, and specific validations. However, it lacks explicit information about the return value or response structure, which would be helpful given no output schema. Otherwise, it is comprehensive for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully describes the single parameter. The description restates 'sitemap or sitemap-index URL' but does not add additional meaning or examples. With 100% schema coverage, baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (fetch and validate), the resource (sitemap URL), and specific checks (oversize, missing lastmod, host mismatch). It distinguishes from siblings like gsc_list_sitemaps and sitemap_health by focusing on XML structure validation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use the tool (for validating sitemap XML) and indirectly distinguishes from siblings by specifying validation criteria. However, it does not explicitly state when not to use or list alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint. Description adds valuable context about probe making live calls and config-only default, enhancing transparency beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, fully front-loaded with key info, no redundant words. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, description covers all reported aspects sufficiently for an agent to understand what the tool returns. Lacks explicit return type but standard for such tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters. Description adds meaning by explaining default behavior (false: config-only) and what probe=true does, exceeding the schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states it reports which SEO services are configured, auth method, destructive mode, and tool catalog. It clearly distinguishes from sibling tools that perform specific actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Includes explicit guidance: 'Call this first if unsure what is set up.' Provides context for the probe parameter but lacks explicit when-not scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructiveHint. The description adds context about safe usage before mutation tools and mentions the output fields. However, it does not elaborate on pagination or behavior for large accounts.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences: purpose, usage guidance, and pairing. No wasted words. Information is front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only listing tool with no output schema, the description adequately describes what is returned (specific fields of redirect rules and Bulk Redirect lists). It also mentions the default zone behavior, making it complete for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the description does not add information beyond the schema's parameter docs. The tool description does not elaborate on the zone parameter beyond what is in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists a zone's single redirect rules and the account's Bulk Redirect lists, specifying the fields returned (source, target, status code, rule id). This verb+resource combination is distinct and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly instructs to call this before cf_create_redirect, cf_delete_redirect, and cf_bulk_redirect_upsert to prevent clobbering, and mentions pairing with redirect_chain_audit and migration_check prompt. This provides clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, openWorldHint, idempotentHint, destructiveHint=false. The description adds behavioral context: it is read-only, fuses multiple signals into a transparent opportunity score, flags cannibalization, and reports click upside and score components. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words. The first sentence states the core purpose and output, the second clarifies limitations. Front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately describes the return value ('click upside plus the score's components'). It covers input parameters implicitly and explains the tool's scope and limitations, making it complete for an agent to decide usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear parameter descriptions. The tool description provides no additional parameter-specific details beyond summarizing the overall purpose. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Rank') and resource ('data-grounded content/blog topics from your own Search Console data'), and clearly distinguishes itself by stating it 'does not do cold-start keyword research' and focuses on existing demand, differentiating from sibling tools like keyword_universe.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: 'prioritize demand you already have'. Also clearly states what it does not do: cold-start keyword research, writing content, or guaranteeing ranking. While it doesn't name specific alternatives, the context signals list many sibling tools, and the description implies when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark it as readOnly, idempotent, and non-destructive. The description adds valuable behavioral context: it returns a specific 28-day snapshot, uses p75 percentiles, and outputs per-metric categories plus an overall verdict. It also clarifies that no_data is a legitimate response for small sites, which is helpful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no fluff. Front-loads the core action and key details (metrics, time range, API). Every sentence adds value and the structure is highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately explains the return value (metrics, categories, overall verdict) and the possibility of no_data. It also mentions the underlying API. For a simple read tool with 3 well-described params, this is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with good descriptions on each parameter. The description adds that url and origin are mutually exclusive alternatives, which is already implied in the schema descriptions. It does not significantly enhance parameter understanding beyond what the schema provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns the current 28-day p75 Core Web Vitals snapshot for a URL or origin, listing exact metrics (LCP, INP, CLS, FCP, TTFB) and their categories. It distinguishes itself from the sibling tool crux_history by noting the difference between snapshot and trend.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly directs to use crux_history for 25-week trends and explains that small pages/origins may return no_data, setting appropriate expectations. This provides clear guidance on when to use this tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, not destructive. The description adds valuable behavioral details: returns per-key deltas, includes keys in only one window, and explains the anomalies_only output (sigma_used). No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph but well-structured: front-loads the core purpose then details. Every sentence provides value, though slightly dense. Could be broken into two sentences for readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema, the description explains return values (per-key deltas, keys in only one window, filters_applied.sigma_used). It covers the main behavioral aspects adequately, though it could mention the response structure more explicitly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, baseline 3. The description adds context beyond the schema, such as the note about sort_dir for delta_position reversal and the z-score cutoff explanation for anomalies_only. This enhances parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: compare two equal-length time windows and return per-key deltas. It distinguishes itself from siblings by noting that it covers multiple comparison types (biggest gainers, losers, movers, outliers) without needing separate tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the tool (comparing periods, finding gainers/losers/outliers) and describes optional filters and the anomalies_only feature. It does not explicitly state when not to use it, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds value by noting that permission levels are returned, offering behavioral context beyond what annotations convey. There is no contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is composed of two short, precise sentences that convey the purpose and a usage hint. There is no redundant or unnecessary information, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (zero parameters, no output schema), the description is fully adequate: it states what the tool does, what it returns (permission levels), and why to use it (discover site_url values). No gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters (schema is empty), so schema description coverage is 100%. The description does not need to elaborate on parameters; a baseline of 4 is appropriate for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') with a clear resource ('every Search Console property') and adds context ('with each property's permission level'). It distinguishes this tool from siblings by its unique role of enumerating properties for discovery of valid site_url values.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises to 'Use this to discover valid site_url values', which provides clear context for when to invoke the tool. However, it does not mention when not to use it or provide alternatives, which slightly limits the guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate it's read-only and idempotent. The description adds value by detailing the output fields and mentioning the data state and alias convention, going beyond annotation hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each purposeful. The first front-loads the core purpose, the second specifies output and use case, the third adds technical details. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and rich annotations, the description fully covers purpose, return format, filtering options, and behavioral details. No gaps for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with parameter descriptions. The description adds the alias convention for the 'days' parameter, providing extra context beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists every property and returns a one-row summary per property with specific metrics. It distinguishes itself from siblings like gsc_list_properties and gsc_search_analytics by positioning as a portfolio-level view.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states it's the fastest answer for portfolio performance across multi-property setups, providing clear context. However, it does not explicitly mention when not to use it or list alternative tools for deeper analysis.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate write, idempotent, non-destructive. Description adds specific behavioral details: batch error handling, notify_time null being normal, scope error remediation. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, no wasted words. Front-loaded with purpose then usage and edge cases. Each sentence adds necessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description covers error behavior and expected null value. Could mention success response structure, but for a simple write tool it is adequate. Context of scope and availability is given.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds value beyond schema: clarifies that url or urls is required (schema lists no required), explains site_url as informational/project-scoped, and reinforces max 100. This is helpful for proper invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States clear action: 'Ask Google to (re)crawl one or more URLs via the Indexing API (URL_UPDATED)'. Verb+resource+method is specific and distinct from siblings like indexnow_submit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly mentions required scope ('Requires the indexing scope') and availability ('Available by default'). Describes error handling for scope/per-URL errors. Lacks explicit mention of alternatives like indexnow_submit, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive. The description adds valuable behavioral context: default data_state of 'all' and that 'final' lags 2-3 days behind the dashboard. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero wasted words, front-loaded with purpose and key equivalence. Efficiently conveys all essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple wrapper tool with no output schema, the description covers purpose, equivalent tool, data lag, and parameter defaults. It is fully adequate for an agent to understand invocation and behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with descriptions. The description adds context that results are sorted 'by clicks' and mentions default values for days and limit, which are also in schema but reinforces usage. Adds meaning beyond schema by noting equivalence and data_state.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a 'convenience wrapper' that returns top pages for a property by clicks over N days, and explicitly equates it to gsc_search_analytics with dimensions=['page']. This distinguishes it from siblings like gsc_search_analytics and gsc_top_queries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for quick top-pages retrieval by calling it a 'convenience wrapper' and noting data_state behavior. It does not explicitly state when to use this vs. gsc_search_analytics or other tools, but the equivalence provides clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint, openWorldHint, idempotentHint, destructiveHint=false) already indicate safe, read-only behavior. The description adds clarity about what it reports (counts and samples) without adding behavioral nuance beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action, and every word adds value. No wasted content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read tool with annotations, the description is complete. It describes input (URL), output (counts and sample), and references a sibling tool for next steps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema's parameter 'url' is described as 'Absolute http(s) URL to inspect.' With 100% schema description coverage, the description adds no additional meaning beyond what the schema provides, meeting the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool extracts all JSON-LD blocks from a page and reports schema.org @type counts plus a sample entity per type. It explicitly calls itself a discovery tool, distinguishing its purpose from validation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: 'Discovery tool: tells you what structured data exists. Pair with validate_schema to check required-field compliance.' This tells when to use it and suggests a complementary tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare it safe, idempotent, and non-destructive. The description adds the specific return types and default strategy, which is useful behavioral context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with front-loaded action and outputs. No unnecessary words, every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool returning multiple metrics with a default strategy, the description covers key aspects: what it returns, default behavior, and when field data is available. No output schema but description suffices.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds the rationale for the mobile default, improving understanding beyond the schema's enum description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool runs PageSpeed Insights and returns specific scores and vitals, distinguishing it from sibling tools like psi_opportunities which focus on optimization opportunities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly notes the default mobile strategy and why, providing clear context. No explicit alternatives or when-not-to-use cases are mentioned, but the scope is well-defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnly, idempotent, non-destructive. The description adds details: uses clicks data, returns lift with CI and verdict, includes confounders block. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph that packs key information (method, return, caveats) efficiently. It is front-loaded but could be slightly more structured. No wasted sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 9 parameters and no output schema, the description explains return values (lift, CI, verdict, confounders) and why clicks are used. It covers key context, though a note on example usage would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with per-parameter descriptions. The tool description adds methodological context but does not significantly enhance parameter semantics beyond what the schema already provides. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool estimates whether an on-site change moved a page's clicks using difference-in-differences. It specifies the exact purpose and distinguishes it from siblings, which are mainly data retrieval tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly notes that this is observational and not proof of causation, advising that a server-side split test is needed for true causal evidence. It also mentions data limitations (GSC bugs), guiding correct usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behavioral traits: the mutual exclusivity of managed robots.txt and Content-Signals policy, the local rejection of invalid combinations, the gating of writes via confirm, support for dry_run, and that the return always includes a caveat. Annotations indicate destructiveHint=true and readOnlyHint=false, which align with the description; the description adds significant context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively long but well-structured, starting with the overall purpose, then detailing actions, then constraints, and ending with return information. Every sentence contributes essential information. Minor redundancy could be trimmed, but it remains efficient for its complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (3 actions, 9 params, mutual exclusion, gates, no output schema), the description covers all necessary behavioral aspects: actions, parameter roles, constraints, gating, dry_run, and return caveat. Annotations complement but do not reduce the burden; the description is fully adequate for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with descriptions for all 9 parameters. The description adds value by explaining the purpose of parameters in context (e.g., what 'configure only' means, the valid combinations, and the role of each protection lever). However, much of the parameter meaning is already clear from the schema, so the description provides incremental but meaningful depth.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool manages Cloudflare's managed robots.txt and Content-Signals policy, enumerating three distinct actions (get, configure, disable) with specific behaviors for each. It distinguishes the tool's scope from siblings, which are mostly unrelated (GSC, PSI, etc.), and provides a specific verb+resource combination.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use each action (get for reading, configure for enabling/setting, disable for turning off), mentions that writes require confirm and support dry_run, and notes the mutual exclusivity constraint. It does not explicitly list when not to use the tool, but the actions are self-explanatory and no direct sibling alternatives exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, etc. The description adds value by explaining read-only nature, why checks are 'verify' not 'fail', and that it grades only edge layer. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is fairly long but well-organized with front-loaded purpose. It includes bullet-like list and specific details. Could be slightly more concise, but no wasted sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, description is complete. It hints at return format (severity-graded findings with reason and benign exception) and answers the core question. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter `zone` with schema coverage 100%. Description adds context about defaulting to configured CF_ZONE, which is extra beyond schema. Baseline 3, so 4 for added value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it audits Cloudflare zone settings for SEO and crawl/index safety, listing specific settings checked. It distinguishes itself from sibling tools like cf_settings_update and cf_zone_info by focusing on audit and safety grading.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use: to check edge settings for SEO safety. It provides context about HSTS danger and 'verify' phrasing, but does not explicitly state when not to use or compare directly to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description provides extensive behavioral details beyond the annotations: it crawls from start_url, uses GSC for striking-distance targets, ranks by lexical relevance and internal in-degree, skips already linking pages, balances anchor text, and never suggests nofollow. This aligns with the readOnlyHint and indicates no destructive behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences, front-loaded with the core purpose, and every sentence adds meaningful detail without redundancy. It efficiently covers the tool's functionality, constraints, and caveats.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite lacking an output schema, the description hints at the output format ('source page -> target page, with anchor text'). Given the complexity of the tool (9 parameters, custom algorithm) and rich annotations, the description is largely complete. However, it could briefly mention the response structure or further clarify the 'striking-distance' concept for total completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, the description adds value by explaining the algorithm context, e.g., 'default position 8-20' for position_min/max and 'default 28' for days. While the schema already describes each parameter, the description integrates them into the overall process, helping an agent interpret how parameters affect the recommendation logic.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Recommend specific internal links (source page -> target page, with anchor text) from high-authority pages to striking-distance pages.' This is a specific verb-resource combination that distinguishes it from sibling tools like gsc_search_analytics or internal_link_graph, which have different focuses.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool: when you need internal linking recommendations based on authority and striking-distance targets. It states it is 'free; read-only' and does not guarantee ranking change, setting expectations. However, it does not explicitly compare to alternatives or state when not to use it, missing some guidance for an AI agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnly, idempotent), the description adds significant behavioral context: it requires DataForSEO/Google Ads configuration, is paid/optional, explains the provider chain for volume data, and warns about 2026 signal degradation. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the core value proposition. Every sentence serves a purpose, covering the main function, competitive advantage, optional features, prerequisites, and a future caveat. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (paid, external, gap analysis, optional volume, no output schema), the description covers essential aspects: what it does, prerequisites, limitations. It lacks explicit return format details, but the description sufficiently implies the outputs (list of gap keywords or volume metrics).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds value by explaining how parameters relate to the core gap analysis (competitors, target_domain) and optional volume lookup (keywords), and sets expectations for limit. This enriches understanding beyond schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides external keyword data with a core value of competitor keyword gap analysis. It distinguishes itself from sibling tools by noting it uses DataForSEO and has no Google equivalent, making its purpose unique.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool, highlighting its competitive gap functionality and optional volume data. It implicitly differentiates from Google-based tools by stating 'no Google equivalent' and warns about signal degradation, but could more explicitly state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds value beyond annotations by stating that unknown budget keys are surfaced as non-fatal findings with hints (not silently ignored), and it describes the return value (per-metric verdict and overall pass/fail). This supplements the readOnlyHint, openWorldHint, idempotentHint, and destructiveHint annotations, with no contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the primary action, then systematically covers budget keys, return behavior, and usage hint. Every sentence adds value without redundancy. It is compact yet comprehensive.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters (one nested object) and no output schema, the description is remarkably complete. It explains required and optional parameters, budget key validation, error handling for unknown keys, and the return format. Edge cases are addressed, making it self-sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the input schema has 100% coverage with descriptions, the description adds significant meaning: it explains the scale for scores (0-100, not decimal), latency units (milliseconds), CLS unitless, and provides an example. It also elaborates on the budget dictionary behavior. This enriches the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: run PageSpeed Insights on a URL and compare results against a performance budget. It specifies the verb ('run', 'verdict') and resource ('PageSpeed Insights', 'performance budget'), and differentiates from siblings by focusing on budget enforcement rather than general analysis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly mentions the tool is useful as a CI/pre-deploy gate, providing clear when-to-use guidance. It also explains behavior for unknown keys. However, it does not directly contrast with sibling tools like 'psi_analyze' or mention when not to use, though the context is strong enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description aligns with annotations (readOnlyHint, non-destructive) and adds valuable behavioral context: winnability signals, zero-click risk, domain authority, and information-gain. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three clear sentences, front-loaded with purpose, no redundancy. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 adequately explains what is returned (winability signals, domain authority). Lacks explicit output structure, but sufficient for understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and descriptions are provided. The description adds context beyond schema, such as 'free' for competitor_urls and DataForSEO requirement for query, enhancing parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool identifies SERP gaps ('headings, entities and schema') and turns them into actions. It distinguishes from siblings by its specific gap analysis focus, and no sibling tool has overlapping verb+resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly provides two usage paths (competitor_urls or query with DataForSEO) and notes read-only and no ranking guarantee. It doesn't explicitly mention alternatives among siblings, but the tool is unique in function.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true, so description does not need to reiterate. However, description adds important behavioral context: the gating by an environment variable (SEO_MCP_ALLOW_DESTRUCTIVE), which is not in annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences that deliver all critical information without unnecessary words. Front-loads the purpose and includes key usage context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple deletion tool with well-defined parameters and annotations, the description covers purpose, input source, and access control. No output schema is needed, and sibling tools provide relevant context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already covers both parameters with good descriptions (100% coverage). The description adds value by clarifying that rule_id comes from the cf_list_redirects tool, aiding the agent in understanding the data flow.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete one single (dynamic) redirect rule'), the resource ('redirect rule'), and the identifier ('by its id'). It also distinguishes itself from cf_create_redirect as the rollback path.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly explains when to use this tool (as the rollback path for cf_create_redirect) and where to obtain the required input ('Get the rule id from cf_list_redirects'). Also mentions the gating condition requiring SEO_MCP_ALLOW_DESTRUCTIVE=true.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds value by explaining the edge-measured traffic nature and how it complements GA4, providing behavioral context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise—three short sentences that are well-structured. The first sentence states the tool's purpose, the second explains the two usage modes, and the third provides additional context and limitation. No superfluous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of an output schema, the description could be more explicit about return data structure (e.g., 'returns site details including metrics'). However, the tool is simple and the domain is well-known, making it adequate for an experienced agent. The openWorldHint annotation also helps set expectations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter host_or_tag is fully described in the schema. The description adds parsing logic (hostname vs. site_tag) that goes beyond the schema description, giving clear semantic meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool is for Cloudflare Web Analytics (edge RUM), specifies two modes of operation (listing all sites or retrieving a site's detail), and distinguishes it from GA4 by mentioning edge measurement. The purpose is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly explains when to use the tool without arguments (list all sites) and with the host_or_tag parameter (get one site's detail). It also notes that create/delete operations are intentionally not exposed, guiding the agent away from writing operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark readOnlyHint and idempotentHint. The description adds critical behavioral context: explains the 'footprint verdict' and confidence band, and crucially discloses that GSC hides ~75% of impressions, making results hypothetical. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise at 7 sentences, front-loaded with purpose, each sentence adds necessary detail without redundancy. Well-structured for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema, the description adequately explains the return (footprint verdict and confidence band) and addresses the hypothetical nature of results. Covers all key aspects of use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters, but the description adds value by explaining how to obtain candidates ('brainstorm from winning queries') and for 'days' adds 'wider = more footprint visible'. This enriches understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Ground... candidates to find net-new terms') and clearly distinguishes from sibling tools like gsc_top_queries by recommending it as a prerequisite. It leaves no ambiguity about the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs the user to brainstorm candidates from gsc_top_queries first, providing clear context. However, it does not explicitly mention when to avoid this tool in favor of other siblings like gsc_query_gaps, though the workflow is implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, etc. Description adds value by explaining data_state behavior and the equivalence to gsc_search_analytics, which provides deeper behavioral understanding.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no fluff, immediately states purpose. Efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple wrapper tool, description covers purpose, alternative, data_state nuance, and parameter defaults. Without output schema, it provides sufficient context for usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with parameter descriptions. Description adds default values (days=28, limit=50, site_url defaults to configured) and explains the meaning of the equivalent query dimensions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly specifies it is a convenience wrapper for top queries by clicks over last N days, equivalent to gsc_search_analytics with dimension 'query'. It differentiates from siblings like gsc_search_analytics and gsc_top_pages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides context as a 'convenience wrapper', implying simpler alternative to gsc_search_analytics. Notes data_state behavior and default settings. Could be more explicit about when not to use, but sibling names guide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, idempotentHint), the description adds that it is offline, makes no network calls, performs no writes, and always includes trade-off alternatives and mandatory caveats about Content-Signal being honored by adopting crawlers and ignored by Googlebot.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two well-structured sentences that front-load the primary action and output, then list key behavioral properties and return characteristics. Every sentence adds essential information with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only two optional parameters, rich annotations, and no output schema, the description is sufficiently complete. It explains the input (business goal), output (artifact and trade-offs), behavioral constraints, and important caveats about Content-Signal recognition.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and describes both parameters clearly. The description adds context about the output (artifact, trade-offs) and ties the goal parameter to business goals, but does not elaborate on the sitemap_url parameter beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool recommends a Content-Signals posture and emits a ready-to-apply artifact including a directive line and robots.txt. This is specific and distinguishes from sibling tools like robots_txt_validate or cf_managed_robots which do different tasks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the tool is read-only, offline, deterministic, and always returns trade-offs and a caveat. It implies usage for generating a posture recommendation but does not explicitly contrast with other robots.txt tools or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds valuable behavioral details: graceful degradation without a DataForSEO key, and the autocomplete endpoint being undocumented and subject to change. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with 5 sentences, each adding essential information. It is front-loaded with the main purpose and well-structured, with no redundant or unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 parameters, no output schema), the description fully explains what it does, how to use it, what it returns (per-seed suggestions + net-new terms), and its limitations. No gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters. The description adds meaning beyond the schema by specifying that 'seeds' should come from gsc_top_queries and that 'include_paa' defaults to true when DataForSEO is set. This helps the agent choose appropriate values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Expand' and the resource 'seed terms into adjacent terms from SERP signals'. It distinguishes from sibling tools like gsc_keyword_expand by specifying SERP signals (Google Autocomplete, PAA, related searches) rather than GSC data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear usage guidance: pass winning queries as seeds (seed from gsc_top_queries), notes the free core and optional DataForSEO features, and explains graceful degradation. It does not explicitly state when not to use it or list alternative tools, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds significant behavioral context beyond annotations: fetching, parsing rules, using RFC 9309 longest-match for probing. Annotations already declare readOnly, idempotent, safe; description enriches with exact behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with main action, no redundancy. Every sentence is necessary and informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 2 parameters, 100% schema coverage, no output schema but description explains outputs (structured ruleset, per-probe verdicts). Complete for a parsing/probing tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage; description adds meaning: site_url is relative for fetching, probes return 'allow/deny verdicts using RFC 9309 longest-match'. This enriches parameter understanding beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches /robots.txt, parses user-agent groups, Allow/Disallow, Crawl-delay, Sitemap, and optionally probes URL pairs. It distinguishes from siblings like robots_ai_posture which focuses on AI posture.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Purpose is clear: validate robots.txt and optionally probe URLs. While no explicit when-not or alternatives are given, the context among siblings (robots_ai_posture, cf_managed_robots) implies it's for parsing and verification.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations show destructiveHint=true and readOnlyHint=false, matching description's 'Write' and 'Gated: requires...DESTRUCTIVE'. Description adds local validation, dry_run preview, and specific confirmation requirements for ssl_mode/HSTS, going well beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is a single, dense paragraph of four sentences. Every sentence adds value: purpose, gating, special confirmations, validation, and dry_run. No unnecessary words. Front-loaded with main action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given moderate complexity (5 params, nested objects, interdependencies) and no output schema, description covers workflow, gating, and parameter constraints well. However, it lacks explicit mention of the response format for actual updates (only mentions dry_run preview). Minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed descriptions. Description adds critical context: 'Only the provided keys are changed' for settings object, explains confirm and acknowledge_hsts_risk conditions, and dry_run behavior. This meaningfully supplements schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool writes Cloudflare zone settings that cf_settings_audit grades, closing the audit-to-remediate loop. It uses a specific verb 'Write' and distinguishes from sibling tool cf_settings_audit which is read-only.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (remediate audit findings) and provides multiple usage conditions: requires SEO_MCP_ALLOW_DESTRUCTIVE=true, confirm parameter for sensitive changes, acknowledge_hsts_risk for HSTS, and supports dry_run. No sibling confusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![seo-monster MCP server](https://glama.ai/mcp/servers/avansaber/seo-monster/badges/card.svg)](https://glama.ai/mcp/servers/avansaber/seo-monster)

Score Badge

Copy to your README.md:

[![seo-monster MCP server](https://glama.ai/mcp/servers/avansaber/seo-monster/badges/score.svg)](https://glama.ai/mcp/servers/avansaber/seo-monster)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/avansaber/seo-monster'

If you have feedback or need assistance with the MCP directory API, please join our Discord server