gsc-mcp

Server Quality Checklist

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

Latest release: v0.6.2
Disambiguation4/5
Most tools have clearly distinct purposes with detailed descriptions, though some overlap exists between search analytics tools (e.g., get_search_analytics vs get_advanced_search_analytics vs compare_search_periods) but descriptions clarify differences.
Naming Consistency3/5
Naming is inconsistent: some use verb_noun (inspect_url, submit_sitemap), others noun_verb (traffic_drops, content_brief), and some have prefixes (ga4_, seo_). While still readable, the mix of conventions makes patterns harder to predict.
Tool Count2/5
With 43 tools, the server is over-scoped for a typical MCP server. Many are highly specific (e.g., discover_performance, news_performance) and could be consolidated, making the surface feel heavy and harder for agents to navigate.
Completeness4/5
The tool set covers a wide range of SEO and analytics tasks (GSC, GA4, CrUX, sitemaps, indexing, SEO analysis) with good depth. Minor gaps exist (e.g., no bulk removal from index, no GA4 account management) but core workflows are well-supported.
Average 3.8/5 across 43 of 43 tools scored. Lowest: 3.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 91 commits in the last 12 weeks
- Last stable release on June 25, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description only discloses that already-submitted sitemaps are updated. No mention of permissions, rate limits, or side effects, leaving significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the primary action. No redundancy.
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?
Despite having an output schema and low complexity, the description omits parameter formats, prerequisites, and error conditions, making it insufficient for practical agent use.
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?
Schema coverage is 0% and the description does not clarify the 'site' or 'sitemap_url' parameters beyond their names. No hints about format (e.g., 'sc-domain:example.com' for site).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('submit') and resource ('sitemap URL') and target ('GSC property'), and distinguishes from siblings like 'submit_url' and 'sitemaps_delete' by specifying the scope.
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 (submitting new sitemaps) and mentions update behavior, but lacks explicit guidance on when not to use or alternatives like 'submit_url'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool returns aggregate totals and top 10 queries, but does not mention read-only nature, potential rate limits, or any side effects. The behavioral details are minimal.
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 main purpose and key outputs. Every sentence is meaningful with no wasted words, achieving high efficiency.
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 only 2 parameters and an output schema, the description provides the core purpose and key behavioral detail (top 10 queries). It is almost complete, though could mention aggregation over time or site scope more explicitly.
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 0%, so the description must explain parameters. It mentions 'for a site' and 'over the rolling window', which loosely map to 'site' and 'days', but doesn't clarify the 'days' format, default, or what 'rolling window' means. It adds some value but lacks detail.
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 summarizes total clicks, impressions, average CTR, and average position, and returns aggregate totals plus top 10 queries. This provides a specific verb and resource, but doesn't explicitly distinguish from siblings like 'get_search_analytics' which may offer similar metrics.
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 implies usage for a site's performance overview over a rolling window, but provides no guidance on when to use this tool versus alternatives or when not to use it. No explicit context or exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully convey behavior. It states the tool lists all sitemaps with their dates, status, and errors, implying a read-only operation. However, it lacks details on pagination, ordering, or potential side effects. It does add value beyond the empty schema descriptions.
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 that effectively conveys the tool's purpose and expected output. There is no wasted text, and it is front-loaded with the action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, list output), the description covers the main functionality and output fields. However, it omits details on the site parameter format and potential output schema details, though an output schema exists. Overall 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?
The schema has 0% description coverage for the only parameter 'site'. The tool description mentions submitting to a GSC property, which hints at the parameter's purpose, but does not explain the required format, source, or constraints. This is insufficient to compensate for the lack of schema descriptions.
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 lists all sitemaps for a GSC property, including specific fields (dates, status, error counts). The verb 'list' and resource 'sitemaps' are specific and distinguishable from siblings like 'sitemaps_get' (single sitemap) and 'sitemap_audit' (analysis), though not explicitly differentiated.
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 is provided on when to use this tool versus alternatives like 'sitemaps_get' or 'submit_sitemap'. There are no usage conditions, prerequisites, or when-not-to-use instructions.
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?
Without annotations, the description carries the full transparency burden. It discloses diagnosis categories (ranking_loss, ctr_collapse, demand_decline) and a critical caveat about data lag (most recent 2-3 days incomplete). However, it does not state whether the tool is read-only or has side effects, leaving gaps in behavioral understanding.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main purpose. The second sentence concisely adds valuable details about diagnosis and data lag with no redundant or irrelevant information.
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 output schema exists to describe return values, so that gap is covered. However, the description omits parameter explanations and usage context, which are essential for an agent to use the tool correctly among 30+ siblings. The caveat about data lag adds value, but overall completeness is adequate but not thorough.
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?
Schema description coverage is 0%, so the description must clarify parameters. It completely fails to mention 'site' (required) or 'days' (optional, default 28). The agent receives no help understanding that 'days' defines the period size for comparison, leaving parameter semantics entirely to inference.
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: 'Find queries whose clicks dropped compared to the previous equally-sized period.' It specifies the verb (find), resource (queries with drops), and context (comparison period), effectively distinguishing it from siblings like seo_lost_queries by focusing on click drops with diagnosis.
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 explicit guidance on when to use this tool versus alternatives such as seo_lost_queries or analytics_anomalies. It includes a note about data lag but does not help the agent choose among sibling tools or understand prerequisites.
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 are absent, so the description carries the full burden. It discloses that it flags two types of issues with severity levels, which is adequate. However, it does not mention whether it is a read-only operation, any prerequisites, or potential side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, using two sentences to convey the core purpose and details. The second sentence is somewhat lengthy but still efficient. No redundant information is present.
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 2 parameters and an output schema (not shown), the description adequately explains the alerts checked but does not cover parameter meaning or return format. It is partially complete but leaves gaps for the agent to infer.
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?
With schema description coverage at 0%, the description should compensate by explaining the parameters. It does not explicitly mention 'site' or 'days' or how they affect the scan. The parameter semantics are not enhanced beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it scans for structural SEO risks, specifically traffic concentration and high-impression low-rank pages, with detailed severity and conditions. This uniquely distinguishes it from sibling tools like analytics_anomalies or get_search_analytics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains what the tool does but lacks explicit guidance on when to use it versus alternatives or when not to use it. The context of scanning for structural risks is implied, but no direct comparisons to sibling tools are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses accepted date formats and substring matching for page_path, but fails to mention rate limits, authentication requirements, pagination, or error behavior. Minimal behavioral disclosure beyond basic operation.
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 (two sentences plus bullet points), front-loaded with purpose, and every sentence adds value. No fluff or redundancy. Efficiently 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?
With 6 parameters and an output schema, the description lists returned metrics and explains filters and dates, which is helpful. However, it misses explanation for property_id and does not specify acceptable format for country (e.g., code vs name). Adequate but with notable gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaning for 5 of 6 parameters: dates (relative format), page_path (substring match), hostname/country (narrowing). Only property_id is omitted. This adds significant value beyond the bare schema.
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 it fetches GA4 page-level metrics and lists specific metrics (views, active users, etc.). It identifies the resource and action, but does not explicitly differentiate from sibling tools like ga4_conversion_funnel or ga4_user_behavior, which limits differentiation. A clear verb and resource, but no sibling distinction.
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 context on optional filters (page_path, hostname, country) and date formats, implying usage scenarios. However, it does not offer explicit guidance on when to use this tool versus alternatives, nor does it mention prerequisites or when not to use it. The guidance is implied but not comparative.
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?
Discloses 3-day reporting lag and the rolling window end date. With no annotations, description carries burden; it is adequate but does not explicitly state read-only nature or other safety 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?
Two concise sentences, front-loaded with purpose and key details. No fluff, 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 fetch tool with 4 parameters and existing output schema, the description covers purpose, grouping, and data freshness. Missing some parameter details but overall adequate for agent usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
0% schema description coverage, but description adds meaning for 'dimensions' (lists possible values: query, page, device, country) and explains 'days'. Does not mention 'row_limit' or 'site' format, so partial compensation.
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?
Clear verb 'Fetch' with specific resource 'GSC search analytics' and lists metrics (clicks, impressions, CTR, position). Groups by dimensions is mentioned, but no explicit differentiation from siblings like 'get_advanced_search_analytics'.
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 explicit when-to-use or when-not-to-use guidance. Does not mention alternatives or compare to sibling tools. Only implies usage via describing the function.
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?
With no annotations provided, the description must carry the burden. It reveals key behaviors: URL normalization, top-20 sorting, GA4 error handling, and question classification. However, it omits details like rate limits, auth requirements, or behavior on missing pages.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise and well-structured with clear steps. However, it includes implementation details (e.g., _normalize_url, try/except) that could be condensed without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (combining GSC and GA4) and the existence of an output schema (which relieves the need to describe return values), the description provides a reasonable overview. It lacks specifics on parameter input formats and edge case handling.
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 mentions the four parameters (days, site, page_url, property_id) and hints at URL normalization, but does not explain formats, allowed values, or constraints beyond defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Gather SEO content intelligence for a single page: top queries, question queries, and GA4 engagement.' It specifies the output components and distinguishes from sibling tools that focus on raw search analytics or GA4 alone.
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 usefulness for 'brief-writing, content refreshes, and intent analysis' and outlines steps, but does not explicitly state when to avoid this tool or compare it to alternatives like get_search_analytics or ga4_page_performance.
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?
With no annotations, the description carries full burden. It discloses grouping, metrics, date format, and filtering, but does not address permissions, rate limits, or potential pitfalls.
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 covering verb, resource, grouping, metrics, date format, and filtering. No redundant information.
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?
Has output schema so return values are likely covered. Description explains grouping and metrics, but lacks clarity on property_id requirement and authentication. Adequate but not fully complete for a 5-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so description adds value by explaining start_date/end_date formats and filtering with hostname/country. However, property_id is not described, which may be critical.
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 it fetches GA4 sessions grouped by channel group, source, and medium, and mentions key metrics. However, it does not explicitly differentiate from sibling tools like ga4_conversion_funnel or ga4_organic_landing_pages.
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 traffic source analysis and provides date format hints, but lacks explicit guidance on when to use this tool vs alternatives, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies a read operation ('Get'), but with no annotations, the agent has no information about side effects, authorization requirements, rate limits, or data freshness. Minimum viability but lacks depth.
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 that immediately conveys the tool's purpose without extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple nature (one parameter) and existence of an output schema, the description is mostly adequate. However, it could be improved by summarizing the output characteristics, such as the structure of permission details.
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 coverage is 0%, and the description adds no details about the site_url parameter (e.g., expected format, constraints, or how to obtain it). This leaves the agent with insufficient guidance.
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 (Get), the resource (permission level), and the target (specific GSC property URL). It is distinct from siblings like get_capabilities or get_performance_overview which focus on other aspects.
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 is provided on when to use this tool versus alternatives. With many sibling tools, explicit usage context would help the agent decide, especially since the tool is specialized (permission level only).
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?
Without annotations, the description carries full burden. It discloses that News does not support query dimension, a key behavioral constraint. However, it omits details like data range (days parameter), pagination (limit), and response structure, limiting transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that fronts the purpose and adds a constraint. No unnecessary words, and it earns its place with the query dimension note.
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?
Given the tool returns data (output schema exists but not detailed), the description should explain what fields are returned. It only mentions 'top pages by impressions', neglecting other potential columns. For a tool with many siblings, more context on output format is needed.
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?
With 0% schema description coverage, the description must compensate but does not. It fails to explain the 'days', 'site', or 'limit' parameters. While parameter names are somewhat clear, their roles (default values, required vs optional) are not clarified, leaving ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves Google News performance data, specifically top pages by impressions, and explicitly distinguishes it by noting that News does not support the query dimension. This differentiates it from siblings like get_search_analytics or discover_performance.
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 News performance data but does not explicitly state when to use this tool over alternatives (e.g., discover_performance for Discover, get_performance_overview for aggregated data). No exclusions or scenarios are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry full burden. It states output is a list of queries sorted by impressions, but does not mention whether it is read-only, pagination limits, or other metrics (e.g., clicks). The behavior is adequately described for a simple listing tool but lacks some detail.
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, direct and efficient. The first sentence states the action and criteria, the second explains the strategic value. No redundant information, front-loaded with the core purpose.
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?
Given the complexity (3 parameters, no annotations, no schema descriptions), the description is incomplete. It fails to document parameters or return structure. Output schema exists but description does not reference it. Essential context is missing for effective tool usage.
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?
Schema coverage is 0%, meaning no parameter descriptions in the schema. The description does not explain any parameters (site, days, min_impressions). This is a critical gap, as users must rely on property names alone. The description adds no value here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool lists queries between positions 8-15 sorted by impressions descending. It explains the relevance ('best candidates for ranking improvement'), distinguishing it from generic analytics tools like get_search_analytics. The verb 'List' and specific ranking range provide precise purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description implies usage for identifying queries close to page 1 that can be improved. It does not explicitly exclude other contexts or compare to sibling tools like seo_lost_queries, but the context is clear. Could mention when not to use (e.g., for queries already on page 1).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the basic purpose but does not mention whether the tool is read-only, any permission requirements, rate limits, or pagination behavior. The 'limit' parameter suggests paginated results but is not explained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is efficient and front-loaded, providing the essential purpose without any unnecessary 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?
The tool has an output schema (not shown) so return values are covered. However, with three parameters and no annotations, the description should at least explain the parameters. Given the simplicity and presence of output schema, the description is minimally complete but leaves gaps in parameter understanding for an agent.
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 description adds no information about the three parameters (days, site, limit). The schema has 0% description coverage, and the parameter names are only titled; the description does not explain their meaning, default values, or allowed formats. For an AI agent, this lack of guidance could lead to incorrect usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves Discover performance data (top pages by impressions) and explicitly notes that Discover does not support the query dimension, distinguishing it from search analytics tools. This gives a specific verb+resource and differentiates from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case is for Discover performance reporting. The note about the query dimension indirectly suggests not to use this tool for query-based analysis, which would be handled by tools like get_search_analytics. However, it does not explicitly state when to use this tool over others or provide 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?
No annotations are provided, so the description must convey behavioral traits. It indicates grouping but does not disclose pagination, sorting behavior, or whether the operation is read-only. For a fetch tool, basic transparency is there but limited.
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, front-loading the main action. It could be improved by integrating parameter explanations but remains efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 3 parameters and 0% schema coverage, the description is incomplete. It does not mention required parameters or defaults, and the context signals show output schema exists but that doesn't compensate for missing parameter documentation.
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 input schema has 0% description coverage for parameters, and the description does not explain what 'site', 'days', or 'row_limit' mean. It only describes the tool's core purpose without parameter details, leaving the agent uninformed.
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 'Fetch GSC data grouped by both page and query simultaneously,' providing a specific verb and resource. It distinguishes the tool from siblings like get_search_analytics by highlighting the dual grouping dimension.
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 adds 'Useful for identifying which query drives which page and diagnosing on-page relevance issues,' providing a clear use case. However, it lacks explicit guidance on when not to use it or alternatives among the many sibling tools.
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?
No annotations are provided, so the description bears full responsibility. It lists the return fields (verdict, robotsTxtState, indexingState, pageFetchState, googleCanonical, userCanonical, derived category) which gives insight into the tool's behavior. However, it does not disclose side effects, authentication needs, rate limits, or what happens if the URL is invalid or not in GSC. The tool is likely read-only, but this is not explicitly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured. It leads with the primary purpose in one sentence, then lists the return fields in a bullet-like format. Every sentence is necessary and there is no wasted text.
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 2 required parameters with no schema descriptions, an output schema (not shown but referenced), and a sibling batch tool, the description covers the return values but lacks parameter details and usage context. It is adequate for a simple tool but leaves gaps for an AI agent to make fully informed decisions.
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 input schema has 0% description coverage, meaning no parameter descriptions are provided in the schema. The tool description only mentions 'a single URL' but does not explain the parameters 'url' (format expectations) or 'site' (what it represents). This adds minimal value beyond the parameter names themselves.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool inspects a single URL in GSC to get indexing status, last crawl time, and canonical URL. The verb 'inspect' and resource 'URL in GSC' are specific, and the tool is distinguished from its sibling 'batch_url_inspection' by explicitly mentioning a single URL.
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 this tool (for a single URL) but does not explicitly mention when not to use it or provide alternatives. The sibling 'batch_url_inspection' is a natural alternative for multiple URLs, but the description does not reference it or provide usage 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?
With no annotations provided, the description adequately discloses that this is a read operation returning specific data. It does not state side effects, authentication, or error handling, but for a simple GET tool, the behavioral insight 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 two concise sentences. The first sentence states the purpose, and the second lists the return fields. There is no wasted verbiage, and the most critical information is front-loaded.
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 presence of an output schema, the description adequately covers return values but omits parameter explanations. For a simple tool with two required params, this lack of parameter documentation leaves a gap in completeness.
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?
Schema description coverage is 0%, and the description fails to explain the meaning or format of the two required parameters ('site' and 'sitemap_url'). The field names alone may not be sufficiently self-explanatory, especially 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 clearly states the tool retrieves details for a specific sitemap, distinguishing it from sibling tools like list_sitemaps (which lists all sitemaps) and sitemap_audit (which performs broader analysis). It specifies the return data: content type counts, error/warning counts, and status flags.
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 context by stating 'already submitted to a GSC property,' but it does not explicitly compare to alternatives or provide when-not-to-use guidance. No exclusions or sibling tool differentiation are mentioned.
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?
With no annotations, the description carries the full burden of behavioral disclosure. It reveals that it requires a CRUX_API_KEY environment variable, returns p75 percentile and ratings, and handles insufficient data with a 'not_enough_data' verdict. It lacks mention of read-only nature, rate limits, or error handling, but covers the essential behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, leading with the core purpose, then detailing return format, edge cases, and prerequisites. Every sentence adds 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?
The description covers the tool's purpose, parameters, return format (p75 and ratings), edge case (insufficient data), and prerequisite (API key). With an output schema present, the lack of detailed return structure explanation is acceptable. Minor omissions like rate limits or error codes prevent a perfect score.
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?
Since schema description coverage is 0%, the description compensates by specifying the allowed values for form_factor ('ALL_FORM_FACTORS' | 'PHONE' | 'DESKTOP' | 'TABLET') and noting that url is required. It could further clarify the expected URL format (e.g., fully qualified), but adds significant value beyond the bare schema.
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 it fetches current Core Web Vitals (LCP, INP, CLS, FCP, TTFB) for a URL from the CrUX API, establishing a specific verb and resource. However, it does not explicitly distinguish itself from the sibling tool 'crux_history,' which likely provides historical data, missing an opportunity for differentiation.
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 like 'crux_history' or other analytics tools. It does not mention when not to use it or any prerequisites beyond an API key, failing to help the agent choose 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?
With no annotations, the description carries the full burden. It discloses error handling behavior (returns error dict on HTTP 400/403 instead of raising) and the specific dimension used. This adds useful behavioral context beyond what annotations would provide, though it does not mention read-only nature or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loading the purpose, then adding technical detail and error handling. Every sentence adds value with no waste. It is efficiently structured for quick agent scanning.
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?
While the description covers the tool's purpose, technical approach, and error behavior, it lacks critical parameter details and does not mention the output structure (though an output schema exists). Given the tool's moderate complexity (3 params, 1 required) and no annotations, more completeness would be beneficial.
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%, yet the description provides no explanations for the three parameters (days, site, limit). The agent must infer meaning from parameter names alone, which is insufficient. Baseline for no param info is low, and the description fails to compensate.
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: 'Get queries where AI Overview appearance data is available.' It specifies a unique resource (AI Overview data) and uses a specific verb. Among siblings, none target AI Overviews, making it easily distinguishable.
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 explains the technical approach (searchAppearance dimension, dataState=all) but does not provide explicit guidance on when to use this tool vs. alternatives like get_search_analytics. The context of siblings implies it is for AI Overview-specific data, but no direct usage boundaries are 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?
No annotations provided, so description carries full burden. Describes the z-score algorithm, threshold default, and return values. Adequately explains what the tool computes without hiding side effects (none apparent). Could be more explicit about read-only nature, but acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences, front-loaded with purpose, method, and output. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema exists (not shown), description adds expected return fields. Explains algorithm and parameters well enough for a statistical tool. Lacks mention of pagination or limits, but not critical for this use case.
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 0%, but description adds context for 'days' (baseline size) and 'threshold' (z-score cutoff). However, 'site' parameter is not explained. Partially compensates for missing schema descriptions.
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?
Clearly states it detects statistically abnormal click days using z-score analysis. Specifies criterion (abs(z_score) > threshold) and outputs. However, does not explicitly differentiate from sibling tools like traffic_drops or check_alerts, though the method is distinct.
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?
Provides guidance on parameter usage ('Use days=90 or more for meaningful baseline statistics') but does not specify when to use this tool versus alternatives like check_alerts or traffic_drops. No 'when not to use' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It describes a read operation ('inspect', 'returns fields') but does not elaborate on side effects, rate limits, or what happens on invalid input. It references 'inspect_url' behavior, which adds some context but insufficiently covers all behavioral traits.
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 extraneous information. Every word serves a purpose; highly 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?
Output schema exists, so return value documentation is handled. The description covers the tool's purpose and relationship to 'inspect_url'. However, it could briefly note error handling for individual URLs in the batch or prerequisites (e.g., site must be verified). Still, it is mostly sufficient for a simple batch wrapper.
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 0%, so the description must compensate. It adds a constraint on the 'urls' parameter ('up to 10') and implies 'site' is a GSC property, but does not describe the format or range of values. Some meaning is added beyond the schema, but not thoroughly.
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 'inspect up to 10 URLs at once in GSC', specifying a specific verb, resource, and scope. Distinguishes itself from the sibling 'inspect_url' by implying batch vs 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?
Implies when to use (multiple URLs) but does not explicitly state when not to use (e.g., for single URL use inspect_url) or provide alternative tools. The description is adequate but lacks explicit 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?
With no annotations provided, the description carries full burden. It transparently discloses the scoring breakdown, error handling via try/except for missing credentials or data, renormalization over available components, and the fallback score of 0. This gives the agent a clear picture of behavior beyond a simple 'compute' call.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, then uses a clear bullet list for the scoring breakdown. Every sentence adds value; there is no redundancy or filler. The length is justified by the complexity of the calculation.
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 output schema exists, so return values need not be described. The description covers calculation logic, error scenarios, and parameter roles. It does not explicitly state necessary permissions or setup for GSC/GA4/CrUX, but the error handling implies missing credentials are gracefully handled. Sufficient for a computational tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It explains property_id overrides GA4_PROPERTY_ID and hostname/country scope GA4 queries, but url and site remain under-explained (only 'required'). For a 5-parameter tool, coverage is partial but adds meaningful context for three 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 starts with a clear action verb 'Compute' and specifies the resource: a 0-100 health score for a single page. It explicitly lists the four data sources (GSC, GA4, CrUX, schema), immediately distinguishing it from sibling tools like crux_page_vitals or ga4_page_performance that provide only component data.
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 explains what the tool does but offers no guidance on when to use it versus alternatives among the many sibling tools. There is no mention of prerequisites, limitations, or typical use cases that would help an agent choose this tool over others like batch_url_inspection or page_analysis.
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?
With no annotations, the description carries full burden. It states 'Makes one GSC call per search type' which is useful, but doesn't disclose potential rate limits, permission needs, or performance considerations. The behavioral context is partially transparent.
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 efficiently convey purpose and behavior. No redundant information; the description is front-loaded and every sentence 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?
While an output schema exists (not shown in full), the description still lacks mention of the number of API calls and the 'days' parameter role. For a tool with few parameters, it is adequate but could provide more context to reduce agent uncertainty.
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 coverage is 0%, so description must compensate. It explains 'site' and 'url' parameters but omits explanation of 'days' (default 28). The description does not fully cover the meaning of all three parameters, leaving ambiguity for the 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 clearly states the verb 'aggregate' and the resource 'clicks and impressions broken down by search type for a site or specific URL'. It is specific and distinguishes from siblings like 'get_search_analytics' which returns overall data without breakdown.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (when you need breakdown by search type) and mentions scoping to a URL if needed. However, it does not explicitly state when not to use or provide alternatives, though the context signals list many 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?
No annotations are provided, so the description carries the full burden. It discloses that step 1 conversion_rate is always null and that at least 2 steps are required. It does not mention rate limits or authentication, but the read-only nature of a report tool is implied.
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 (4 sentences), front-loaded with the main purpose, and each sentence adds necessary detail 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?
For a tool with 4 parameters, no schema descriptions, and an existing output schema, the description covers the step structure, output format, and property_id override. It could elaborate on date format but is otherwise adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Since the schema has 0% coverage, the description adds meaning by explaining that steps are dicts with 'name' and 'event', and that property_id is optional for overriding defaults. However, it does not detail the date parameters.
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 it runs a GA4 funnel report via a specific API, explains the step structure, and mentions output details. However, it does not differentiate from the sibling tool 'ga4_conversion_funnel', which could cause confusion.
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 some context (e.g., overriding property_id for multi-property setups) but lacks explicit guidance on when to use this tool versus alternatives, such as 'ga4_conversion_funnel'.
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?
Despite no annotations, the description discloses the behavioral trait of computing an opportunity_score formula and explains what high scores mean. This adds valuable context beyond the tool's name, though it doesn't explicitly state idempotency or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences that front-load the main action. Every sentence adds value: the first defines the filter criteria, the second explains the scoring and interpretation.
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 output schema exists, the description appropriately focuses on the filtering logic and scoring formula. It could mention the return format briefly, but the output schema covers that. The description is complete for a reporting 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 coverage is 0% and the description provides no explanation of parameters (site, days, min_impressions). The description does not compensate for the lack of parameter documentation in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: identifying pages ranking between positions 4-15 with CTR below industry benchmark. This is a specific verb-resource combination that distinguishes it from siblings like 'search_by_page_query' or 'compare_search_periods'.
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 finding quick wins, but no explicit guidance on when to use or not use this tool versus alternatives. There is no mention of prerequisites or context for exclusion.
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?
With no annotations, the description handles transparency well: it details the ratio calculation, the four outcome categories with their thresholds (including inclusivity), and mentions the GA4 query limit of 10000 to avoid undercounting. It also notes that hostname and country narrow the query. This gives a clear behavioral model, though it could mention error handling or rate limits.
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 well-structured: it starts with a clear purpose, then explains the ratio and outcomes with examples. While slightly long, each sentence adds necessary information. The bullet list of outcomes is clear but could be condensed slightly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity, the description covers the main behavior: the comparison, ratio interpretation, threshold boundaries, and query limit. With the presence of an output schema (context signal), the description's inclusion of outcome categories makes it largely complete. Minor gaps like handling of missing GA4 data or zero sessions are not addressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 5 parameters with 0% description coverage. The description adds meaning for 'hostname' and 'country' (they narrow the GA4 query) and implies a default 'days' of 28 (via schema default), but it does not explain 'site' or 'property_id'. It partially compensates for the low schema coverage but not fully.
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 compares total GSC clicks with total GA4 organic sessions to detect tracking gaps. It uses a specific verb and resource, and the unique function distinguishes it from sibling tools like analytics_anomalies or ga4_traffic_sources.
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 should be used to detect tracking discrepancies between GSC and GA4, but it does not explicitly state when to use or when not to use it, nor does it compare to alternatives. The guidance is adequate but lacks explicit recommendations.
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?
With no annotations, the description carries the full burden. It reveals a 3-day lag and explains the period definitions. It does not mention authentication or permissions, but the read-only nature is implied.
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: three sentences, front-loaded with the main purpose, and 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?
Given the output schema exists and the tool is simple, the description adequately explains the comparison logic, lag, and use case. Minor edge cases are not covered.
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 0%. The description explains the 'days' parameter in context (e.g., 7 for weekly trends) but does not mention the 'site' parameter, leaving partial coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool compares two consecutive equal-length windows and reports delta in clicks and impressions, which distinguishes it from sibling analytics tools that provide raw data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states it is useful for week-over-week or month-over-month trends, providing context for when to use it. However, it does not list alternatives or 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?
Without annotations, the description carries the burden. It discloses sequential report execution and date format, but lacks read-only confirmation, rate limits, or side effect details. 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 concise with front-loaded main action, using four clear sentences without 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?
Given 6 parameters, no annotations, and an output schema, the description covers the main usage and report structure well, though it omits error handling or edge 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 coverage is 0%, so the description must compensate. It explains date relative format, hostname/country filtering, and event_name filter, but does not clarify property_id or provide complete parameter meanings.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it fetches GA4 conversion data, specifically pages with conversions and event counts, and runs two sequential reports. This distinguishes it from sibling tools like ga4_page_performance or ga4_user_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 context by noting it is useful for identifying which pages and events drive goals, but does not explicitly state when to use it versus alternatives or mention exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It lists returned metrics (sessions, engaged_sessions, bounce_rate, etc.) which helps understand behavior. However, it does not disclose read-only nature, rate limits, auth needs, or data freshness, leaving gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences long, front-loaded with purpose, and each sentence adds value. No fluff or repetition. It is well-structured and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (6 parameters) and presence of an output schema, the description covers inputs well and outlines returned data. Minor gaps: limit meaning and error handling are absent, but overall it provides sufficient context for most use cases.
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 0%, but the description adds meaning for most parameters: explains date format (GA4 relative format), property_id override, hostname and country narrowing. Limit is mentioned but not detailed. Overall, it significantly enhances schema understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it fetches GA4 landing page performance filtered to organic traffic only. It uses specific verbs and resources, and distinguishes from sibling tools like ga4_page_performance and ga4_traffic_sources by narrowing to organic traffic and landing pages.
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 explains when to use the tool (for organic landing page performance) and includes context for multi-property setups by passing property_id. However, it does not explicitly state when not to use it or mention alternative tools for different scenarios.
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?
No annotations are provided, so the description carries the full burden. It mentions authentication context and permission levels, which adds transparency. However, it does not disclose pagination, rate limits, or behavior when no properties are 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 a single sentence with 14 words, highly concise and front-loaded with the main action. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is complete for a simple list tool with no parameters and an output schema. It covers the basic purpose and key details (permission levels). Could mention edge cases but not critical.
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 zero parameters, so the description does not need to add parameter details. It appropriately focuses on the tool's action and output, which is sufficient given the simple input.
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: listing GSC properties with permission levels. It uses a specific verb ('List') and resource ('GSC properties'), and distinguishes from sibling tools like 'get_site_details' which work on a single property.
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 accessing available properties but does not explicitly state when to use this tool versus alternatives, nor does it mention any prerequisites or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full burden. It explains the algorithm (HHI), the conflict_score formula, and the min_impressions filter. This provides good transparency about how the tool behaves, though it does not explicitly state 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?
The description is concise with four sentences, each adding value: purpose, algorithm, formula, filter. No fluff, front-loaded with the main action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (indicated true), the description does not need to explain return values. It covers inputs and algorithm sufficiently for a 3-parameter analytical tool. Could briefly mention the output shape but not required.
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 adds meaning for min_impressions (filtering noise) but does not elaborate on site or days. Schema coverage is 0%, so the description partially compensates but could provide more detail for all parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: detecting queries where multiple pages compete for the same ranking slot. It uses a specific verb ('Detect') and resource ('queries'), making it distinct from sibling tools like seo_striking_distance.
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 SEO analysis and keyword cannibalization detection but does not explicitly state when to use this tool versus alternatives or exclude certain scenarios. There is no mention of when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Given no annotations, the description fully carries the behavioral burden. It explicitly states the 80% threshold, the minimum click filter, and the data lag warning that can cause false positives. This is thorough and beyond basic expectations.
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 filler. The first sentence states the main purpose, the second adds a noise filter, and the third warns about data lag. Every sentence 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?
The tool is moderately complex (period comparison, threshold, noise filter). The description explains the logic and output implications but omits parameter details and does not clarify how the periods are defined (e.g., 'previous period' is the same length as 'days' before the current period). With an output schema present, the return values are handled, but parameter semantics are missing.
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 input schema has 0% description coverage, and the description does not mention any parameters (site, days). It provides no additional meaning to help the agent understand how to set the parameters correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it finds queries with 80%+ fewer clicks compared to a previous period, specifying a specific resource (queries) and a clear action (find lost queries). It distinguishes from sibling tools like traffic_drops by focusing on query-level drops.
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 context on when results are meaningful (at least 5 clicks in previous period) and warns about incomplete data in the last 2-3 days. However, it does not explicitly compare to sibling tools or specify when to prefer this over 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?
No annotations are provided, so the description carries the burden. It discloses the return format (p75 per week, oldest to newest), the metrics available, and the API key requirement. However, it does not mention rate limits, error handling, or behavior for URLs with no data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three focused sentences. The first sentence states the core purpose, the second details parameter options, and the third mentions return format and requirement. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the key aspects: what data is returned (p75 per week), the parameters, and the environment variable requirement. An output schema exists but is not shown; the description provides sufficient context for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It explains form_factor options (ALL_FORM_FACTORS, PHONE, DESKTOP, TABLET) and lists metric values explicitly. The url parameter is not described beyond being a string, but the overall parameter meaning is clear from the tool's purpose.
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 'Fetch 40 weeks of Core Web Vitals history for a URL from the CrUX History API.' It specifies the action (fetch), the resource (Core Web Vitals history), and the scope (40 weeks), distinguishing it from siblings like crux_page_vitals.
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 explains parameter options (form_factor, metric) and the required environment variable CRUX_API_KEY. However, it does not explicitly state when to use this tool instead of alternatives such as crux_page_vitals or other analytics 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?
No annotations are provided, so the description carries full burden. It discloses that the tool executes a single batch request and returns three reports, implying a read-only operation. It does not mention side effects, rate limits, or authentication, but the behavior is reasonably transparent for a reporting tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two paragraphs and four sentences. The first sentence front-loads the core purpose, followed by a technical detail, a usage hint, and a filter clarification. No filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema, the description's lack of return structure detail is acceptable. It sets expectations by naming the three reports. However, the missing parameter documentation for property_id creates a gap, preventing a perfect score.
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 only explains hostname and country as filters, leaving start_date, end_date, and property_id unexplained. The property_id is especially important as it is nullable with a default null, and the description does not clarify how it is resolved.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches GA4 sessions and engagement rate broken down by device, country, and user type. It specifies it executes a single batch request returning three reports, which distinguishes it from sibling tools like ga4_conversion_funnel or ga4_page_performance that focus on other metrics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides useful context by stating it is 'useful for audience analysis' and explains that hostname and country parameters narrow results across all sub-reports. This helps an agent decide when to use it, though it does not explicitly exclude other use cases or name alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description discloses grouping behavior (by screen name, country, device category) and parameter nuance for hostname. Could mention auth/rate limits but sufficient for read operation.
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?
Four sentences, each with distinct value. Front-loaded with main action. No redundant 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?
Covers purpose, grouping, and param usage. Though output schema exists, description could mention it returns active users grouped; still adequate for a realtime monitoring tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, so description must clarify. Explains hostname narrows results but leaves property_id unexplained. Adds some value over bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states verb 'fetch', resource 'active users', and time window 'last 30 minutes from the GA4 Realtime API'. Distinguishes from siblings like ga4_conversion_funnel by specifying 'realtime' and 'current moment'.
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 says 'Use for live traffic monitoring' and notes no date range applies. Does not name alternatives or when not to use, but context is clear.
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?
No annotations are provided, so the description carries the full burden. It details parameter options but does not disclose side effects, authentication requirements, or rate limits. Since it is a read operation, safety is implied but not stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, with a single introductory sentence followed by bullet-like parameter explanations. No extraneous words, and the purpose is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 6 parameters, 0% schema coverage, and an output schema exists, the description covers the main controllable aspects. It could mention that it returns analytics rows, but the output schema handles that, so completeness is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description compensates by explaining the allowed values for search_type, data_state, and dimensions. However, it does not explain the site, date_range_days, or row_limit parameters beyond their names.
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 starts with a clear verb 'Fetch' and specifies the resource 'GSC search analytics'. It lists controllable parameters, distinguishing it from the simpler sibling get_search_analytics.
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 'Use when get_search_analytics defaults are not sufficient', providing clear guidance on when this tool is appropriate versus the sibling. Could be slightly more explicit about when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. Discloses the safety guard (URL validation), the destructive scope (removes from tracking only), and that the actual file is not deleted. This goes beyond the schema's parameter types.
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 short sentences, each adding distinct value: purpose, safety guard, and limitation. Efficiently front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (two required params, destructive but safe) and the presence of an output schema (not shown), the description covers the essential behavior, safety, and scope. Could mention site format (e.g., URL format for GSC property) but overall 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 0%, so description must add meaning. For 'sitemap_url', it adds validation rule (ends with .xml or contains /sitemap). For 'site', no extra info is provided, leaving its semantics implicit.
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 'Delete a submitted sitemap from a GSC property', which is a clear verb+resource combination. It distinguishes this tool from siblings like submit_sitemap (add) and list_sitemaps (list) by focusing on deletion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides context for safe usage: requires URL to end with '.xml' or contain '/sitemap' as a safety guard. Also clarifies what is not affected: 'Removes the entry from GSC tracking only; does not delete the sitemap file.' Does not explicitly state when not to use or alternatives, but the guard and limitation are 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?
No annotations provided, so description carries full burden. It discloses the 10-URL limit and filtering behavior. While it doesn't explicitly state it's safe and non-destructive, the name and context imply a read operation. Minor gap, but overall good.
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, clear and front-loaded. Could be slightly more concise but efficient overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the presence of an output schema, the description covers purpose, limit, filtering, and sibling distinction. Lacks explicit parameter descriptions but is fairly complete for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It mentions 'up to 10 URLs' which adds context for the 'urls' parameter, but does not describe the 'site' parameter. Provides some value but incomplete for all 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?
Description clearly states the tool inspects up to 10 URLs and returns only those with indexing problems, with a summary count by category. It lists specific categories (indexed, not_indexed, robots_blocked, fetch_error, canonical_issue) and distinguishes from a sibling tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to use 'batch_url_inspection' when results for all URLs are needed, providing clear guidance on when to use this tool versus an alternative.
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?
With no annotations, the description fully discloses behavior: joining on normalized URL, handling missing pages, computing opportunity score with formula, sorting, truncating, and deriving engagement rate. This is thorough and transparent.
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 slightly long but well-structured with clear statements. Each sentence adds value, though some redundancy could be trimmed. Front-loaded with the core purpose.
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 of joining two data sources and no annotations, the description covers joining logic, scoring formula, sorting, and truncation. Missing parameter details for all parameters 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 coverage is 0%, so description must compensate. It explains 'hostname', 'country', and 'limit' but does not cover 'site', 'days', or 'property_id' explicitly. Partial addition of meaning beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool joins GSC and GA4 data at the page level and ranks by opportunity score. It uses specific verbs like 'Join' and 'rank' and distinguishes itself from siblings like 'ga4_organic_landing_pages' by explaining the combination.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for combined page-level analysis but does not explicitly state when to use this tool over alternatives. It provides context on data sources and joining logic, which helps understand its purpose.
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?
With no annotations provided, the description fully bears the burden of disclosure. It accurately describes the tool's behavior as listing tool names, which is non-destructive and straightforward. No additional behavioral traits need to be disclosed for this simple tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of nine words, perfectly concise and front-loaded with the core functionality. Every word contributes value, with no unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and the description is sufficient to understand its purpose. Although an output schema exists, the description clearly states it returns tool names, which is adequate. No additional details are needed given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty with zero parameters, and schema description coverage is 100%. The description does not need to elaborate on parameters since none exist, meeting the baseline of 4 for zero-parameter tools.
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 verb 'List', the resource 'available tool names', and the scope 'in this MCP server', making it clear what the tool does. It effectively distinguishes itself from sibling tools, which are the tools being listed.
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 indicates the tool's purpose, and in context with sibling tools, it is obvious that this tool is for discovering available tools. However, it does not explicitly state when to use it vs. alternatives or when not to use it, though such guidance is not critical given its meta-tool nature.
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?
Despite no annotations, the description discloses key behaviors: detecting all <script> blocks, checking required fields, suggesting missing schemas based on URL patterns, and listing possible verdicts. It also states that no authentication is needed. It does not cover rate limits or error details beyond fetch_error, but is generally transparent.
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, using seven well-structured sentences that front-load the main purpose. Every sentence adds value without redundancy, making it efficient for an AI agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple input (one parameter) and the presence of an output schema (so return values need not be fully described), the description adequately covers input, behavior, and output summary. It includes verdicts and recommendations, making it complete for the tool's complexity.
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 only one parameter (url) and 0% schema description coverage, the description compensates by explaining that the URL is to be fetched and that it works on any public URL. This adds meaning beyond the schema alone, though more detail on URL format or constraints could improve 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 that the tool fetches a URL and validates its JSON-LD structured data schemas, using specific verbs and resources. It distinguishes from sibling tools like 'inspect_url' by focusing on schema validation rather than general page analysis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for usage, noting that authentication is not required and it works on any public URL. However, it does not explicitly state when to use this tool versus alternatives like 'inspect_url' or 'page_analysis', though the specialization is implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description transparently discloses key behaviors: one-level recursion for sitemap indexes, use of defusedxml for safe parsing, and the exact return structure (urls_declared, urls_in_gsc, urls_missing_from_gsc, missing_sample, verdict with possible values). This goes beyond basic expectations.
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 (4 sentences), front-loaded with the core purpose, and logically structured. It covers key aspects without unnecessary details, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (not shown) and only two simple parameters, the description provides comprehensive context. It explains the tool's process, safety measures, and return values, leaving minimal gaps for an agent to decide 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?
The input schema has no descriptions (0% coverage), but the tool name and description make 'site' and 'sitemap_url' self-explanatory. The description could add format hints (e.g., 'site: sc-domain:example.com') for clarity, but the current text is sufficient for an agent to understand the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Fetch a sitemap, parse its URLs, and cross-reference with GSC indexed pages.' It specifies the resource (sitemap and GSC indexed pages) and actions (fetch, parse, cross-reference), which distinguishes it from siblings like list_sitemaps or submit_sitemap.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for auditing sitemap coverage against GSC but does not explicitly state when to use this tool over alternatives. No exclusions or when-not-to-use guidance is provided, leaving the agent to infer context.
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?
With no annotations, the description fully covers behavioral traits: required authentication (service account), retry policy (up to 3 times), and error propagation. This provides essential operational context beyond the schema.
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, front-loaded with purpose, concise with no fluff. Each sentence adds necessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two parameters and an output schema, the description covers purpose, auth, retry, and error handling. Output schema handles return values, so description is 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?
Schema has 0% description coverage. Description adds meaning by explaining url_type values and their meanings, and implicitly defines url. Partially compensates for missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool submits a single URL to the Google Indexing API for crawl notification, with specific verb and resource, distinguishing it from batch submission and other 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?
The description implies use for single URL submissions by specifying 'single URL', but does not explicitly mention alternatives like 'submit_batch' for multiple URLs. Context is clear but lacks direct comparison.
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?
No annotations provided, but the description fully discloses behavior: batching mechanism, daily quota limits, optional url_type with default, and response contents (per-URL results, counts, quota warning).
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?
Very concise: three sentences covering action, return details, quota, and default parameter values. No fluff, every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description still adds value by summarizing returns (per-URL results, counts, quota remaining) and the quota_warning condition. The tool is moderately complex with two parameters, and the description covers all essential aspects without gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description carries full burden. It explains the 'urls' parameter as a batch of URLs, and clarifies the 'url_type' parameter values (URL_UPDATED default, URL_DELETED) and its purpose.
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 'submit', resource 'multiple URLs', and scope 'HTTP batches of 100'. It distinguishes from the sibling 'submit_url' by explicitly mentioning batching and multiple URLs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides important usage constraints: daily limit of 200 requests, batch size of 100, and a warning threshold. Does not explicitly tell when to use this versus the single URL tool, but the mention of batching implies use for multiple URLs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

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

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

Card Badge

Copy to your README.md:

[![google-search-console-mcp MCP server](https://glama.ai/mcp/servers/FlorianBruniaux/google-search-console-mcp/badges/card.svg)](https://glama.ai/mcp/servers/FlorianBruniaux/google-search-console-mcp)

Score Badge

Copy to your README.md:

[![google-search-console-mcp MCP server](https://glama.ai/mcp/servers/FlorianBruniaux/google-search-console-mcp/badges/score.svg)](https://glama.ai/mcp/servers/FlorianBruniaux/google-search-console-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/FlorianBruniaux/google-search-console-mcp'

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