Google Search Console MCP Server

Server Quality Checklist

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

Latest release: v0.3.2
Disambiguation3/5
Many tools have overlapping purposes (e.g., get_sitemaps, list_sitemaps_enhanced, manage_sitemaps all can list sitemaps; get_search_analytics vs get_advanced_search_analytics). Detailed descriptions help distinguish, but the redundancy creates ambiguity.
Naming Consistency2/5
Naming is inconsistent: some use verb_noun (list_properties, get_site_details), others use gsc_ prefix for diagnostics, but verbs vary (list vs get, build vs gsc_build). No single pattern is followed across all tools.
Tool Count2/5
32 tools is excessive for GSC's limited API surface. Many tools are near-duplicates or highly specialized diagnostics that could be combined, making the toolset feel bloated.
Completeness4/5
Covers properties, sitemaps, URL inspection, search analytics, performance overview, and advanced diagnostics. Minor gaps like crawl errors or detailed index coverage, but overall a thorough surface for GSC.
Average 3.9/5 across 32 of 32 tools scored. Lowest: 2.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses it is read-only and does not mutate state, and mentions pagination and file location. However, it lacks details on rate limits, auth requirements, or what happens if files already exist. With no annotations, more context would be beneficial.
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 that front-load the core functionality. It is appropriately sized for a tool with moderate complexity, though it could be more structured.
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 11 parameters and no parameter descriptions, the description is insufficient. It does not explain key parameters like filters, dates, or dimensions, leaving agents without enough context to use the tool effectively.
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 provides no information about any of the 11 parameters. The schema itself lacks descriptions, so the agent has minimal guidance on parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Export a read-only Search Analytics snapshot to JSONL and/or CSV plus manifest', which provides a clear verb and resource. However, it does not distinguish this tool from siblings like get_search_analytics, which might also retrieve similar 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?
No explicit guidance on when to use this tool versus alternatives. The description implies it is for exporting, but does not specify scenarios or provide reasons to choose it over 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?
The description correctly identifies the tool as 'read-only' and explains it compares current vs previous rows by dimension keys, returning stable JSON. However, with no annotations, it could disclose more about rate limits, data staleness, or behavior with missing 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?
Two efficient sentences: first states purpose, second adds methodology and output format. No redundant or extraneous information.
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 has 11 parameters (5 required), no schema description coverage, and no annotations, the description is insufficient to guide correct usage. The output schema exists but is not referenced, and parameter semantics are completely absent.
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 0% schema description coverage, the description provides no explanation of parameters like site_url, date ranges, max_items, or dimensions. It adds no value beyond the raw schema, leaving the agent without guidance on how to properly set inputs.
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 builds a 'read-only prioritized action queue for Search Analytics traffic drops' and mentions it uses two official query calls. However, it does not differentiate from sibling tools like compare_search_periods or other build_*_queue tools, leaving ambiguity about when to use this one.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs. alternatives such as compare_search_periods. The description does not specify prerequisites, context, 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?
No annotations are provided, so the description carries the full burden. It states the tool is 'read-only' and 'sampled,' and clarifies it is a 'diagnostic queue, not proof.' However, it does not disclose whether the queue is persistent, how sampling works, or potential side effects (e.g., if it overwrites previous queues). For a tool with no annotations, this is adequate but not comprehensive.
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, consisting of three short sentences. It is front-loaded with the core purpose. However, it could benefit from a more structured format (e.g., bullet points or explicit parameter guidance) given the complexity of the tool (8 parameters). As is, it is efficient but slightly under-structured.
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's complexity (8 parameters, output schema present but not described) and lack of schema descriptions, the description is incomplete. It does not explain how parameters affect the queue behavior, nor does it detail the output format. While the purpose is clear, the missing parameter semantics leaves significant gaps for an AI agent to correctly invoke the tool.
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%, leaving 8 parameters completely undocumented. The description mentions 'dimensions query,page' and 'sampled' but does not connect these to any specific parameter like row_limit, max_queries, or min_total_impressions. The description adds no semantic value beyond the parameter names, failing 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Build a read-only sampled decision queue for likely keyword cannibalization,' specifying the verb, resource, and purpose. It distinguishes from siblings like gsc_build_content_action_queue by focusing on cannibalization. The line 'Uses one official Search Analytics query call with dimensions query,page' adds technical specificity, and 'diagnostic queue, not proof' clarifies limitations.
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 diagnosing keyword cannibalization but does not provide explicit guidance on when to use this tool versus alternatives like gsc_build_content_action_queue. It lacks when-not-to-use conditions or prerequisites. The context of sibling 'build queue' tools suggests additional comparative guidance would be beneficial.
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, and the description does not disclose behavioral traits such as whether it is read-only, any rate limits, required permissions, or side effects. For a comparison tool, it fails to mention if data is fetched from an API, cached, or if it modifies state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured as a docstring with parameter list. It is fairly concise for 7 parameters, but the parameter descriptions are somewhat verbose. Could be more terse without losing meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers required parameters adequately, and since there is an output schema, omitting return value details is acceptable. However, it lacks usage context and does not mention any prerequisites or limitations.
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 0% description coverage (no descriptions in JSON Schema), so the description carries full burden. The description explains each parameter's meaning and format (e.g., site_url formats, date format). This adds significant value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: comparing search analytics data between two time periods. The name 'compare_search_periods' and the description together distinguish it from siblings like 'get_search_analytics' or 'get_performance_overview', which do not perform comparisons.
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 parameter details but no explicit guidance on when to use this tool versus alternatives (e.g., 'get_search_analytics' for a single period). No when-not-to-use or context for selection is 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?
The description mentions 'read-only' which assures no side effects, but does not disclose auth requirements, rate limits, or how it combines the three data sources. With no annotations, more behavioral context is desirable.
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, clear sentence with 16 words—no redundancy or excess.
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 9 parameters and no schema descriptions, the description is too brief. It omits details on how parameters affect the report and the relationship between inputs and outputs, though an output schema exists.
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 provides no elaboration on any of the 9 parameters (e.g., site_url, row_limit, data_state). Users must rely solely on parameter names, which are ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool composes a read-only weekly SEO ops report from specific data sources (Search Analytics, diagnostic queues, manual checklist). It effectively distinguishes from sibling tools like get_search_analytics (raw data retrieval) and gsc_build_*_queue (queue builders).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for generating a consolidated report but provides no explicit when-to-use or when-not-to-use guidance against alternatives. Context from sibling names helps, but the description itself lacks usage criteria.
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 discloses that the tool is informational and benign, but does not specify what information is returned or any potential side effects. For a zero-parameter tool, this is adequate but 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?
A single sentence that is front-loaded and contains no unnecessary words. Every part 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?
Given that the tool has no parameters and an output schema exists, the description is moderately complete. However, it does not specify what kind of information is provided (e.g., bio, contact, version), leaving the agent uncertain about the output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, and the input schema (with 0 properties) is fully documented. The description adds no parameter meaning, but none is needed. Baseline is 4 for zero-parameter tools.
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 provides information about Amin Foroutan, the creator. It specifies the verb ('provides information') and resource ('the creator of MCP-GSC'). This distinguishes it from sibling tools, which are all related to GSC functionality.
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 given on when to use this tool vs alternatives. While it is unique among siblings, the description does not mention any context or exclusions. The agent must infer its use case.
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?
Explicitly declares read-only and that it does not mutate Search Console state. With no annotations, this is good, though rate limits or data freshness are unaddressed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is brief (3 sentences) and front-loaded with purpose. No redundancy, but could be slightly more informative without bloat.
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 an output schema existing, the large number of parameters (12) with no description coverage leaves significant gaps. The agent lacks guidance on parameter values like dates, thresholds, and dimensions.
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 0% and description provides no explanation for any of the 12 parameters, leaving their meaning and usage entirely to 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?
Clearly states it builds a read-only prioritized content-opportunity action queue using Search Analytics. Distinguishes from sibling tools by naming specific alternative queues.
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?
Describes what it returns but does not explicitly state when to use this tool over alternatives like gsc_build_cannibalization_decision_queue. Context is implied but not directive.
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, and the description does not disclose behavioral traits beyond deleting. It omits side effects (e.g., irreversibility, impacts on indexing) or any required permissions, which is essential for a destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the purpose and structured with clear argument headings. It is relatively concise, though the argument details are slightly lengthy. Overall well-organized.
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 that an output schema exists, return value explanation is not needed. However, the description lacks usage guidelines and behavioral transparency, making it insufficiently complete for a tool with no annotations and high parameter count.
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 the description must compensate. It provides thorough detail for both parameters: site_url format with examples and domain property clarification, and sitemap_url as full URL. This adds significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Delete (unsubmit) a sitemap from Google Search Console.' It uses a specific verb (Delete) and resource (sitemap), and implicitly distinguishes from sibling tools like 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 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 (e.g., audit_sitemap_urls) or any prerequisites (e.g., permissions). It only describes arguments, not the usage context.
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 provided, so description carries full burden. Only states it adds a site but does not disclose consequences of adding, prerequisites, or if it has destructive effects. Does not mention authentication 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: one sentence for purpose, then parameter explanation. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool, description is fairly complete. Covers purpose and parameter format. Could mention output or errors but not required per output schema existence.
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% coverage with only 'Site Url' title. Description adds essential semantics: exact match requirements, examples for URL patterns and domain properties. Significantly compensates for 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?
Description clearly states 'Add a site to your Search Console properties.' Uses specific verb and resource, and distinguishes from sibling tools like delete_site or list_properties.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. With siblings like delete_site, get_site_details, and list_properties, explicit usage context would help agents choose correctly.
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?
In the absence of annotations, the description fully discloses that the tool is auth-free, read-only, never calls external APIs, never writes files, and never mutates state. The term 'sampled adjacent technical diagnostics' is somewhat vague but overall provides a clear safety profile. A small deduction for not clarifying 'sampled' or 'adjacent'.
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 two sentences: the first states the purpose, the second elaborates on safety and scope. It is concise and front-loaded with the essential verb and resource. However, it could be structured slightly better with bullet points or clearer separation of purpose and behavior.
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 of 3 parameters (2 required), 0% schema descriptions, and no annotations, the description lacks completeness. It does not explain the expected output (though an output schema exists), the meaning of 'sampled', or how to set the parameters. The agent would need additional context to use the tool correctly.
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 provides no explanation of the parameters (urls, max_urls, site_url) and the input schema has 0% description coverage. The agent must infer parameter meaning from names alone, which is insufficient for correct invocation. The description does not compensate for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool runs 'auth-free, read-only sampled adjacent technical diagnostics for supplied URLs' and elaborates that it only performs property-scoped HTML and robots.txt fetches. It distinguishes itself from sibling tools by explicitly listing APIs it does not call (Search Console, Indexing API, etc.).
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 gives context on when to use it (for safe, read-only diagnostics without authentication) but does not explicitly state when not to use it or provide alternatives among siblings. The reference to 'auth-free' and 'read-only' implies appropriate use cases 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.
Behavior2/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 mentions batch and API limits but gives no details on rate limits, error handling, partial success, or failure behavior. For a batch operation, more behavioral context is needed.
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 a clear Args section. No extraneous words; every sentence provides value. 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.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the batch complexity and existence of an output schema, the description covers main points but misses rate limits, error handling, and input format specifics. It is adequate but could be more 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 coverage is 0%, so the description must compensate. It explains site_url with examples and domain property coverage, and urls as a list per line. This adds meaning beyond the schema, but lacks constraints like max URL count or format validation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool inspects multiple URLs in batch within API limits. The verb 'inspect' and resource 'multiple URLs' are specific, and the batch aspect distinguishes it from single-URL siblings like inspect_url_enhanced.
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 'within API limits' and explains domain property usage, but does not explicitly state when to use this tool versus alternatives (e.g., for bulk vs. single inspection). No exclusion criteria or when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose side effects, rate limits, or return structure. It only says 'check for specific indexing issues' without explaining what those are or the output.
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 a clear one-liner purpose followed by structured Args. No unnecessary 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's purpose and the existence of an output schema, the description provides basic parameter guidance but lacks details on return values, limitations, or what constitutes 'indexing issues'. It is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds value by explaining site_url in detail and noting that urls should be 'one per line'. However, with 0% schema description coverage, more could be said about parameter types or constraints.
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 'Check for specific indexing issues across multiple URLs', using a specific verb and resource. It distinguishes from sibling tools like batch_url_inspection and inspect_url_enhanced by focusing on indexing issues 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?
The Args section provides explicit guidance on site_url format and domain property usage, aiding correct invocation. However, it lacks when-not-to-use or alternative tool mentions.
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 must disclose behavioral traits. It does not mention that the operation is read-only, any rate limits, potential errors, or side effects. Although the name implies a read operation, without explicit disclosure the agent lacks important behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded. The first sentence states the purpose, followed by a structured 'Args' section. Every sentence adds value, with no redundancy or fluff. It is appropriately sized for the tool's complexity.
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 adequately covers the input parameters with usage context, especially site_url. Since an output schema exists, the lack of output explanation is acceptable. However, it does not address behavioral traits (e.g., read-only) or differentiate from sibling analytics tools, leaving minor gaps in overall completeness.
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 description coverage is 0%, so the description carries full burden. It adds significant value: site_url is explained with example formats and a note on domain properties and subdomain analysis; days is explained with default and meaning ('look back'). Both parameters are fully described beyond the 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 the action ('Get a performance overview') and the resource ('for a specific property'). The verb and resource are specific. While it does not explicitly distinguish from sibling tools like get_search_analytics, the name and context imply a high-level summary. However, lack of explicit differentiation prevents a 5.
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 practical guidance on using the site_url parameter (e.g., format, domain vs subdomain) and explains the days parameter. However, it does not specify when to use this tool versus alternatives, such as get_search_analytics or get_advanced_search_analytics. The guidance is helpful but insufficient for tool selection.
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 adds useful parameter context (e.g., site_url format, domain property note) but does not disclose side effects, auth requirements, rate limits, or what 'detailed information' includes. Adequate but not comprehensive.
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 main sentences plus parameter descriptions. Front-loaded with purpose, no fluff. Each sentence adds value. Could be slightly improved by explicitly stating enhanced nature up front, but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given sibling tools and output schema existence, the description covers parameters well and hints at enhanced detail but does not fully guide tool selection. Lacks comparison to get_sitemaps and does not mention what 'detailed information' includes. Adequate but with 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%, but the description provides excellent semantic information for both parameters. site_url includes format examples and domain property guidance; sitemap_index explicitly explains its purpose. This compensates fully for the 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?
The description clearly states the tool lists sitemaps for a specific GSC property with detailed information. The verb 'list' and resource 'sitemaps' are specific. It distinguishes from siblings by hinting at enhanced detail and optional child sitemap listing, but could explicitly contrast with get_sitemaps.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear usage context: requires site_url from list_properties, explains domain property behavior, and descriptions of sitemap_index. However, no explicit guidance on when to prefer this over get_sitemaps or manage_sitemaps, nor 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?
No annotations provided, so description carries full burden. It states read-only, no indexing, and 10-URL limit, but does not disclose authentication, rate limits, or whether it modifies state. Adequate but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no fluff. Front-loaded with key purpose and constraints. 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?
Covers overall purpose and behavioral traits, but misses parameter details critical for correct invocation. Output schema exists but is not shown; still, parameter guidance is insufficient for a 0% schema coverage tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and description only adds 'up to 10 URLs' as a constraint for 'urls'. Lacks format, examples, or explanation of 'site_url', leaving 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 it builds a read-only prioritized action queue from URL Inspection data, distinguishing it from indexing tools. It specifies the verb, resource, and scope (up to 10 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?
It explicitly says it does not request indexing, guiding when not to use it. It implies use for URL inspection and recommendations, but does not explicitly name alternatives like inspect_url_enhanced.
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 must fully disclose behavior. It notes the destructive action and URL format requirements, but lacks information on irreversibility, authentication needs, or post-deletion 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 concise and efficient, with the purpose front-loaded and parameter details following in a clean structure without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple deletion tool, the description covers the essential action and parameter. An output schema exists, so return values need not be described. Minor missing details like confirmation or error messages, but acceptable.
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 significant value by explaining the site_url parameter with exact match examples and domain property format, which is beyond the schema's type definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the specific action ('Remove a site') and resource ('from your Search Console properties'), clearly distinguishing it from sibling tools like add_site or delete_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 does not explicitly state when to use this tool versus alternatives. While the purpose is clear, there's no guidance on prerequisites or exclusions.
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 must carry the full burden. It does not disclose whether the operation is safe/read-only, authentication requirements, rate limits, or what 'detailed information' includes. The description only states the basic purpose and parameter hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: one sentence for purpose followed by clear parameter explanations. No fluff, well-structured, and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has a simple interface (2 required params, no nested objects, output schema exists), the description covers the parameter semantics adequately. It does not explain return values (but output schema exists) or prerequisites, but is sufficient for a straightforward retrieval operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description compensates well. It explains site_url format and domain property behavior, and clarifies sitemap_url as 'the full URL'. This adds significant meaning beyond the schema's bare parameter titles.
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: 'Get detailed information about a specific sitemap.' This is a specific verb+resource pair, and it differentiates from sibling tools like 'delete_sitemap' or 'list_sitemaps_enhanced'.
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 parameter guidance (e.g., site_url format, domain property coverage) but does not explicitly state when to use this tool versus alternatives like 'get_sitemaps' or 'list_sitemaps_enhanced'. The usage context is implied but lacks clear exclusions.
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, and the description does not disclose behavioral traits such as read-only status, potential side effects, or access requirements. The description carries the full burden but adds no transparency beyond the basic purpose.
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 a clear one-sentence purpose followed by structured parameter details. No extraneous information exists, and the Args section is well-organized.
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 parameter sufficiently and, given the existence of an output schema, need not detail return values. However, it could briefly summarize what 'detailed information' includes to better set expectations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description explains the site_url parameter in detail, including acceptable formats and a usage tip about domain properties. This adds significant value beyond the raw schema definition.
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: 'Get detailed information about a specific Search Console property.' This distinct verb+resource pattern differentiates it from sibling tools like list_properties and delete_site.
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 specific guidance on the site_url parameter, including format examples and a tip about using domain properties with filtering. However, it does not explicitly mention when to avoid this tool or suggest alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It explicitly states multiple behavioral traits: read-only, blocks unsafe/private targets, does not follow redirects, never calls Indexing API, never mutates Search Console. These are clear and accurate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, dense paragraph that is front-loaded with the key purpose. Every sentence adds value: it lists actions, constraints, and what it returns. No redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides good behavioral detail but lacks parameter explanations (site_url, urls, max_urls). Given that the input schema has no descriptions and 3 parameters, the description should clarify what each parameter represents. The output schema exists, so return values are covered.
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%, but the description does not explain the parameters (site_url, urls, max_urls). It only mentions 'fetches property-scoped URLs' which implies url is a list, but does not clarify format or meaning. The description fails to compensate 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 it's a read-only audit of JobPosting JSON-LD and a dry run for Indexing API eligibility. It specifies the scope (property-scoped URLs), actions (fetches, blocks unsafe, parses, validates), and output (eligible action). It is distinct from sibling tools like build_indexing_action_queue or inspect_url_enhanced, which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for auditing job posting schema and performing a dry run, but does not explicitly state when to use this tool versus alternatives (e.g., inspect_url_enhanced, build_indexing_action_queue). No exclusions or when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 discloses the tool inspects indexing status and rich results, but does not specify behavioral traits such as read-only nature, rate limits, or authentication needs. The output schema exists, which helps, but the description lacks explicit safety or side-effect disclosure.
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 and front-loaded with the purpose. The parameter details are structured clearly in Args. Every sentence adds value, though it could be slightly more structured (e.g., bullet points) for easier reading.
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 (so return values are documented), the description adequately covers the 3 parameters (2 required). It provides necessary context about site_url and subdomain handling, making it complete for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains the site_url format and usage in detail, including domain property coverage. The page_url is briefly described, and language_code is explained as optional IETF BCP-47. This adds significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool inspects a URL for indexing status and rich results. It uses a specific verb ('inspect') and resource ('URL') with a clear purpose ('check indexing status and rich results'), and distinguishes from sibling tools like batch_url_inspection and check_indexing_issues by being single-URL and enhanced.
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 detailed guidance on the site_url parameter, including the format and how to handle domain vs. subdomain properties. It also mentions the optional language_code parameter. However, it does not explicitly state when to use this tool vs. alternatives like batch_url_inspection, though the context is implied.
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 explains the site_url format and domain property coverage, but does not disclose whether submission is asynchronous, overwrites existing sitemaps, or has quotas.
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 plus parameter descriptions, front-loaded with purpose, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 2 required parameters and the presence of an output schema, the description adequately explains inputs. It could mention success/error behavior, but is largely complete for a submit action.
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%, but the description provides detailed explanations for both parameters, including examples and usage notes for site_url (e.g., domain properties covering subdomains) and a clear definition for sitemap_url.
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 verb 'Submit' and the resource 'sitemap to Google', distinguishing it from sibling tools like delete_sitemap or audit_sitemap_urls.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains what the tool does (submit/resubmit), but does not provide explicit guidance on when to use it vs alternatives like manage_sitemaps or audit_sitemap_urls.
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 behavioral disclosure. It covers data freshness (data_state), pagination (start_row, row_limit), filter logic (single vs multiple filter parameters), and domain property nuances. It does not mention rate limits, error handling, or performance, but key behaviors are 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 front-loaded with a clear purpose sentence and organized into a readable Args block. While slightly verbose for some parameter descriptions, the structure is clear and each parameter has its own line. Could be tightened without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (14 parameters, pagination, multiple filter modes) and the presence of an output schema, the description covers most essential usage context: defaults, allowed values, parameter interactions. It lacks error case handling or performance notes, but overall it enables effective use.
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 description coverage is 0%, so the description must compensate. It provides detailed explanations for all 14 parameters, including defaults, formats, allowed values, examples, and interactions (e.g., filters overrides filter_dimension/filter_operator/filter_expression). This adds significant meaning beyond the 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?
The description clearly states 'Get advanced search analytics data with sorting, filtering, and pagination.' It uses a specific verb and resource, and the term 'advanced' distinguishes it from sibling tool '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 provides detailed parameter guidance (e.g., site_url format, filter overrides, data_state options) but does not explicitly state when to use this tool versus alternatives like 'get_search_analytics' or other siblings. Usage is implied but not contrasted.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description explicitly states the tool is read-only, never calls Google APIs, never requires credentials, and never mutates Search Console. This fully discloses its behavioral traits, especially since annotations are absent.
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-sentence description is extremely concise, front-loaded with the primary purpose, and each sentence adds unique value. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose and behavior well, and an output schema exists (as per context signals) to detail return values. However, the lack of parameter explanation is a significant gap, making the tool's interface unclear for the 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?
Input schema has two parameters ('focus' with default 'weekly', 'site_url' with default '') with no schema descriptions. The description does not explain what these parameters do or how they affect the checklist, leaving the agent with no guidance despite 0% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool returns a stable read-only checklist for Search Console UI-only/manual surfaces. It specifies verb, resource, and distinguishes from sibling tools by noting it never calls Google APIs, requires no credentials, and never mutates Search Console.
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 context: when an operator needs a checklist for manual review surfaces. It does not explicitly state when not to use it or list alternatives, but the sibling tools (e.g., get_search_analytics) suggest when API-calling tools are more appropriate.
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 fully discloses that it deletes the current OAuth token and triggers a browser authentication flow. However, it does not mention potential side effects like requiring user interaction or loss of session state, which would enhance 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?
Three sentences, front-loaded with the core action, no wasted words. Every sentence adds value: what it does, how it does it, and when to use it.
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 with no parameters and an output schema exists. The description explains the purpose and usage, though it could mention that it might return a success/failure indication. Overall adequate for a straightforward auth tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema coverage is 100% (empty schema). According to guidelines, baseline is 4. The description adds no parameter info, which is appropriate as there are none.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Perform a logout and new login sequence'), specifies what it does (deletes OAuth token file and triggers browser authentication flow), and distinguishes it from siblings by focusing on authentication rather than GSC operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Useful when you need to switch to a different Google account,' providing a clear use case. It does not mention when not to use it or alternatives, but the context of sibling tools makes it clear this is for authentication.
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 implies a read operation but does not disclose permissions, rate limits, or output format. It adds useful format hints for the parameter but lacks broader behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences plus an Args section. The main purpose is front-loaded, and the parameter breakdown is well-structured with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and an output schema, the description covers the parameter usage and gives domain-specific guidance. It could mention that the output is a list of sitemap URLs/details, but the output schema exists and rules don't require describing it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter site_url is thoroughly explained: it must be an exact GSC property URL, with examples and a note about domain properties. This adds significant meaning beyond the bare schema (which has 0% description 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 'List all sitemaps for a specific Search Console property.' The verb 'list' and resource 'sitemaps' are specific, and it distinguishes from siblings like 'get_sitemap_details' and '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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides context that the site_url must be an exact GSC property URL from list_properties, and explains domain property behavior. However, it does not explicitly mention when not to use this tool or suggest 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 provided, so description must cover behavioral traits. It lists actions but doesn't disclose side effects (e.g., destructive nature of delete), authorization needs, or rate limits. Adequate but not comprehensive.
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: one sentence stating purpose, followed by clear parameter breakdown. No filler, 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?
Covers all parameters and action options adequately. Output schema exists but return values not described, which is acceptable. Missing some behavioral context for mutation actions, but overall complete for decision-making.
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%, but description explains all 4 parameters in detail: site_url format, action options, sitemap_url requirement, and sitemap_index usage. Adds significant value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool is for managing sitemaps with specific actions (list, get details, submit, delete). It differentiates from siblings like get_sitemaps and submit_sitemap by being a combined tool.
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 guidance on site_url format (exact GSC property URL, domain vs subdomain) and when sitemap_url is required. However, it doesn't explicitly compare with sibling tools like get_sitemaps or submit_sitemap to guide tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses safety measures (validation, DNS resolution, redirect disabling, byte capping) and confirms read-only behavior. Could mention error handling 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, with a clear purpose statement followed by safety notes and parameter explanations. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of an output schema, the description covers input and safety adequately. It could be more explicit about return data but likely covered by output schema.
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 description adds meaning to all three parameters beyond the schema, explaining site_url format, sitemap_url as full URL, and max_urls limit on samples. Schema coverage is 0%, so this is valuable; slight improvement could be format requirements for sitemap_url.
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 and parses XML sitemaps for read-only diagnostics, using specific verbs and distinguishing from sibling tools like submit_sitemap and delete_sitemap.
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 what the tool does not do (submit/delete sitemaps, call URL Inspection), providing context for when to use versus siblings. However, it could be more explicit about when to use this tool instead of other read tools like get_sitemaps.
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?
Despite no annotations, the description fully discloses all key behavioral traits: read-only, no Indexing API calls, no URL updates, no file writes, no mutation of Search Console.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, no extraneous verbiage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description adequately covers the tool's composition (schema audit + URL Inspection) and safe nature, making it complete for an agent to understand when and how to invoke.
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 has 0% description coverage and the tool description does not explain any parameters. Agent must infer meanings from parameter names alone; format of urls string is ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it builds a read-only JobPosting lifecycle action queue, and distinguishes from sibling tools like build_indexing_action_queue by explicitly noting it never calls the Indexing API.
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 describes when to use (for read-only queue building) and when not to use (not for actual indexing), and contrasts with sibling tools that may call the Indexing API.
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: returns tools grouped by category, auth status, and getting started info. Notes that it's a single call and faster than alternatives. No side effects 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?
Three concise sentences, each earning its place: purpose, usage guidance, and behavioral detail. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema, the description sufficiently explains what the tool returns. The simple purpose is well covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters, baseline 4. Description does not need to add parameter info beyond what schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a full list of tools, auth status, and getting started info. It explicitly distinguishes itself from sibling tools by positioning it as the first call for discovery.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit conditions for use: 'when asked what tools are available, what this server can do, or how to get started.' Also explains comparative advantage over searching individually. No explicit when-not-to-use, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It explains site_url format, default values, and constraints like row_limit max. Does not mention rate limits or authentication, but given context, sufficient.
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?
Well-structured with clear parameter explanations, but could be slightly more concise. Main purpose is front-loaded.
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 4 parameters and output schema exists, description covers all parameter semantics and provides cross-tool guidance. No gaps for agent decision-making.
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 description coverage is 0%, yet description fully explains all 4 parameters with examples, options, and usage advice (e.g., dimensions options, row_limit ranges). Adds significant value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Get search analytics data for a specific property' with specific verb and resource. Explicitly distinguishes from sibling get_advanced_search_analytics for bulk exports.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on when to use this tool vs. get_advanced_search_analytics for paginated bulk exports. Also advises on row_limit ranges for different use cases.
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 burden. It clearly implies a read operation (getting data) and explains parameters in detail, but it does not explicitly declare read-only behavior or mention permissions. For a simple search analytics retrieval, this is largely sufficient, though a note on non-destructiveness would be beneficial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is front-loaded with a clear purpose statement, followed by well-structured parameter explanations in bullet-like format. Each sentence is informative and necessary, with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters, an output schema (so return values are covered), and no annotations, the description covers all parameters with useful context. It could mention the output's scope (e.g., aggregated query data) but is largely complete for effective use.
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 description coverage is 0%, but the description fully compensates: for site_url it provides examples and domain property vs page filtering explanation; for row_limit it offers usage ranges and scenarios; for days it explains default and purpose; for page_url it clearly defines. This adds significant meaning beyond the 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?
Description explicitly states 'Get search analytics data for a specific page, broken down by query.' This clearly distinguishes it from sibling tools like get_search_analytics (broader) and get_advanced_search_analytics (paginated).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance: explains domain property usage for site_url, recommends filtering by page for subdomain analysis, and for row_limit gives usage scenarios and explicitly cites get_advanced_search_analytics for bulk exports beyond 500 rows. This is a clear when/when-not/alternatives pattern.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies a read-only operation by stating it lists properties, but no annotations are provided to confirm; it lacks explicit mention of side effects but is not misleading.
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 fluff, purpose first, and actionable guidance.
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 is complete for a parameterless list tool with an output schema; it covers purpose and when to use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so the baseline is 4. The description adds value by explaining what the tool returns (a list of properties) beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verbs ('list') and resources ('Google Search Console properties and sites') and distinguishes from siblings by recommending it as the first call to get site_url.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states 'Always call this first to get the exact site_url needed for other tools,' providing clear context for when to use it.
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/shutovdef-dotcom/google-search-console-mcp/badges/card.svg)](https://glama.ai/mcp/servers/shutovdef-dotcom/google-search-console-mcp)

Score Badge

Copy to your README.md:

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

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