Google Search Console MCP Intel Engine

Server Quality Checklist

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

Latest release: v0.10.1
Disambiguation5/5
Each tool targets a distinct resource or action: sites, dimensions, metrics, skills, sitemaps, analytics, and setup. The only similar pair is skills_list/skill_read but they are clearly list vs. fetch-content, matching the standard pattern. No meaningful overlap.
Naming Consistency4/5
Most tools follow a clear verb_noun snake_case pattern (list_, get_, submit_, delete_, setup_). However, skills_list and skill_read invert the convention to noun_verb, which is a minor but noticeable deviation from the dominant pattern.
Tool Count5/5
Ten tools is well-scoped for a GSC integration, covering metadata discovery, sitemap management, analytics retrieval, skills/playbooks, and setup. Each tool has a clear role without redundancy or bloat.
Completeness4/5
The surface covers core GSC workflows: listing sites, querying analytics, managing sitemaps, and enumerating dimensions/metrics. Minor gaps exist, such as no direct URL inspection tool or ability to fetch a single site's details, but these can be worked around with existing tools.
Average 4.1/5 across 10 of 10 tools scored. Lowest: 3.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 19 commits in the last 12 weeks
- Last stable release on August 10, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate idempotentHint=true and destructiveHint=false, which the description does not contradict. However, the description adds little beyond a trivial 'Success message or error details' return statement, and it does not disclose any additional behavioral context such as asynchronous processing or submission 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?
The description is extremely concise, with clear labels for Args and Returns. Every sentence serves a purpose, and there is no redundant fluff or repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool, the description covers the basics: action, parameter, and return type. However, it lacks important contextual information such as the need for Google Search Console access setup, potential side effects, or relationship to sibling tools, making it incomplete for a fully-informed invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description states 'sitemap_url: Full URL of the sitemap to submit', which adds the meaning that the URL must be a full (absolute) URL, partially clarifying the schema's generic 'string' type. However, the signal indicates zero schema description coverage, and the description does not mention constraints like valid formats or allowed protocols, so it does not fully compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Submit a sitemap to Google Search Console'. This clearly distinguishes it from sibling tools like get_sitemaps and delete_sitemap, which have different actions on the same resource.
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, nor does it mention any prerequisites such as needing setup_gsc_access or verifying site ownership. It is a bare description with no contextual usage suggestions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and readOnlyHint=false, so the agent knows this is a destructive operation. The description adds that it returns a success message or error details, but does not disclose irreversibility, side effects, or idempotency nuances beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and well-structured: a clear one-line purpose, an Args section explaining the parameter, and a Returns section. Every sentence earns its place 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 single-parameter tool with destructive annotations and no output schema, the description covers the action, argument, and return format. It does not mention prerequisites (e.g., GSC access setup) or side effects, but the annotations and sibling tools provide enough context for this low-complexity 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 schema only specifies sitemap_url as a required string with 0% description coverage. The description compensates by explaining it as 'Full URL of the sitemap to delete', which adds meaningful semantics the schema lacks.
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 'Delete a sitemap from Google Search Console' with a specific verb and resource, clearly distinguishing it from sibling tools like get_sitemaps and submit_sitemap. The action is unambiguous and directly reflects the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided about when to use this tool versus alternatives. The sibling list (e.g., get_sitemaps, submit_sitemap) implies its role in the sitemap lifecycle, but the description does not name when to prefer this tool or exclude other 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?
Annotations already declare readOnlyHint=true, openWorldHint=false, and idempotentHint=true, which cover the safety profile. The description adds the return format (list of objects with api_name and description), which is useful. It does not contradict annotations, but it does not disclose additional behavioral traits such as ordering, data source, or pagination. Given the simple nature and strong annotations, this is adequate but not exceptional.
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 that state the purpose and the return format. There is no filler or redundant content. Every word adds value, making it highly efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is simple with no parameters, has robust annotations, and the description explains the return format, it is nearly complete for its purpose. It could optionally mention that 'GSC' means 'Google Search Console' or provide an example, but these are minor gaps. Overall, the description provides sufficient context for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema is empty with 100% coverage. Since there are no parameters to clarify, the description does not need to add parameter semantics. The baseline for 0 parameters is 4, and the description provides no misinformation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'List all available GSC dimensions with their descriptions.' The verb 'List' is specific, the resource 'GSC dimensions' is precise, and it inherently distinguishes from sibling tools like 'list_available_metrics' (metrics versus dimensions) and 'list_gsc_sites' (sites versus dimensions).
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 by clearly stating the tool lists dimensions, which is distinct from the sibling tools focused on metrics or sites. However, it does not explicitly provide guidance on when to use this tool versus alternatives, nor does it mention any exclusions or prerequisites. The usage context is implied rather than explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, open-world, and idempotent hints. The description adds useful context: summary_only token efficiency, start_row pagination, and return metric names. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-organized with a one-sentence purpose, an Args list, and a Returns line. All sentences provide unique value; 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?
Despite 9 optional parameters, the description covers all key behaviors: pagination, token-efficient summary, date formats, and return metrics. With an output schema present, return details need not be exhaustive. Could mention filter operators or dimension combinations, but not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description carries full burden. It thoroughly explains all 9 parameters with types, examples, defaults, and max rows, going beyond the schema. The intent parameter is clarified with a plain-English example.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Retrieve') and resource ('Google Search Console search analytics data'), clearly differentiating from siblings like list_gsc_sites and list_available_dimensions.
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 vs alternatives like list_gsc_sites or list_available_dimensions. It implies analytics retrieval but doesn't state exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, covering safety. The description adds that it returns a list with status and details, which is useful context. However, it does not disclose any rate limits, pagination, or specifics about the configured site, so transparency 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 extremely concise: a single purpose sentence followed by a brief return statement. Every word earns its place, and the structure is front-loaded with the action and resource. No unnecessary 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?
Given the tool's simplicity (no parameters, no output schema) and strong annotations, the description is complete. It states what it returns ('List of sitemaps with their status and details') and clarifies the scope ('configured site'). This is sufficient for an agent to invoke and interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the baseline is 4. The description adds meaning by stating 'for the configured site,' which implies no parameters are needed because the scope is predefined. This helps agents understand why the tool requires no arguments.
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+resource: 'Get all sitemaps for the configured site.' This clearly states what the tool does and distinguishes it from siblings like submit_sitemap and delete_sitemap, which perform different actions. The 'Returns' line adds clarity about the output.
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 (you use this when you need to retrieve sitemaps) but does not explicitly state when to use it versus alternatives. It does not mention related tools or conditional guidance, so it relies on the inherent clarity of the name and context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the description adds only the return format ('List of verified sites with their permission levels'). This is minimal additional context, not covering auth needs or side effects, but sufficient given annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded, with two short sentences providing purpose and return value. No waste or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only list operation, the description is fully complete. It states what it does and what it returns, and the annotations cover safety and idempotency. No output schema is needed for such a simple 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, so the baseline is 4. The description correctly focuses on the operation and return value, needing no parameter explanations.
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 sites verified in Google Search Console' with a specific verb and resource. It distinguishes from sibling tools like get_sitemaps or get_search_analytics which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the tool's name and description, but there is no explicit guidance on when to use it versus alternatives. For a simple list operation with no prerequisites, the absence of exclusions is acceptable, but it falls short of clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint and idempotentHint, and the description does not contradict them. However, the description adds minimal behavioral context beyond the fact that it lists items; no additional details such as return format, rate limits, or scope limitations are provided. For a simple list operation, this is acceptable but not exceptional.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of three short, front-loaded sentences that first state the primary action, then explain the use case, and finally suggest the next step with skill_read. Every sentence earns its place; no unnecessary details or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, no output schema, and a simple purpose, the description sufficiently explains what the tool does and how to proceed after listing. It covers the essential context for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description is not expected to explain any parameter syntax or semantics. Baseline of 4 for 0 params 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 uses a specific verb ('List') and a specific resource ('available analytical skills (playbooks) for Google Search Console'). It is clearly distinct from sibling tools like list_available_dimensions or list_available_metrics, and from skill_read which fetches a full playbook.
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 clearly states when to use the tool ('Use this to learn proven field combinations and how to interpret GSC data for specific SEO tasks') and points to an alternative for the next step ('Fetch the full playbook with skill_read'). It does not explicitly state when not to use it, but the guidance is clear enough for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare the safety profile (not read-only, idempotent, non-destructive). The description adds valuable behavioral context: it is interactive (asks the user for needed value through the client) and re-initializes without a restart. This goes beyond annotations and sets clear expectations for side effects and process.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose ('Interactively fix a broken Google Search Console MCP setup') and immediately followed by concrete examples. Every sentence earns its place with no waste.
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 zero-parameter, interactive setup tool with no output schema, the description covers what it does, how it operates (asking the user), and when to call it. While it does not describe expected return values or post-fix confirmation, the simplicity and interactive nature make the description sufficient for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 shows an empty object. The baseline for zero-parameter tools is 4, as there is no parameter information to explain. The description does not need to compensate for missing parameter docs.
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 verb ('fix') and resource ('Google Search Console MCP setup') and enumerates specific failure modes (missing credentials path, wrong GSC_SITE_URL, invalid key, missing property access). This distinguishes it from sibling tools like list_gsc_sites or get_sitemaps, which are read-only data tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use guidance: 'Call this whenever a configuration or authentication error is reported.' While it does not explicitly mention when not to use or name alternatives, the context is clear and no sibling tool serves a similar purpose, providing sufficient guidance for an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is established. The description adds transparent return-structure information ('List of metric objects with api_name and description'), which is useful beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise—two short sentences. It front-loads the core purpose and then provides a brief return structure, with no filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read-only listing tool, the description is complete. It states what the tool does, the return format, and with annotations covering safety, no other context is needed.
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 baseline is 4. The description correctly notes no inputs are needed, and there is no parameter ambiguity to resolve.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all available GSC metrics with descriptions, using a specific verb ('List') and resource ('GSC metrics'). It distinguishes itself from the sibling tool list_available_dimensions by explicitly focusing on metrics rather than dimensions.
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 makes the usage context clear: use this tool when you need to enumerate all available metrics and their descriptions. It doesn't explicitly mention alternatives or exclusion cases, but the scope is well-defined enough for an agent to discern when to invoke it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With annotations already declaring readOnlyHint and idempotentHint, the safety profile is covered. The description adds value by explicitly stating the return structure ('title, description, and playbook steps'), which is not present in the annotations. It also clarifies the dependency on skills_list for ID sourcing, adding behavioral context beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise and well-structured, with a brief introductory sentence followed by clear Args and Returns sections. Every sentence earns its place, including the example. There is no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with one parameter and no output schema, the description is complete. It covers the purpose, parameter semantics, and return value structure. The reference to skills_list provides necessary context for the expected workflow. Given the low complexity, nothing further is needed.
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 no description for skill_id, but the description's Args section compensates well by explaining it as 'The skill id from skills_list' and providing an example ('brand_visibility.md'). This gives the agent concrete guidance on where to obtain the value and its expected format, significantly exceeding the schema's bare 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 clearly states 'Fetch the full content of one analytical skill (playbook)' with a specific verb and resource. It distinguishes itself from sibling tools like skills_list (which presumably lists skills) by focusing on fetching a single skill's full content. The phrase 'one analytical skill' also clarifies the singular scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context by instructing the agent to get the skill_id from skills_list and gives an example ID. It also implies the appropriate workflow (list first, then read). However, it does not explicitly mention when not to use this tool or name alternatives, so it falls just short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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/surendranb/google-search-console-mcp/badges/card.svg)](https://glama.ai/mcp/servers/surendranb/google-search-console-mcp)

Score Badge

Copy to your README.md:

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

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