google-seo-mcp

by Akxan

Overview Schema Source Related Servers Score Discussions Admin

TypeScript

Hybrid

Server Quality Checklist

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

Latest release: v0.3.0
Disambiguation3/5
Most tools have distinct purposes, but the large number creates some overlap—e.g., gsc_site_snapshot vs gsc_search_analytics, gsc_opportunities vs gsc_ctr_opportunities, and page_audit vs site_crawl all have similar scopes. The detailed descriptions help, but an agent could still hesitate between closely related tools.
Naming Consistency4/5
Tool names consistently use lowercase_snake_case and frequently follow a service-prefix pattern (gsc_, ga_, github_, llms_txt_, schema_). Minor deviations like 'pagespeed' and 'robots_check' are still readable and match the overall style, so the naming is predictable and coherent.
Tool Count1/5
With 51 tools, this server far exceeds the typical well-scoped range of 3-15 tools. While the breadth covers many SEO facets, the sheer number makes the server feel like a bundle of multiple specialized MCPs rather than a single focused toolkit, and it likely overwhelms an agent's tool-selection process.
Completeness5/5
The toolset covers an exceptionally wide range of SEO workflows: crawling, audits, search performance, analytics, schema, social previews, keyword research, content refresh, migration checks, and more. It also integrates external services (GSC, GA, GitHub, Brave, Places, CrUX) so that most common SEO tasks can be executed without leaving the server.
Average 4/5 across 49 of 51 tools scored. Lowest: 3.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 5 commits in the last 12 weeks
- Last stable release on September 9, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
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 declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile fully. The description adds the output scope (per-appearance-type clicks/impressions plus top pages), which is mildly useful context, but discloses nothing beyond that, such as aggregation behavior or data availability nuances. Consistent with annotations, so 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?
A single, front-loaded sentence that leads with the purpose and packs the data details efficiently. No filler or repetition of schema content.
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 carries the burden of explaining return values, which it does at a high level (clicks/impressions per type, top pages). With 4 parameters, one required, and safety annotations present, this is a reasonably complete report-tool definition, though it omits date-range aggregation behavior that the agent must infer from the schema.
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 75%, with endDate, startDate, and siteUrl well documented in the schema itself. The description adds little parameter-specific meaning; the mention of 'top pages for each appearance type' loosely maps to pagesPerType, but that parameter still lacks an explicit schema description and the tool description doesn't clarify it either. The description neither compensates for nor worsens the moderate coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Show how the site appears in Google results') with the exact data returned (clicks and impressions per search appearance type, top pages). The enumerated appearance types (rich results, FAQ, review snippet, video, AMP, Discover) make the scope concrete. It doesn't explicitly name the closest sibling gsc_search_analytics to differentiate, but the 'search appearance type' focus implicitly distinguishes it.
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 choose this tool over alternatives. With siblings like gsc_search_analytics (general query/page analytics) and gsc_index_coverage (indexation status), the agent receives no criteria for picking this report vs others. No exclusions, no alternative tool named.
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, idempotentHint, and non-destructive behavior, so the description need not repeat these. It adds context that a comparison date range introduces a 'dateRange' dimension and lists common dimensions/metrics, but it does not disclose return format, pagination behavior, or rate limits. This is acceptable given 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with the core purpose, and uses a few sentences to convey key information. The list of common dimensions/metrics is useful but slightly lengthy; it earns its place by guiding parameter selection. No unnecessary 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 report tool with no output schema, the description provides enough to call it correctly: property ID, dimensions, metrics, date range, and optional comparison. It points to ga_get_metadata for extended metadata. Missing details like return format are minor given the tool's nature and the provided annotations.
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 53%, and the description compensates by listing common dimensions and metrics, which helps agents populate the arrays. It also explains that compareStartDate adds a 'dateRange' dimension, adding meaning beyond the schema. The pointer to ga_get_metadata further supports parameter discovery.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool runs a Google Analytics 4 Data API report, lists common dimensions and metrics, and points to ga_get_metadata for discovery. It implies a distinction from real-time and comparison tools but does not explicitly contrast with siblings like ga_run_realtime_report or ga_compare_periods.
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?
The only usage guidance is 'Use ga_get_metadata to discover more.' It does not state when to use this tool versus alternatives like ga_run_realtime_report or ga_compare_periods, nor does it mention prerequisites or exclusions. The optional comparison date range hints at overlap with ga_compare_periods but is not clarified.
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?
The annotations already declare readOnlyHint and idempotentHint, and the description aligns with those. However, it does not add extra transparency about pagination, ordering, or any side effects beyond what annotations already cover.
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 extremely concise, using only a few words to convey the core functionality. No unnecessary fluff or redundancy.
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 the basic scope but omits important context such as pagination behavior, ordering, or the significance of the 'limit' parameter. Given the simplicity of the tool, it is adequate but not fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25% (only 'repo' has a description). The description partially explains 'branch' and 'path' but does not mention 'limit' or its default/maximum values, leaving users without full 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 action ('List'), the resource ('recent commits'), and the scope ('of a branch', optionally 'touching a path'). It is unambiguous and easily distinguishable from sibling tools like github_list_dir or github_commit_files.
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?
The description does not explicitly state when to use this tool over alternatives, nor does it mention any prerequisites or conditions beyond the optional path filter. There is no guidance on 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the return field set (name, type, size, sha) and implies a non-recursive listing, but does not disclose potential edge cases (e.g., missing path, pagination, or whether subdirectories are included). Given the annotation coverage, this is adequate but not rich.
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, focused sentence that immediately states the core purpose and the returned information. It is concise, front-loaded, and contains no filler. Every word adds value.
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?
For a simple listing tool with three parameters and no output schema, the description covers the basic return fields and purpose. However, it omits clarification on the 'ref' parameter, recursion behavior, and error conditions. It also does not reference any sibling tools to guide selection, which is a gap given the large sibling set. The description is functional but not fully complete for an agent operating autonomously.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% (only 'repo' has a description). The tool description mentions 'path' implicitly but does not explain the 'ref' parameter at all. It also does not clarify default behavior for 'path' (default is '') or the meaning of 'ref'. With low schema coverage, the description should compensate but does not add meaningful parameter semantics beyond what is already 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 action ('List files and folders') and the resource ('at a path in a repository'), and it enumerates the returned fields (name, type, size, sha). This distinguishes it from sibling tools like github_get_file (which retrieves file content) and github_list_commits (which lists commits). The purpose is unambiguous and specific.
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?
The description provides no guidance on when to use this tool versus alternatives. It does not mention any conditions for selection, exclusions, or prerequisites. The intended usage must be inferred from the tool's name and context, which is not explicit.
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, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds the requirement of both properties but does not disclose behavior for missing data, invalid dates, or how the merge handles pages present in only one source. Given strong annotations, the bar is lower, but the description adds only marginal 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 core purpose and then lists the metrics and requirement. It has no redundancy or filler, 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.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool merges two data sources and has 6 parameters, yet no output schema is provided. The description does not specify the output structure (beyond 'one table per landing page'), error handling, or parameter behaviors. Given the complexity and absence of an output schema, the description leaves critical details for correct invocation unexplained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% (siteUrl and propertyId have descriptions), so the description should compensate for the other four parameters (limit, sortBy, startDate, endDate). It does not explain their semantics or how they interact with the merged metrics. It only indirectly covers the two required parameters, leaving a significant gap for the rest.
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: to merge GA4 organic-search behavior with Search Console performance into one table per landing page. The verb 'combining' and specific resource ('landing page') make it distinct from sibling tools like gsc_search_analytics (Search Console only) and ga_run_report (GA4 only), which is a clear differentiation.
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 a prerequisite ('Requires both the GA4 property and the Search Console property of the same site') but does not explicitly state when to use this tool versus alternatives (e.g., running separate queries). It implies usage but lacks explicit contrast with siblings, so the guidance is only partially 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 and idempotentHint, lowering the bar. The description adds that it performs live requests with each bot's User-Agent, which is a behavioral trait not fully covered by annotations, and notes detection of UA-based blocks. This adds valuable context beyond the structured fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a dense two-sentence paragraph listing many crawlers and explaining consequences. While it is front-loaded with the main action, it is not concise and could be trimmed without losing key information. It is informative but not optimized for quick scanning.
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 there is no output schema, the description does not explain what the result looks like, but it clearly explains the method and the significance of blocked bots. Annotations cover safety, and the tool's purpose is well understood. It is fairly complete 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and both parameters (url and liveFetch) are already documented in the schema. The description does not add significant meaning beyond the schema, except noting the URL should be representative. Baseline 3 is appropriate when the schema handles the details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks whether AI and search crawlers can reach a page, and details the method (robots.txt rules and live UA requests). It is specific about the resource and lists many crawlers, but does not explicitly differentiate from the sibling robots_check tool, which likely performs a similar check.
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 the tool is for AI crawler access and mentions consequences of being blocked, but it does not explicitly state when to use this tool instead of alternatives like robots_check or ai_citation_check. There is no exclusion or comparison with siblings, leaving usage to inference.
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, and destructiveHint=false, covering safety and side-effect semantics. The description adds behavioral context beyond this: it states the output structure ('per-row current/previous/delta/percent change plus period totals') and the default breakdown by dimensions. This is valuable, though it does not mention edge cases like missing data or handling of zero denominators. Given the annotation coverage, this is a solid disclosure.
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 purpose and output characteristics, followed by a concrete usage example. There is no fluff, and every sentence contributes to the agent's understanding. It is efficiently structured and easy to parse.
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?
With 9 parameters, low schema coverage (22%), and no output schema, the description is incomplete. It does not explain how the four date parameters (currentStart, currentEnd, previousStart, previousEnd) define the two periods, nor does it describe the dimensionFilters object structure or allowed match types. The description leaves significant gaps that an agent must infer or discover by trial, which is risky for a tool with this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 22% (only propertyId and limit have descriptions). The description does not compensate for the other 7 parameters. It mentions the default dimensions but does not explain metrics, currentStart, previousStart, currentEnd, previousEnd, or dimensionFilters. Parameter names are somewhat self-explanatory (e.g., 'currentStart'), but the description adds minimal semantic value beyond the schema. For a low-coverage schema, the description should carry more explanatory weight; it does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear purpose: 'Compare GA4 metrics between a current and a previous period, broken down by dimensions'. The verb 'compare' and resource 'GA4 metrics' are specific, and the default dimension (channel group) is mentioned. While it doesn't explicitly contrast with sibling tools like ga_run_report or gsc_compare_periods, the 'GA4' qualifier and comparison focus make its intent distinct enough.
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 concrete use case: 'Use it for "how did organic traffic change vs last month"'. This gives the agent a clear scenario for invoking the tool. However, it does not mention when NOT to use it (e.g., for real-time data or complex custom reports), nor does it reference alternatives like ga_run_report for more flexible queries. It gives a useful but not exhaustive guideline.
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 annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds transparency by listing all the validations performed, giving the agent a clear picture of the tool's behavior. It does not contradict 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, dense sentence that efficiently lists all checks. It front-loads the purpose with a colon and enumerates the items. No wasted words, though it could benefit from bullet points for readability.
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?
This is a complex tool performing many validations, yet there is no output schema, and the description does not mention what the tool returns (report, pass/fail, list of issues). It also omits any constraints like authentication or limits beyond the schema's maxItems. An agent would not know what to expect as a result, making the definition incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% (only sitemapUrl has a description). The description indirectly explains the urls vs sitemapUrl inputs ('page' vs 'sitemap sample'), but leaves sampleSize entirely unaddressed. With low coverage, the description should compensate more, but it fails to explain the optional sampleSize parameter or how the two input modes interact.
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 specific verbs 'read' and 'verify' and enumerates the exact checks (reciprocal, self-referencing, valid codes, x-default, canonical consistency, html lang). This clearly distinguishes it from sibling tools like sitemap_check or robots_check, which focus on different aspects.
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 tool's purpose is clear from the name and description, so an agent can infer when to use it, but the description does not explicitly state when to prefer it over alternatives or mention any exclusions. It provides no comparison to sibling 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=false, covering the safety profile. The description adds value by enumerating exactly what data is extracted (word count, heading counts, content terms, etc.) and the content-gap hint, giving the agent a clear picture of the operation's scope without contradicting 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 compact, two sentences, with the core purpose front-loaded and details listed in a structured manner. No redundant filler, though the list of metrics is extensive, it is still 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?
For a tool with no output schema, the description lists the data points it returns but does not explain the output format or structure. It also omits clarification of the gapTerms parameter and does not mention that pages are fetched live, though openWorldHint implies external access. Given the complexity, the description is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It implicitly maps 'yourUrl' and 'competitorUrls' via the text, but the 'gapTerms' parameter is entirely undocumented in both the schema and the description. The agent cannot infer its purpose or constraints from the description 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 the tool's function: auditing multiple URLs side by side, listing specific metrics (word count, headings, links, schema types, etc.) and explicitly mentions comparing 'yours plus pages ranking above you'. This differentiates it from single-page audit tools like page_audit and structured_data_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 competitive analysis but does not explicitly state when to use this over alternatives, nor does it mention any exclusions or conditions. It provides context (comparing with competitor pages) but lacks explicit routing 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, idempotentHint, and destructiveHint false, which describe core behavior. The description adds context about a non-destructive side effect: providing steps to establish an entity if none exists. This is consistent with annotations and adds value beyond the metadata 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 concise with two sentences, clearly organized: first states the core function and data sources, then provides context about importance and a conditional behavior. It avoids fluff, though the mention of AI engines could be trimmed without loss, making it not perfectly 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 tool has 3 parameters, no output schema, and moderate annotations. The description covers the main purpose and one conditional result, but it does not explain the expected output format for the normal case or elaborate on the 'limit' and 'languages' parameters. For a relatively simple tool, this is adequate but has gaps in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only the 'name' parameter is described in the schema; 'limit' and 'languages' lack descriptions and are not mentioned in the tool description either. Schema description coverage is 33%, and the description does not compensate by explaining parameter usage, leaving most parameters under-specified.
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: 'Check whether a brand/business/place exists as an entity in Wikidata and in Google's Knowledge Graph Search API.' It also explains why this matters ('AI engines and Google rely on entities to know who a site is'), making the intent unambiguous. This distinguishes it from sibling tools like brand_mentions or reviews_snapshot.
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 provides implicit usage guidance by mentioning prerequisites (Wikidata free, Google requires API enablement and key) and a conditional result behavior ('if none exists, the result includes the steps to establish one'). However, it does not explicitly compare with alternatives or state when to use this tool over other knowledge-graph-related tools, leaving the context implied rather than direct.
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, and destructiveHint=false, covering the safety profile. The description adds value by disclosing an external API key requirement and describing the output behavior (link detection and AI context). No contradictions found.
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 with no filler. It leads with the core action, then explains the purpose and adds the key prerequisite, all in a tight structure. Every sentence contributes to understanding.
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 tool has 6 parameters, an external API dependency, and no output schema. The description gives a high-level output hint (list of mentions with link status and AI context) but omits details on response structure, pagination, error handling, rate limits, or behavior when the API key is invalid. For a tool with these complexities, more specifics would be needed for fully autonomous invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 17% (domain only). The description clarifies the roles of 'brand' and 'domain' implicitly ('brand name', 'your own domain') but provides no information about count, country, language, or checkLinks. With such low coverage, the description must compensate but does not, leaving several parameters ambiguous.
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 specific verbs and resources: 'Search the web for pages mentioning a brand name' and explicitly scopes to 'not on your own domain' while adding the link-checking purpose. It clearly distinguishes from siblings like keyword_suggest or ai_citation_check by focusing on unlinked mentions and outreach targets.
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 a use case ('outreach targets for links') and states a prerequisite (BRAVE_API_KEY), but it does not explicitly mention when to prefer this tool over alternatives or provide exclusions. The context is clear but not directive, so agents must infer applicability from the surrounding toolset.
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, idempotentHint, and destructiveHint false, covering safety. The description adds that it checks token obtainability, which is a behavioral trait, but it doesn't disclose response format or error behavior. With annotations covering the safety profile, the description adds modest value.
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. The first sentence states the primary function, and the second gives usage guidance. Information is front-loaded 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?
For a simple tool with one optional parameter and annotations covering safety, the description is mostly adequate: it explains purpose and when to use. However, the lack of any explanation for the 'verbose' parameter leaves a gap, and the return value is not described. It's a minimum viable description but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has a single optional boolean parameter 'verbose' with 0% description coverage. The description does not mention this parameter at all, so it fails to compensate for the schema gap. An agent has no guidance on what 'verbose' does or how to use it.
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 function: verifying which Google credentials are in use and whether an access token can be obtained. It uses a specific verb (verify) and resource (Google credentials) and distinguishes it from the many sibling audit and data tools by focusing on authentication status.
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 provides explicit guidance on when to use this tool: 'Run this first if other tools fail.' This establishes a clear condition for invocation and implies it serves as a diagnostic prerequisite, which is sufficient to differentiate it from alternatives.
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, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds that it returns 'last submitted/downloaded times, errors, warnings and URL counts', which gives some insight into the output but not into behavioral traits like rate limits, authentication requirements, or handling of missing properties. Since annotations carry the main behavioral burden, 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?
The description is a single, front-loaded sentence with no wasted words. It states the action, scope, and key output fields efficiently, making it 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?
For a simple list tool with one parameter and no output schema, the description covers the main aspects: it lists submitted sitemaps and includes the fields returned. It does not mention pagination or limits, but that is minor given the tool's simplicity. The schema provides the parameter details, and the description is sufficient for an agent to call the tool correctly.
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% for the single parameter siteUrl, and the schema already explains what it is and how to find it. The description text adds nothing about parameters beyond the schema. With full schema coverage, the baseline is 3, and the description does not enhance it.
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 ('List'), the resource ('sitemaps'), and the scope ('submitted for a property'), and it specifies the data returned (times, errors, warnings, URL counts). This distinguishes it from siblings like gsc_submit_sitemap (submit action) and sitemap_check (likely checks a specific sitemap), so an agent can identify the tool correctly.
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 does not explicitly mention when to use this tool versus alternatives. It is self-evident that you use it to list sitemaps, but it does not name alternatives or conditions for when not to use it. The schema parameter hints to use gsc_list_sites to find the property, but that is in the schema, not the description. There is no guidance on choosing between this and sitemap_check or gsc_submit_sitemap.
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 and idempotent behavior. The description adds useful transparency by mentioning that it optionally fetches each page to inspect headings and FAQPage schema, making the extra network-facing behavior clear. No destructive side effects are implied.
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 three sentences, front-loads the main purpose, and uses examples efficiently. The final sentence about AI Overviews and answer engines is somewhat repetitive given the title, but it does not add significant bloat.
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, optional behavior, and target use case, but because there is no output schema, it does not specify return fields or format beyond 'grouped by page'. It also does not mention limits or edge cases, though parameter descriptions cover date lag.
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 descriptions cover most parameters, including siteUrl, dates, and checkPages. However, top and minImpressions lack descriptions, and the description text does not clarify those two parameters. The parameter names are reasonably self-explanatory but not fully documented.
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 the verb 'Find' and the specific resource: question-style queries with impressions, grouped by page. It also gives the use context (AI Overviews and featured snippet targets) and includes concrete query examples, making its purpose distinct from general search analytics tools.
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 when to use the tool by mentioning AI Overviews and answer engines, and it notes optional page-level checking. However, it does not explicitly contrast with sibling tools like gsc_search_analytics or keyword_suggest, nor does it state when not to use this tool.
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, and destructiveHint=false, covering the key behavioral profile. The description adds the 'or resubmit' nuance, which aligns with idempotence, but it does not go further into side effects, permission requirements, or confirmation behavior. 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?
Description is a single, front-loaded sentence with no filler: it names the action immediately and the scope. Every word earns its place, and the optional '(or resubmit)' adds meaningful nuance without bloat.
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 two-parameter tool with complete schema coverage, helpful annotations, and no output schema, the description is almost sufficient. The only notable omission is a hint about what happens when the sitemap already exists or how to interpret a result, but '(or resubmit)' and idempotentHint already cover repetition safety. Overall adequate for correct invocation.
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% and both parameters already carry full descriptions with examples and hints (e.g., 'Use gsc_list_sites to discover it'). The description adds essentially no parameter-level meaning beyond what the schema already provides, so it meets the baseline for high-coverage schemas.
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 'Submit (or resubmit) a sitemap URL for a property' — a specific action (submit/resubmit) on a clear resource (sitemap URL) with explicit scope (for a property). This differentiates it naturally from sibling tools like gsc_list_sitemaps (list) and sitemap_check (check), so an agent can choose it without opening schemas.
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 when to use it (to submit or resubmit a sitemap), which is useful context. However, it provides no explicit alternatives or exclusion guidance, such as 'use gsc_list_sitemaps to see existing sitemaps first' or 'don't use if you only need to verify a sitemap'. This is a gap but not confusing.
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 enumerates the specific checks performed (existence, size, structure, robots access, link status), providing a clear picture of the tool's behavior. The readOnlyHint and destructiveHint annotations support that no mutations occur, and the description does not contradict them.
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 listing the checks in a logical order. It contains no redundant wording and directly conveys the tool's functionality.
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 lists the checks but does not explain the output format or how results are returned, which is relevant given the absence of an output schema. It also omits context for the checkLinks parameter and does not define what constitutes a valid structure (e.g., H1, blockquote) for llms.txt.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only the siteUrl parameter is documented in the schema, and the description does not elaborate on the checkLinks parameter, which controls the number of linked URLs to test. This leaves a required parameter for fine-tuning the check without any explanation.
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: to check the llms.txt file for existence, size, structure, robots access, and link status. It distinguishes itself from related tools like robots_check or page_audit by its specific focus on llms.txt.
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 verifying llms.txt files, but it does not explicitly state when to use this tool versus alternatives like llms_txt_generate or sitemap_check. Nor does it mention prerequisites such as having a valid site URL or handling of robots restrictions.
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 cover readOnly, openWorld, idempotent, and non-destructive behavior. The description adds that it fetches 'like a crawler' and that no authorization is needed, reinforcing the open-world and read-only traits. It doesn't mention rate limits or potential blocking, but the annotations lower the bar; the added context is useful.
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 long sentence that front-loads the action and then lists outputs in a clear sequence. It is efficient in packing a lot of information, though it is a run-on and could be broken into bullets. Still, it is concise relative to the breadth of 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?
The tool is complex with no output schema, but the description enumerates the major output categories comprehensively (redirects, status, metadata, headings, link counts, schema types, etc.). It also states the input (any URL) and the access requirement (none). The only gap is parameter details, but those are partially in the schema. For a crawler-like tool, this is quite complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% (only maxHeadings has a description). The tool description does not explain any parameter semantics, such as the effect of maxHeadings or maxImagesMissingAlt. With low schema coverage, the description should compensate, but it only lists outputs and ignores parameters entirely. An agent would need to rely on the schema alone, which is insufficient for maxImagesMissingAlt.
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 ('Fetch a page like a crawler and report') and the resource (a URL), and enumerates a comprehensive list of outputs (final URL, status, title, meta, robots, etc.). It distinguishes itself from siblings like robots_check or pagespeed by being a full on-page audit, so an agent can tell it apart without opening schemas.
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?
It states when to use it ('Works for any site, no authorization needed') and implies it is for a full audit, but it does not explicitly contrast with alternatives or give exclusions. For example, it doesn't say 'use robots_check if you only need robots'. The broad scope is implied, but not explicitly routed.
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=false. The description adds valuable operational context: it requires GOOGLE_PLACES_API_KEY with 'Places API (New)' enabled, billing must be enabled, and mentions the free monthly allowance. This goes beyond the annotations and helps the agent understand prerequisites.
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 with no wasted words. The action verb is front-loaded, and the operational requirements are stated clearly. 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 simple read-only tool with 3 parameters and no output schema, the description covers purpose, usage, prerequisites, and the data returned. It does not describe the exact response format, but given the annotations and the nature of the tool, this is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 67% (query and placeId have descriptions; language does not). The description adds no parameter-specific meaning, leaving the language parameter undocumented. With moderate coverage and no compensation in the description, it falls short of the baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Fetch') and resource ('Google Business Profile') with concrete data types (rating, review count, latest reviews). It does not explicitly distinguish from sibling tools, but the purpose is unique enough among the listed siblings (no other tool targets reviews).
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 use cases: 'source for AggregateRating schema and to monitor reputation.' It does not mention alternatives or when not to use it, but the stated uses give clear context for an agent deciding when to invoke 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 provide readOnly, idempotent, and non-destructive hints. The description adds value by explaining the underlying logic (weighted by impressions) and providing concrete CTR benchmarks by position, which goes beyond the annotations and helps interpret results.
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 with no filler. It leads with the core function and immediately provides actionable benchmarks, making it efficient and scannable.
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?
With 8 parameters and no output schema, the description should explain what the tool returns. It implies a list of queries/pages but does not detail output fields, sorting, or caveats like data lag (though the schema mentions lag). It is adequate for understanding the concept but incomplete for a fully self-sufficient call.
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 only 38%, so the description should compensate. It references 'top positions' (relating to maxPosition) and 'impressions' (relating to minImpressions) but does not explicitly define top, dimension, searchType, or other parameters. It adds some context but not enough to fully bridge the schema gap.
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 finds queries ranking in top positions with CTR far below the position benchmark, weighted by impressions, and explicitly names the use case (fastest wins from rewriting titles/meta descriptions). This distinguishes it from siblings like gsc_search_analytics or gsc_opportunities, which are broader.
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 when to use it (when seeking CTR improvements from titles/meta) but does not explicitly mention alternatives or conditions for choosing this over gsc_opportunities or gsc_search_analytics. The guidance is implicit rather than explicit.
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, and destructiveHint=false. The description adds behavior beyond that: it validates required/recommended properties, flags invalid JSON and dates, and checks entity consistency across pages. It also clarifies the sampling approach. No contradictions found.
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 front-loads the main action (extract JSON-LD and validate) and then details specific checks and input methods. It is information-dense without being redundant, though it lists many schema types which could be trimmed without losing core meaning.
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 the main functionality, input methods, and validation scope. It does not describe the output format (no output schema exists) or mention limits like maxItems, but those are in the input schema. Given the tool's complexity and the annotations covering safety, the description is reasonably complete for an agent to understand what the tool does and how to call it.
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 only 33% (only sitemapUrl has a description). The description explains that urls and sitemapUrl are alternative input methods ('Pass explicit urls or a sitemap'), which adds meaning to those parameters. However, sampleSize is not explicitly described, though 'sample' implies its purpose. The description partially compensates for the low coverage but could be more explicit about sampleSize and the relationship between urls and sitemapUrl.
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 JSON-LD from pages, validates properties per schema type, flags invalid JSON/dates, and checks entity consistency. It lists specific schema types and mentions input methods. This distinguishes it from siblings like schema_validate (likely single-schema validation) and eeat_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?
It explains how to invoke the tool ('Pass explicit urls or a sitemap to sample') but does not explicitly state when to choose this over alternative tools like schema_validate or site_crawl. The intended context is implied by the description but not spelled out with exclusions or comparisons.
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-destructive. The description adds behavioral context beyond these: it explains that the tool identifies overlapping queries, suggests links, and optionally fetches top candidate pages to check for existing cross-domain links. This clarifies the tool's analysis and network behavior, which is not covered by 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 concise sentences. The main purpose is front-loaded in the first sentence, and the optional behavior is added in the second. No filler or repetition, 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.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 7 parameters, low schema coverage, and no output schema, the description provides the core purpose and an optional behavior, which is adequate for a high-level understanding. However, it does not explain how optional parameters like top, minImpressions, or date ranges affect results, nor what the output format is. The annotations cover safety, but the description leaves gaps for an agent to correctly configure the call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 29% (only siteA and checkExistingLinks have descriptions). The tool description does not elaborate on any parameters, such as top, startDate, endDate, minImpressions, or the semantics of siteB. With low schema coverage, the description should compensate but does not, leaving agents without guidance on how to set these parameters or their impact.
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 a clear and specific purpose: for two owned Search Console properties on the same topic, it finds pages ranking for overlapping queries and suggests cross-links. The verb 'find' and 'suggest' with a concrete resource (two properties) makes the tool's function unambiguous, and it is distinct from any sibling tool like gsc_opportunities or content_refresh_candidates.
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 a clear usage context: 'for two Search Console properties you own on the same topic.' This tells the agent when the tool is applicable. It does not explicitly name alternatives or exclusions, but the condition 'you own' and 'same topic' is a sufficient usage guideline, especially given no sibling tool overlaps directly.
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, openWorldHint, and destructiveHint false, so the safety profile is clear. The description adds valuable context beyond annotations: API enablement requirement, key environment variables, and the 404 error behavior with a suggested workaround. This enriches 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first covers the core functionality and metrics, second covers prerequisites and error handling. Front-loaded with the most important info, no fluff. Minor density but well-structured.
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 should detail the return format. It mentions metrics and time period but not the response structure (e.g., JSON shape, per-week array). Also the '~25 weeks' vs schema 'weeks' default (12) creates ambiguity. These are notable gaps for a tool with 4 parameters and no output schema.
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 only 25% (only target has a description). The description clarifies scope (origin vs URL) but does not explain the 'weeks' parameter (says 'last ~25 weeks' while schema default is 12 and max 40) or 'formFactor'. It partially compensates for low schema coverage but leaves gaps for two key 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 states exactly what the tool returns: weekly p75 for LCP, INP, CLS, FCP, TTFB and the share of good/needs-improvement/poor for an origin or URL. This is specific and clearly distinguishes it from sibling tools like pagespeed (single snapshot) and geo_page_score.
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 provides practical guidance: mentions prerequisite (API enabled, key) and a fallback when 404 ('try the origin instead'). However, it does not explicitly compare to alternatives like pagespeed or other CrUX-related tools, so the agent must infer when to prefer this 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 indicate read-only and idempotent behavior. The description adds useful details about the return value ('matching files with fragments') and an important limitation (indexed for default branch only), going 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 two sentences, direct, and includes examples and a key limitation without unnecessary detail.
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 primary return value and the default branch limitation. Since there is no output schema, the return description is adequate; further detail about ordering or pagination would be helpful but is not essential for this simple 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?
Only 'repo' is described in the schema, and 'query' lacks a schema description. The description does provide query examples using GitHub code search syntax, which partially compensates, but 'limit' is left entirely to schema constraints and default 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 tool searches file contents in one repository and returns matching files with fragments, which distinguishes it from sibling tools like github_get_file or github_list_dir.
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 code search within a single repository and notes the default-branch-only limitation, but it does not explicitly contrast with alternatives such as github_get_file or github_list_dir.
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, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral detail beyond annotations by explaining that results list competing pages with clicks, impressions, and position. It does not mention data lag or limits like top/minImpressionsPerPage, but it does not contradict the annotations and provides meaningful return-behavior 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 one well-structured sentence that front-loads the core behavior and then expands on result contents and intended use. Every clause contributes meaning, with no filler, repetition, or unnecessary detail. It is compact and easy to parse.
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 explains the core concept and result structure, but without an output schema it should provide more guidance on limits, default thresholds, and parameter behavior—especially since several parameters lack schema descriptions. The tool is relatively specialized, so basic usage is clear, but an agent would still need to infer details about minImpressionsPerPage and top. This is adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 50%, and the description does not compensate by explaining key parameters such as top, minImpressionsPerPage, or searchType. It mentions queries, impressions, clicks, and position, but these are output concepts rather than parameter semantics. The description adds little beyond what the schema already provides for startDate, endDate, and siteUrl, leaving several parameters ambiguous.
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 opens with a specific verb and resource: 'Find queries for which two or more pages of the site receive impressions'. This clearly defines the tool's purpose and differentiates it from sibling tools like gsc_search_analytics or gsc_opportunities, which address different GSC reporting needs. It also explains the downstream action ('consolidate or differentiate'), giving the agent an unambiguous sense of what this tool is for.
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 clear context for when to use this tool: when pages are competing for the same keyword and you want to consolidate or differentiate them. It does not explicitly name alternatives or exclusion conditions, but the use case is stated well enough that an agent can match it to the user's intent. A fully explicit when-to-use versus alternatives statement would push this to 5.
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, openWorld, and non-destructive behavior. The description adds output behavior ('returns rows with deltas, sorted by biggest click change'), providing transparency without contradicting 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 a single, tightly worded sentence with no redundancy. It efficiently conveys the core function and output, making it easy for an agent to parse and act on.
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 10 parameters, the description plus parameter-specific notes (e.g., date formats, data lag) provide sufficient context. The lack of an output schema is acceptable, but the dimension mismatch between the description and schema slightly reduces 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 descriptions cover 70% of parameters with helpful notes like data lag and example values for siteUrl and expression. However, the description misleadingly limits dimension to 'query or page' while the schema permits country/device, and dimension/searchType lack descriptive text, reducing semantic clarity.
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 'Compare search performance between a current and a previous period' with a specific action and resource. It distinguishes from sibling tools by focusing on period-over-period deltas for a single dimension, making it uniquely identifiable among similar GSC tools.
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 when comparing two date ranges but does not explicitly mention alternatives or conditions. It lacks guidance on when to use this tool versus other GSC tools like gsc_search_analytics or gsc_opportunities, leaving the choice to the agent.
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-destructive, so the safety profile is covered. The description adds that it crawls up to maxPages, reads titles and meta descriptions, and produces a draft in a specific format. It also notes the draft must be reviewed before publishing, indicating it does not write directly. This adds meaningful 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 core action ('Crawl the sitemap') and efficiently packs in the output format and a safety instruction. 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?
Given the complexity and lack of output schema, the description explains the process, output format, and that the result is a draft to be reviewed before publishing. It does not explicitly state the return type, but 'produce a draft' implies the tool returns the draft. Overall, it covers the essential information for an agent to use it correctly.
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 descriptions cover 3 of 5 parameters (summary, siteName, excludePatterns). The description clarifies that maxPages limits the crawl ('up to maxPages') and implies siteUrl is the sitemap source, but it does not explicitly define siteUrl or maxPages beyond that. Since coverage is 60%, the description partially compensates but leaves siteUrl ambiguous.
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 a clear verb (crawl, read, produce) and resource (draft llms.txt) with specific format details. It distinguishes itself from siblings like llms_txt_check (which likely checks existing files) by focusing on generation. The process is unambiguous.
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 the tool is for generating a draft from a sitemap but does not explicitly state when to use it versus alternatives like llms_txt_check or site_crawl. It provides context ('Crawl the sitemap') but lacks explicit exclusions or alternative routing.
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, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context beyond annotations: it explicitly checks remote image reachability, file size, content type, and fallback behavior, indicating the tool performs network fetches and assesses resource metadata. This goes beyond the bare annotation data without contradicting it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the core action ('Validate how a page previews when shared') and then efficiently lists the specific checks. It is dense but not bloated; every listed item adds concrete information. It could be broken into two sentences for readability, but it earns a high score for no wasted words.
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 the tool's moderate complexity and lack of an output schema, the description is almost complete: it covers what is validated and the main checks. However, it does not describe the result format (e.g., pass/fail, list of issues, or a structured report), which an agent would need to know for downstream handling. With no output schema to fill this gap, the description leaves a meaningful ambiguity.
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 schema has a single 'url' parameter with no description (0% coverage), so the description must compensate. It effectively encodes the meaning of the parameter by stating the tool validates 'a page' that is to be shared, clearly implying the URL parameter is the target page. For a one-parameter tool, this is sufficient to make the parameter's role unambiguous.
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 a specific verb ('Validate') and resource ('how a page previews when shared') and enumerates concrete checks (OG tags, Twitter card, image reachability, dimensions, etc.). It is clearly distinct from sibling tools like page_audit or structured_data_audit because it focuses exclusively on social/messaging/link-card preview behavior, so an agent can select it unambiguously.
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 makes the use case implicit: 'when shared' and the list of social contexts imply the tool is for preview validation. However, it does not explicitly state when to use this tool versus alternatives (e.g., page_audit, structured_data_audit), nor does it mention exclusions or prerequisites. The usage context is clear enough but not explicitly contrasted with sibling 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, idempotentHint, and destructiveHint=false, so safety is covered. The description adds behavioral detail: it returns a pass/fail checklist with recommendations, and it checks a sample of articles for bylines and dates. This goes beyond the annotations and gives the agent a concrete sense of what will happen.
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 with a list of checks, which is efficient and front-loads the core purpose ('Site-level trust signals'). The list is dense but every item is relevant to E-E-A-T. No redundant 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?
The description explains the tool's scope, the checks performed, and the output (pass/fail checklist with what to add). It does not explicitly define the sampleArticles parameter's role, but given the simple schema and read-only nature, it is reasonably complete for an agent to invoke correctly.
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 description mentions 'a sample of articles' which implicitly relates to the sampleArticles parameter, but it does not explicitly state that sampleArticles controls the sample size or its constraints (default 5, max 20). Since schema coverage is 0%, the description could compensate more, but the intent is partially conveyed. siteUrl is self-evident.
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 audits site-level trust signals for search and AI engines, listing specific elements checked (About/Contact pages, schema, social profiles, etc.) and the return format (pass/fail checklist). This is a specific verb+resource with a distinct scope, easily differentiated from siblings like structured_data_audit which focus narrowly on schema 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 explicitly scopes to 'site-level' trust signals, which implies it is for whole-site audits rather than page-level analysis. It does not name alternatives or provide when-not-to-use guidance, but the context is clear enough to infer appropriate usage.
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 the tool read-only, idempotent, and non-destructive. The description adds behavioral context beyond that by specifying the response contains period-over-period comparisons and multiple breakdowns. It doesn't discuss pagination or rate limits, but these are not critical for a snapshot tool with read-only 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, information-dense sentence that front-loads the core purpose and lists all major output categories. It then adds a concise usage directive. No filler or redundancy—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?
With no output schema, the description does a good job enumerating the returned data types (totals, deltas, top queries, etc.). However, it omits parameter explanations for non-required fields, which are part of a complete contextual picture for a complex tool. Still, the output description is thorough for a snapshot tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25% (only siteUrl is described). The description does not explain `top`, `days`, or `searchType`. While these are somewhat inferable from their names, the low coverage means the description should have compensated. It doesn't, leaving agents to guess at valid ranges or semantics for non-required 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 states a clear, specific verb (answers 'how is the site doing') and lists the exact data included: totals with deltas, top queries/pages, device/country splits, winners/losers. It also explicitly positions itself as the first tool for overviews/reports, distinguishing it from the many specialized GSC siblings.
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 gives an explicit directive: 'Use this first when asked for an overview or a report.' This provides strong context for when to choose it over more granular tools like gsc_search_analytics or gsc_compare_periods. It doesn't name alternatives explicitly, but the phrase 'use this first' implies a starting point, which 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 already declare readOnlyHint=false, idempotentHint=true, destructiveHint=false, and openWorldHint=true. The description adds genuine value beyond annotations by disclosing that 'The tool verifies the key file before submitting', which is an important pre-condition behavior an agent needs to know. No contradiction with annotations; the description's write-implying language matches readOnlyHint=false.
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?
Three dense sentences, each earning its place: core action with limit, prerequisite with location detail, and the Google exclusion. The main action is front-loaded before prerequisites. Slightly packed but not verbose; appropriate length for the information conveyed.
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 the essentials for an open-world submission tool: what it does, the 1000-URL cap, supported engines, the key-file prerequisite, verification behavior, and the Google exclusion. Missing return-value/response details (no output schema exists), so an agent doesn't know what success or failure looks like. Given moderate complexity (3 params, no nested objects), this is a minor but real gap.
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 67%, so the schema already documents key ('Overrides INDEXNOW_KEY') and keyLocation ('Overrides INDEXNOW_KEY_LOCATION') with descriptions. The description adds context about what INDEXNOW_KEY is and how the key file must be published, which enriches the key/keyLocation semantics. However, the urls parameter gets no extra explanation beyond the schema's uri format, and the description doesn't fully compensate for the 33% coverage gap.
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 a specific verb+resource ('Submit up to 1000 changed URLs to IndexNow') with clear scope, and names the target search engines explicitly (Bing, Yandex, Naver, Seznam). The title 'IndexNow: notify Bing/Yandex of changed URLs' aligns with the description, and no sibling tool performs this exact function (gsc_submit_sitemap is Google-specific), so differentiation is not needed.
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 the prerequisite: 'Requires INDEXNOW_KEY and the key file published at https://<host>/<key>.txt (or set INDEXNOW_KEY_LOCATION)'. Gives a clear when-not signal: 'Google does not support IndexNow', implying the agent should use Google's own tooling for Google URLs. Does not name an explicit alternative sibling tool, but the exclusion is informative enough.
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, idempotent, and non-destructive behavior. The description adds operational details beyond annotations: respects robots.txt for Googlebot, same-host constraint, breadth-first strategy, and a time estimate. It does not contradict annotations and provides useful context on how the crawl behaves.
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 moderately long but each sentence adds value. It front-loads the core purpose, then lists the detailed outputs and ends with a practical usage hint. It avoids fluff and is well-structured, though slightly verbose in the output enumeration.
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 crawl tool with no output schema, the description covers the key aspects: what it returns (list of metrics), how to bound it, performance expectations, and constraints (same host, robots.txt). It does not mention authentication requirements or exact response format, but these are minor given the comprehensive summary provided.
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 50%, so the description should compensate. It does explain maxPages (bounding) and startUrl (implicitly), but concurrency is left unexplained. The description adds a performance note tied to maxPages but does not fully elaborate on all parameters. This is adequate but not exhaustive.
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 a specific verb ('crawl') and resource ('from a start URL'), and clarifies it audits each HTML page like page_audit. It lists the detailed site-level summary outputs, making its purpose unambiguous and distinguishing it from single-page tools like page_audit or specific checks like robots_check.
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 it (site-wide audit vs. single page via 'like page_audit') and gives practical guidance on bounding with maxPages and performance expectations. However, it does not explicitly mention alternatives or when not to use it, such as when a sitemap check or robots check would be 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 already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds meaningful context: the need for PERPLEXITY_API_KEY (auth) and cost (cents per call). It 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?
Three sentences: purpose, use case, and requirements. No fluff, information is front-loaded. Every sentence contributes.
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 output content (sources cited, domain presence, answer text) and the API key requirement. For a read-only tool with no output schema, this is sufficient. Minor gaps like error handling or rate limits are 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 75% (domain and question have descriptions; model and country do not). The description implicitly clarifies the question and domain parameters but adds no detail about model or country. It provides marginal value 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 states a specific verb ('Ask Perplexity's Sonar API') and a clear outcome (report citations, domain presence, answer text). It is distinct from all sibling tools, which focus on other aspects like robots, sitemaps, or Google data. No other tool addresses AI citation checking.
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 provides a clear use case ('see if the site is being cited by AI search for target queries') and prerequisites (API key, paid). It does not explicitly name alternative tools for when not to use it, but the uniqueness of the function makes the context 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 already declare readOnlyHint and idempotentHint, so safety is covered. The description adds behavioral details: it compares two periods, uses sitemap lastmod for staleness, and returns top losing queries. It does not describe output format or pagination, but these are minor given the read-only nature.
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 tightly written sentences with zero filler. The primary purpose is front-loaded, and the actionable context follows naturally. 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?
For an analysis tool with 9 parameters and no output schema, the description covers the selection logic well but omits details about the return format (e.g., whether it returns a list with metrics, sorting, or pagination). Still, given the read-only nature and clear purpose, an agent can reasonably infer expected output. The description is sufficient for most use cases.
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 only 33%, so the description should compensate for the undocumented parameters. It references 'two periods' and 'sitemap lastmod', which loosely maps to the date-range and sitemap parameters, but it does not explain top, minPreviousClicks, or the default periods. The description adds some meaning but not enough for a tool with 9 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 uses a specific verb ('Find') and clearly specifies the resource ('pages') with precise criteria (clicks/impressions dropped, not updated recently). It distinguishes itself from sibling GSC analysis tools by focusing on content refresh candidates rather than generic opportunities or CTR reports.
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 it ('best candidates for a content refresh') and even suggests follow-up actions, providing clear context. However, it does not explicitly name alternative tools or state when not to use it, leaving some inference to the agent.
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=false, covering safety and side effects. The description adds the behavior that it includes custom dimensions/metrics and that the output can be large without a search filter, which are useful non-obvious details. 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 two short sentences with no filler. It front-loads the core action and then provides a practical filtering tip. 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?
For a metadata listing tool with a required propertyId and optional kind/search, the description covers the essential purpose and filtering behavior. It does not detail the return structure, but the absence of an output schema and the simplicity of the tool make that less critical. Annotations cover the safety profile, so nothing critical is missing.
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 67% (propertyId and search have descriptions; kind does not). The description reinforces the search parameter's purpose and implies kind through 'dimensions and metrics', but it does not add substantial semantics beyond what the schema already provides. Baseline of 3 is appropriate given high schema 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 verb ('List') and the resource ('dimensions and metrics available for a GA4 property'), and adds specificity with 'including custom ones'. It is distinct from siblings like ga_list_properties (which lists properties) and ga_run_report (which runs reports), so an agent can immediately tell what this tool does.
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 context (listing available dimensions/metrics for a property) and even hints at usage by advising to filter with a search string to keep output small. However, it does not explicitly mention when to prefer this over alternatives, nor does it state exclusions. The context is sufficient for most agents to select it appropriately.
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, and destructiveHint=false, so the description doesn't need to repeat those. It adds valuable context by noting the prerequisite that the Analytics Admin API must be enabled and that the listing is scoped to the authorized account, which goes 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: the first states the core action and resource, the second adds a necessary prerequisite. No filler or redundancy; 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?
For a simple list tool with no parameters and safety annotations, the description is sufficiently complete. It specifies what is listed and the API requirement. It doesn't mention output format or pagination, but these are minor for a tool of this 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?
There are zero parameters, so the schema has full coverage and no parameter documentation is needed. The baseline for 0 params is 4, and the description doesn't need to add anything about parameters since none exist.
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 a specific verb ('List'), a precise resource ('Google Analytics accounts and GA4 properties'), and the scope ('the authorized account can access'). It is unambiguous and clearly differentiates from sibling tools like ga_run_report, which run reports rather than list resources.
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 use for discovery of accessible accounts/properties, but it does not explicitly contrast it with alternatives or state when not to use it. The context is clear enough for an agent to infer the purpose, but no explicit routing guidance is given.
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, and destructiveHint=false, covering safety. The description adds the time window (last 30 minutes) and lists available dimensions/metrics, which is useful behavioral context beyond annotations. It does not disclose potential limitations like data availability or latency, but given the annotation coverage, this is sufficient.
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, dense sentence that front-loads the core purpose (real-time GA4 data) and then lists supported dimensions and metrics. Every word adds value, with no fluff or repetition. It is optimally 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?
For a simple read-only tool, the description covers the essential aspects: data freshness (last 30 minutes) and valid dimensions/metrics. It does not mention pagination or limit behavior, but the schema provides defaults and bounds. There is no output schema, but the description implies the nature of the returned data. Overall, it is complete enough for an agent to call 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?
Schema description coverage is only 25% (propertyId has a description). The description compensates by listing valid dimension and metric names, which directly informs the 'dimensions' and 'metrics' array parameters. This adds meaning beyond the schema, though it does not explain the format of arrays or default behaviors (covered by defaults in schema). The propertyId hint in the schema is also helpful.
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 real-time GA4 data for the last 30 minutes, listing specific dimensions and metrics. This distinguishes it from sibling tools like ga_run_report (which likely handles historical data) and ga_compare_periods. The verb 'Real-time' and resource 'GA4 data' are explicit 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for real-time data by stating 'last 30 minutes', but does not explicitly say when to use this tool versus alternatives such as ga_run_report. There is no direct statement of 'use this for immediate data' or 'use ga_run_report for historical data'. The real-time scope is a clear hint, but explicit guidance is missing.
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 destructiveHint=true and readOnlyHint=false, and the description reinforces this by mentioning 'adds/updates/deletes' and 'atomically'. It adds useful context about the branch update triggering CI/CD and the requirement to provide full file content. 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 concise, front-loaded with the core action and purpose, then provides practical usage instructions in a few sentences. Every sentence adds value without 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?
The description is complete for a mutation tool: it covers the workflow (read, modify, commit), mentions atomicity, CI/CD implications, and branching options. It lacks explicit error handling or return format details, but since there is no output schema and annotations provide safety hints, this 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 80%, so most parameters are described in the schema. The description adds extra meaning by explaining the content parameter should hold full new file content and that createBranch creates from the default branch. However, it doesn't add much beyond what the schema already covers, 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 a specific action: creating one commit that adds/updates/deletes files atomically via the Git Data API, with the downstream effect on CI/CD deployment. It distinguishes itself from sibling tools like github_get_file (read) and github_list_commits (list) by naming the commit creation and file changes.
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 explicit workflow guidance: read files first with github_get_file, send full new content, and use createBranch for new branches. It implies when to use this tool (for commit changes) versus when to use the read tool, though it doesn't explicitly state 'do not use this for reading' – but the guidance is clear enough.
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=false. The description adds valuable operational context beyond annotations: it notes the cost of one inspection call per URL against the ~2000/day quota and advises keeping batches small. 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 two sentences: the first front-loads the purpose and output fields, the second adds a crucial cost warning. No redundant words or padding.
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 complexity (6 parameters, no output schema), the description covers purpose, input modes (list or sitemap), output fields summarized, and cost. It sufficiently prepares an agent to decide when to use it and what to expect, though it could elaborate on exact response formatting.
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 83% (5 of 6 parameters have descriptions). The description mentions the urls/sitemap usage patterns and the limit concept, but does not add new semantics beyond the schema. Since schema coverage is high, 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 runs the URL Inspection API over a batch of URLs or a sitemap and summarizes index status with specific fields (indexed, coverage state, robots state, last crawl, canonical mismatch). This is a specific verb+resource and distinguishes it from single-URL inspection tools like 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?
The description provides clear context for batch usage (list of URLs or sitemap) and includes a cost warning to keep batches small. It does not explicitly name alternative tools or state when not to use it, but the batch nature and cost guidance make usage conditions 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 establish readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is known. The description adds valuable behavioral details: it groups results by page and optionally maps to WordPress post IDs when a WordPress site is configured. This goes beyond the annotations and clarifies the output organization without contradicting them.
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 with no redundancy. It front-loads the core purpose and adds the WordPress mapping detail efficiently. Every phrase 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 9 parameters and no output schema, the description provides the essential context: the target range, the quick-win concept, and the WordPress integration. Parameters like siteUrl and date formats are covered in the schema, and the tool's read-only nature is handled by annotations. The only minor gap is the lack of explanation about the output structure, but since there is no output schema and the use case is clear, it is 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 description coverage is only 44%, so the description should compensate. It does explain the default position range (8-20) and the overall intent, but it does not elaborate on parameters like top, minImpressions, or minPosition/maxPosition beyond their names. The names are self-explanatory, but the description could have clarified relationships (e.g., how minImpressions affects results). It adds some value but does not fully compensate for the coverage gap.
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 a specific verb ('Find'), resource ('queries with high impressions but average position in a range'), and the qualifying condition ('pages already ranking on page 1-2 that can be pushed into the top results'). This clearly distinguishes it from siblings like gsc_ctr_opportunities (focused on CTR) and keyword_suggest (keyword generation). The purpose is 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 clearly conveys when to use this tool: when seeking quick wins by improving pages in positions 8-20. It gives concrete context (title/content/internal-link work) but does not explicitly name alternative tools or exclusion criteria. Still, the usage scenario is obvious and distinct enough from the listed 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 cover readOnly, idempotent, and non-destructive behavior, so the description does not need to repeat those. It adds valuable behavioral detail: the tool fetches robots.txt, shows groups and sitemap lines, and applies Google's longest-match rules for crawlability testing. This goes beyond the annotations and clarifies the operation's logic.
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 primary action and includes all essential elements without fluff. Every phrase adds value: fetching, showing groups/sitemaps, testing with a user agent, and the rule engine. It is concise and 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 read-only tool with two simple parameters and no output schema, the description is sufficiently complete. It explains the tool's core outputs (groups, sitemap lines, crawlability results) and the key behavioral rule. It does not detail edge cases or error handling, but those are not critical for a tool of this complexity given the 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 50%; the schema already explains that robots.txt is fetched from the first URL's origin and that userAgent has a default. The description reinforces the purpose of URLs (test crawlability) and mentions the default Googlebot, but adds little beyond what the schema states. The mention of 'Google's longest-match rules' adds context for the userAgent, but it is not directly tied to a specific parameter's 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 states a specific verb (fetch, show, test) and a clear resource (robots.txt) with a well-defined scope: fetching, displaying groups/sitemap lines, and testing crawlability. It clearly distinguishes from siblings like sitemap_check and ai_crawler_access by focusing on robots.txt rules and Googlebot behavior.
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 the tool: to inspect robots.txt and test URL crawlability for a specific user agent. It mentions the default Googlebot and Google's longest-match rules, which implies typical usage. However, it does not explicitly state when not to use it or mention alternatives, so it stops short of an explicit when/when-not.
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, so the safety profile is covered. The description adds meaningful behavioral context: it produces a draft (not a final publication), trims answers to ~600 characters, and suggests a follow-up publishing step. It does not contradict any annotation and enriches the behavioral picture with concrete constraints.
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 with zero fluff. It front-loads the primary action, then breaks down each mode with a semicolon-separated list, and ends with the practical workflow note. Every sentence earns its place; the structure is scannable and 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 has 4 parameters, one enum, and no output schema, the description covers the essential behaviors: the output kinds, the trimming behavior, and the follow-up publishing step. It does not explicitly describe the exact JSON-LD structure returned, but that is implied by the purpose and the annotations cover read-only/idempotent behavior. The only minor gap is the lack of explicit mention of 'maxQuestions' behavior, but that is a schema-level detail. Overall it is complete enough for an agent to call correctly.
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 only 25% (only organizationName has a schema description). The description compensates by explaining the 'kind' enum values in detail (faq, article, breadcrumb, all), but it does not clarify 'maxQuestions' beyond its schema metadata (default 10, max 30) nor the 'url' parameter, which is self-explanatory. It adds partial meaning for one parameter but leaves 'maxQuestions' under-documented, so it only partially compensates for the low schema 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 states a specific verb (generate), a specific resource (draft JSON-LD from an existing page), and enumerates the four output kinds (faq, article, breadcrumb, all). It clearly distinguishes itself from sibling tools like schema_validate (which validates) and structured_data_audit (which audits) by framing itself as a generation tool. No ambiguity remains about what the tool produces.
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 context for when to use it: to produce draft structured data before publishing, and it names the follow-up action (publish with wp_set_schema). However, it does not explicitly state when not to use it or compare itself to alternatives like schema_validate, leaving some inference required. It implies usage through workflow rather than explicit exclusions.
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 cover safety (readOnly, openWorld, idempotent, non-destructive). The description adds behavioral detail beyond annotations: it performs specific validation checks and returns normalized, compact JSON ready to inject. This is meaningful extra context about the tool's behavior and output format, though it does not describe error handling or response details on failure.
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 with no fluff. It front-loads the core purpose and immediately lists concrete validation criteria, then states the return format. Every sentence earns its place, and the structure is highly scannable for an agent.
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 single-parameter validation tool, the description covers what is validated, the input format (via schema), and the output (normalized JSON). It omits details like error messages or behavior on invalid input, but these are not critical for correct invocation. The tool is simple enough that the description is nearly 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 description coverage is 100% for the single parameter 'jsonld', which already explains it accepts an object, array, or JSON string. The tool description does not add further parameter-specific semantics beyond what the schema provides. Per the baseline rule for high coverage, a 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 validates JSON-LD objects and enumerates specific checks (required/recommended properties, FAQ/Breadcrumb structure, ISO dates, @context presence). It distinguishes itself from siblings like structured_data_audit by noting it uses the same rules but is for validation before publishing, and from schema_generate by focusing on validation rather than generation.
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 says 'before publishing', providing a clear usage context. It references 'same rules as structured_data_audit', which hints at an alternative tool but does not explicitly say when to use this instead. It also mentions returning normalized JSON ready to inject, implying the output is intended for publishing workflows. This is clear context but lacks explicit exclusions or alternative conditions.
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, covering the safety profile. The description adds valuable behavioral details such as sitemap index support, .gz handling, sampling vs. all URLs, a 500 cap for checkAll, and even sampling logic, which go 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 three concise sentences with the primary action front-loaded. It covers the core functionality, format support, and auto-discovery without any redundant or vague phrasing.
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 moderate complexity and the lack of an output schema, the description explains the main actions and expected results (identifying 404s, redirects, errors) but does not detail the response structure or error handling. While sufficient for an agent to call correctly, a bit more detail on output would make it fully 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 description coverage is 80%, so the schema already documents most parameters (url, checkAll, listUrls, sampleSize). The description adds minimal parameter-specific meaning—it mentions auto-discovery for url and sampling for sampleSize, but these are already in the schema. Concurrency lacks a description in the schema and the description does not compensate for that gap.
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 sitemap, lists URLs, and checks HTTP status to identify 404s, redirects, and server errors. It also mentions auto-discovery from robots.txt or /sitemap.xml, making the purpose specific and distinct from sibling tools like site_crawl or robots_check.
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 on what the tool does and how to use it, including the option to pass a site root for auto-discovery. It does not explicitly name alternative tools or exclusion conditions, but the usage is straightforward and unlikely to be confused with 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 cover readOnly and idempotent behavior. The description adds a practical quota ('~2000 calls/day per property'), which is useful behavioral information beyond the annotations. It does not mention failure modes, but the annotations sufficiently convey safety.
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, information-dense sentence that lists the tool's purpose and outputs, immediately followed by the quota note. No fluff or redundant wording.
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 read-only inspection tool with no output schema, the description sufficiently enumerates the key result categories and parameter constraints. It is complete enough for an agent to invoke correctly without additional 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 description coverage is 100%, and the description enriches key parameters: siteUrl includes property format examples and a pointer to gsc_list_sites, while inspectionUrl clarifies ownership. LanguageCode is straightforward. This goes beyond the schema's 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?
States a specific verb ('Run the URL Inspection API') and a clear resource (a page URL). Lists concrete outputs (index status, last crawl time, canonical selection, etc.) and distinguishes itself from broader GSC tools like gsc_index_coverage or page_audit by focusing on single-URL inspection.
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?
Clearly implies when to use it—when you need inspection details for one specific URL—but does not explicitly contrast with sibling tools or state when not to use it. The purpose is evident, but no direct alternative guidance is provided.
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 goes beyond the readOnly/idempotent annotations by disclosing latency, caching behavior, retry expectations, and a specific failure mode. This accurately sets agent expectations without contradicting the supplied 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?
Every sentence adds useful information: output contents, quota, runtime, caching/retry, and error diagnosis. There is no filler, repetition, or unnecessary detail, making it compact yet dense with relevant guidance.
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 thoroughly covers outputs, latency, retries, and error semantics, which is valuable given there is no output schema. It falls slightly short by not explaining how the strategy and categories parameters alter the returned result set or that defaults are not the full category list.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The url parameter is implied and categories/top opportunities are loosely referenced, but strategy is never explained and the categories defaults/limiting behavior are not described. With 0% schema description coverage, the description does not carry enough parameter-level 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 opens with a specific verb and resource: 'Run Google PageSpeed Insights for a URL', then lists the concrete output types. This makes the tool's purpose and scope immediately clear and distinct from sibling 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?
It gives practical operational guidance: set PAGESPEED_API_KEY for a higher quota, expect 15–60 second runs, retry on timeout, and interpret repeated Lighthouse errors as an idle-page issue. Alternative-selection guidance is not explicit, but the usage context is strong.
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, so the safety profile is covered. The description adds return format (0-100 score, signals found, concrete fixes) and the evaluation dimensions, which is valuable context beyond the 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?
Two sentences with zero fluff. The purpose is front-loaded, and the criteria list is dense but relevant. Every word contributes to understanding what the tool evaluates and returns.
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 single-parameter scoring tool with no output schema, the description covers what it does, what it evaluates, and what it returns. It lacks any prerequisites or limitations (e.g., page must be public), but given the read-only, idempotent nature, these are not critical. Overall, sufficient for correct invocation.
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 0% schema description coverage, the description must define the sole parameter (url). It implies the URL via 'a page' and the tool name, but does not explicitly state that the url parameter is the page to score. This is a minor gap, but the implicit definition is clear enough for an agent.
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 a specific verb ('Score') and resource ('how easily AI answer engines can extract and cite a page'), and enumerates concrete criteria (direct answer, FAQ schema, etc.), making its purpose unmistakable and distinct from siblings like page_audit or structured_data_audit.
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 its use case—evaluating GEO readiness for AI engines—but does not explicitly mention when to prefer it over alternatives like eeat_audit or ai_crawler_access. Clear context is present, though exclusions are absent.
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, and destructiveHint=false, covering the safety profile. The description adds behavioral context by explaining that it supports grouping, filtering (with an example), and pagination, which goes beyond the annotations. It does not cover rate limits or auth, but the annotations suffice for safety, and the description adds operational details.
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 primary action and metrics. It includes an example for filtering and mentions pagination, all in a compact format. Every sentence contributes useful information without 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 complexity (10 parameters, no output schema), the description covers the core use case well: it states the metrics returned, the grouping options, filtering, and pagination. It does not explicitly mention data lag (though that is in the parameter descriptions) or the need to use gsc_list_sites for siteUrl, but these are covered by the schema. Overall, it is fairly complete for an agent to understand the tool's purpose and basic 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 description coverage is 70%, so the schema already documents most parameters. The description adds value by summarizing the grouping dimensions and providing a filtering example (page contains '/blog/'), which helps agents understand how to use the dimensions and filters parameters. It does not repeat schema details but enriches the conceptual model.
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 queries Google Search performance data with specific metrics (clicks, impressions, CTR, average position) and lists the grouping dimensions (query, page, country, device, date, searchAppearance). It also mentions filtering and pagination, which distinguishes it from sibling tools like gsc_compare_periods or gsc_opportunities by focusing on raw data retrieval.
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 context on what the tool does (query performance data) and its capabilities (filtering, pagination), which implies when to use it. However, it does not explicitly state when not to use it or mention alternatives such as gsc_opportunities or gsc_ctr_opportunities, so there is no explicit exclusion 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?
The description adds behavioral context beyond the annotations: it notes the tool is free and requires no key, deduplicates suggestions, and groups them by prefix. It also implies multiple requests via a-z expansion. Annotations already declare readOnlyHint and idempotentHint, and the description does not contradict them. It could mention rate limits or external dependency, but the added value is solid.
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 scope. It packs essential parameter guidance and output characteristics without fluff. Every clause earns its place, making it efficient for an agent to parse quickly.
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 6-parameter tool with no output schema, the description covers the main purpose, key parameters, and high-level output format. It doesn't detail rate limits or the exact response structure, but the description's summary of deduplicated grouped suggestions is sufficient for an agent to understand expected results. The annotations cover safety and idempotency, so overall it is reasonably complete.
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 schema coverage at 67%, the description compensates by explaining the seed expansion modes (question prefixes, a-z suffix) and providing concrete examples for hl and gl parameters. It does not elaborate on extraPrefixes, but the schema describes it. The description adds meaningful semantics beyond the schema's basic type 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's function: expanding a seed keyword via Google Autocomplete, with specific modes (question prefixes, a-z suffix expansion) and output (deduplicated suggestions grouped by prefix). It is specific about the resource and action, and easily distinguished from sibling tools which are mostly audit, crawl, or analytics 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 clear context for using the tool, including language and country parameter guidance with examples, and mentions its utility for long-tail and FAQ ideas. However, it does not explicitly name alternatives or state when not to use this tool compared to other sibling tools, though its distinct purpose makes this less critical.
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, but the description adds concrete behavioral details: returns content, sha, size, and latest commit, plus the 1 MB refusal. This goes beyond the annotations without contradicting them.
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, direct, and informational. Every clause serves a purpose—stating the action, return values, and a constraint with an alternative. No redundant wording.
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?
With no output schema, the description compensates by listing return fields. It also addresses edge cases (file size) and names the fallback tool. For a simple read operation, this provides complete context 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers repo and ref with descriptions, but path lacks a schema description. The tool description implies path is a file path, but this is not fully explicit. Schema coverage is 67%, and the description adds only partial clarification, so a baseline score 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 ('Read a file (text) from a repository branch') and the resource (a file in a GitHub repo). It distinguishes itself from sibling tools like github_list_dir by focusing on file content retrieval.
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?
Provides explicit guidance on when not to use it ('Files over 1 MB are refused') and names the alternative tool (github_list_dir) for browsing. This makes the decision context clear without requiring inference.
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 annotations already signal read-only, non-destructive, and idempotent behavior. The description adds rich detail beyond that: it explains the source collection, URL rewriting, redirect following, and the exact classification categories (OK, REDIRECTED, REDIRECT_TO_HOME, CHAIN, NOT_FOUND, ERROR) plus sorting by old-site clicks. This substantially clarifies runtime behavior without contradicting 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 a single, well-organized paragraph that front-loads the purpose, then explains the process and classification in a logical order. Every sentence contributes to understanding, with no filler or 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 there is no output schema, the description adequately explains the return format by enumerating the classification values and the sorting logic. It covers input sources, process, and output expectations. For a read-only, non-destructive tool with these annotations, nothing critical is missing.
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 50% (4 of 8 parameters have descriptions). The tool description indirectly references several parameters (period via 'pages with impressions in the period', old sitemap, new host) but does not explicitly explain the undocumented ones like concurrency or maxUrls. It adds some context beyond the schema but does not fully compensate for the missing parameter descriptions, warranting a middle score.
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 opens with a precise statement of what the tool does: verify that every URL on the old site still works on the new one before migration. It names the specific resources (Search Console, sitemap) and the classification outcomes, making its purpose unambiguous and clearly distinct from siblings like sitemap_check or robots_check.
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 provides a clear usage context: 'Before pointing a domain at a new (static) site.' This tells an agent exactly when to invoke it. However, it does not explicitly mention alternatives or when not to use it, so it stops short of a 5.
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=true and destructiveHint=false, so the tool is safe to call. The description adds 'authorized account' indicating an authentication requirement, and no side effects are implied. This is fully consistent with the annotations and provides 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 a single, concise sentence with no redundant phrasing. It directly states the action, target, and scope, which is optimal for this simple tool.
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?
The description fully explains the tool's function and what the output will be (list of properties with permission levels). There is no output schema, but the description provides sufficient information for an agent to understand the result.
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 tool has zero parameters, so the schema coverage is complete by definition. There is nothing further for the description to explain about inputs, and no ambiguity exists.
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 'List', the resource 'Search Console properties (sites)', and the scope 'authorized account can access' with 'permission level'. This distinguishes it from sibling tools like gsc_search_analytics or gsc_list_sitemaps, making the 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 implicitly indicates its use case (enumerating accessible properties) but does not explicitly name alternative tools or conditions for selection. It is clear enough for an agent to infer when to use it, but lacks the explicit contrast seen in the best examples.
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

google-seo-mcp MCP server – quality and maintenance score on Glama

Copy to your README.md:

[![google-seo-mcp MCP server – quality and maintenance score on Glama](https://glama.ai/mcp/servers/Akxan/google-seo-mcp/badges/card.svg)](https://glama.ai/mcp/servers/Akxan/google-seo-mcp)

Score Badge

Copy to your README.md:

[![google-seo-mcp MCP server – quality and maintenance score on Glama](https://glama.ai/mcp/servers/Akxan/google-seo-mcp/badges/score.svg)](https://glama.ai/mcp/servers/Akxan/google-seo-mcp)

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/Akxan/google-seo-mcp'

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