GSC MCP Server

by wyattxmgmt

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool targets a distinct resource and action: site listing, sitemap lifecycle (list/get/submit/delete), URL inspection, and search analytics querying. No overlap; get_sitemap vs list_sitemaps is clearly singular vs plural.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern: list_sites, get_sitemap, submit_sitemap, delete_sitemap, inspect_url, query_search_analytics, list_sitemaps. The style is uniform and predictable.
Tool Count5/5
7 tools is well-scoped for a Google Search Console server, covering the core resources (sites, sitemaps, URLs, analytics) without bloat. Each tool earns its place.
Completeness4/5
The sitemap lifecycle is complete (list, get, submit, delete), and URL inspection plus search analytics cover major GSC functions. A minor gap is the lack of a dedicated tool to get detailed property info beyond listing, but this is workable.
Average 3.8/5 across 7 of 7 tools scored. Lowest: 3.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 4 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does not mention prerequisites (e.g., property must exist), idempotency, side effects (e.g., overwriting or adding a new entry), or any return value. The description essentially restates the tool's name with minimal added 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?
A single, clear sentence that front-loads the action and resource. No wasted words or redundant 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?
For a simple action tool with no annotations and no output schema, the description should at least hint at expected behavior or usage context. It lacks guidance on when to use it and what happens after submission, leaving gaps that the schema cannot fill.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents both parameters (siteUrl and feedpath). The description adds no additional parameter semantics, but the schema already provides sufficient detail, meriting the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Submit') and resource ('sitemap to Google Search Console for a property'), clearly distinguishing it from sibling tools like get_sitemap, delete_sitemap, and list_sitemaps.
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. It doesn't mention that this is for adding a sitemap, or when not to use it (e.g., for updating existing sitemaps). The existence of sitemap-related siblings makes this absence notable.
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 present, so the description must carry full behavioral disclosure. 'Remove' implies a destructive action, but the description does not state whether the action is irreversible, whether special permissions are required, or what happens if the sitemap does not exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no redundant or irrelevant information. Every word contributes to the meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete operation with two well-specified parameters, the description covers the core action. However, with no annotations, it could benefit from noting permanence or side effects, though it remains minimally viable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both siteUrl and feedpath clearly documented. The description adds no additional meaning beyond the schema, providing no further guidance on syntax or format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Remove') on a specific resource ('sitemap') within a clear context ('Google Search Console for a property'). It clearly distinguishes from sibling tools like submit_sitemap and list_sitemaps by focusing on deletion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies usage when a sitemap needs to be removed from a property. It provides clear context but does not explicitly state alternatives or when not to use it, nor mention prerequisites like the sitemap having been previously submitted.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It explicitly says 'get', indicating a read operation, which is a basic behavioral trait. However, it does not disclose error handling, prerequisites, or return format, leaving some gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that directly states the tool's function. No unnecessary words or repetition of the tool name; it earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, no annotations, and the description does not explain what 'details and status' specifically include. It also lacks behavior context like what happens if the sitemap does not exist. Given the vague wording, the description is insufficient for a fully informed agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for both parameters (siteUrl and feedpath), each with clear definitions. The description adds no extra parameter semantics, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets details and status for a single sitemap, using the specific verb 'get' and resource 'single sitemap'. This differentiates it from sibling tools like list_sitemaps (plural) 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?
The description conveys that this is for a single sitemap, implying you should know the specific sitemap URL. While it does not explicitly mention alternatives like list_sitemaps, the context is clear enough that an agent would know when to use this tool versus listing all sitemaps.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavior. It correctly indicates a read-only listing operation and notes that only submitted sitemaps are included, but it does not mention return format, pagination, permissions, or side effects. The coverage is adequate for a simple list tool but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant words. Every word contributes to the meaning, making it appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (one parameter, no output schema, no annotations), the description sufficiently covers the core purpose. It could be more complete by mentioning the return type or that it only returns submitted sitemaps, but for a straightforward list operation, it is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (siteUrl is well-described as 'The property URL as registered in Search Console'). The tool description adds no additional meaning beyond the schema's parameter explanation, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List all sitemaps') and the scope ('for a Search Console property'). It distinguishes from sibling tools like get_sitemap (singular) and submit/delete sitemap by emphasizing it lists all submitted 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?
The description implies usage for viewing all submitted sitemaps but does not explicitly mention when to use this tool versus alternatives such as get_sitemap. No exclusions or alternative tools are referenced, leaving usage guidance mostly implicit.
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 queries performance data broken down by dimensions, but does not mention pagination behavior, data limits, authorization requirements, or response format. The schema adds some behavioral details, but the description itself is thin.
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, front-loaded sentence efficiently conveys the tool's purpose and key capabilities with no filler or repetition. It is appropriately sized for a query tool with a rich schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having 8 parameters and no output schema, the schema is very thorough, covering each parameter's meaning. The description is adequate for a read-oriented analytics query, but it does not mention return value shape or edge cases, which would have made it more 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 schema has 100% coverage of parameters with descriptions, so the baseline is 3. The description adds little beyond restating the dimensions concept already present in the schema, mostly echoing 'query, page, country, device, or date' without providing additional semantic meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool queries Google Search Console performance data with specific metrics (clicks, impressions, CTR, position) and dimensions, distinguishing it from sibling tools that manage sites, sitemaps, or inspect URLs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for performance data but does not explicitly state when to use this tool over alternatives, nor does it mention any exclusion conditions. Siblings are distinct enough that confusion is unlikely, but no direct 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 burden. It discloses the types of checks performed (indexing, coverage, mobile usability) and implies a read-only inspection, but lacks details on response format, potential errors, authentication, or rate limits. This is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the action and purpose, with no wasted words. It efficiently communicates the core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description lists the key inspection categories (indexing status, coverage issues, mobile usability, and more), which is sufficient for an agent to understand the tool's breadth. It could be more explicit about return data, but the tool's scope is moderate and the description is adequately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all three parameters (siteUrl, languageCode, inspectionUrl). The description adds little beyond stating 'single URL,' so it meets the baseline but does not enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Run the Search Console URL Inspection tool' and clearly identifies the resource (a single URL) and the purpose (check indexing status, coverage issues, mobile usability). It effectively distinguishes itself from sibling tools that deal with sitemaps and analytics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for inspecting a single URL, which is clear given sibling tools focus on different tasks (sitemaps, analytics, site listing). However, it does not explicitly state when not to use it or mention alternatives, so it stops short of full guidelines.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It indicates a read-only operation by saying 'List' and 'has access to', but it does not mention rate limits, pagination, or output format. This is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that conveys all essential information without redundancy or extraneous detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple parameterless list operation with no output schema, the description fully covers what the tool does. The output is implied to be the list of sites, and the lack of parameters simplifies the context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so baseline is 4. The description correctly adds no parameter-specific semantics since there are none to explain.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' with a clear resource 'sites/properties' and scope 'the authenticated account has access to'. It clearly distinguishes from sibling tools like list_sitemaps, which lists sitemaps rather than properties.
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 this tool is the way to retrieve accessible Search Console properties, but it does not explicitly state when to use it over alternatives or mention exclusions. Usage context is inferred rather than directly guided.
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-server MCP server](https://glama.ai/mcp/servers/wyattxmgmt/google-search-console-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/wyattxmgmt/google-search-console-mcp-server)

Score Badge

Copy to your README.md:

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

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/wyattxmgmt/google-search-console-mcp-server'

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