Google Search Console MCP Server

Server Quality Checklist

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

Latest release: v0.1.2
Disambiguation4/5
Each tool has a clearly defined primary purpose, and the descriptions are thorough in distinguishing them. However, a few pairs (gsc_check_status vs gsc_find_unindexed, gsc_request_indexing vs gsc_start_indexing_job) operate in the same domain and could be confused without careful reading.
Naming Consistency3/5
All tools share the gsc_ prefix and snake_case, which provides a consistent feel, but the structural pattern is mixed. Most use verb_noun (list_sites, check_status, submit_sitemaps), while several are plain nouns (doctor, quota, performance, setup, audit) or noun_noun (job_status). This is readable but not fully consistent.
Tool Count4/5
At 15 tools, the server is on the higher end of the ideal range, but the broad domain of Search Console management justifies it. Each tool covers a distinct aspect (setup, properties, inspection, analytics, quota, sitemaps, indexing jobs), and none feel redundant or unnecessary.
Completeness4/5
The tool set covers the core Search Console workflows: setup, property listing, index status inspection, performance analytics, quota estimation, sitemap submission, and indexing jobs. Minor gaps exist, such as no standalone tool to list or remove sitemaps and no property creation/removal, but agents can work around these limitations.
Average 4.6/5 across 15 of 15 tools scored. Lowest: 3.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 199 commits in the last 12 weeks
- Last stable release on August 8, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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

Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description takes on full responsibility for behavioral disclosure. It does this admirably by enumerating all possible states, explaining the meaning of `results` and `live`, detailing `stop_reason` values, and even covering the edge case of a run refused at the gate with empty `results` and `error`. This is rich, exact, and goes far beyond what a simple status check would imply.
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 but packed with useful information: a clear opening statement, a list of states, definitions of key fields, and an edge case explanation. Each sentence contributes meaning, and the structure is logical. It is not overly verbose, though the density of terms might require careful 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 lack of an output schema, the description explains the meaningful return fields (`results`, `live`, `stop_reason`) and provides context on how to interpret them. It covers common states and the special case of a gated run. However, it does not describe error handling, timeouts, or how to distinguish between a yet-to-start job and a failed one, leaving some gaps for a complete operational picture.
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 one optional parameter `job_id` with default null, but the schema description coverage is 0%. The description compensates partially by stating that the tool returns progress for 'one submission job, or the most recent one', implying that omitting job_id selects the most recent. However, it never explicitly names `job_id` or explains the parameter's format or null behavior, leaving ambiguity for the agent.
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's purpose: 'Progress and state for one submission job, or the most recent one.' It names the resource and the kind of information returned (progress, state), making it easy to understand. However, it does not explicitly differentiate itself from similar sibling tools like gsc_check_status, which could also be interpreted as a status check.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage context is implied: you use this tool to inspect the progress or state of a submission job. It does not provide explicit 'when to use' or 'when not to use' guidance, nor does it mention alternatives like gsc_check_status. The presence of optional job_id suggests checking a specific job or the most recent, but no explicit conditions are stated.
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 carries the full burden. It discloses the asynchronous return immediately, the response shape, the concurrency limitation (second job refused), and the underlying browser-tab mechanism. These are significant behavioral traits 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 three compact sentences, each adding distinct value: what it does, what to do after, and a key limitation. It is front-loaded and free of redundant wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with no output schema, the description covers the essential operational context: return behavior, follow-up actions, and concurrency policy. It could mention prerequisites (e.g., browser setup) or error scenarios, but given the simplicity, it is quite complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only names the 'urls' parameter as an array of strings, and the description adds only 'any number' — a minor clarification. It does not explain URL format, length limits, or any constraints, leaving the parameter semantics largely underspecified.
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 (queue a background submission run) and the resource (URLs). It distinguishes itself from sibling tools like gsc_request_indexing (single submission) and gsc_job_status (polling) by emphasizing the background, batch nature.
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 related tools for tracking and stopping (gsc_job_status, gsc_stop_job), and notes the one-at-a-time concurrency constraint. However, it does not explicitly say when to use this tool versus alternatives like gsc_request_indexing, nor does it mention prerequisites or exclusions.
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 the full burden and does an excellent job. It discloses a non-obvious and important behavioral trait: the stop happens after the URL currently in flight, not mid-URL, and explains the rationale (quota slot and ledger row must settle). This is exactly the kind of side-effect transparency an agent needs.
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. The first sentence front-loads the primary purpose, and the second adds an essential caveat. Every word earns its place, making it an ideal concise description.
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 with no output schema, the description covers the core behavior and its rationale well. It could be more complete by mentioning edge cases (e.g., what happens if the job is already stopped, or what the return value is), but it is sufficient for typical use and provides the most critical contextual detail (the no-mid-URL guarantee).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter, job_id, with 0% description coverage. The description does not add specific meaning to job_id (e.g., where to obtain it, format, or that it comes from a start-job call). It only refers generically to 'a running submission job,' leaving the agent to infer the job_id's role from the schema property name alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Ask a running submission job to stop.' It uses a specific verb ('stop') and resource ('running submission job'), and it distinguishes itself from sibling tools like gsc_start_indexing_job and gsc_job_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when a submission job is running and needs stopping) and provides a critical context clue by explaining the stopping behavior ('never mid-URL'). However, it does not explicitly mention alternative tools or when not to use it, so it stops short of full exclusionary guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full transparency burden. It thoroughly discloses behavioral traits: no network call, no quota usage, point-in-time snapshot, no movement numbers due to no status history, and explains how to interpret zeros (absence of data). It also reveals the `basis` field and the meaning of `stale`.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with the most critical information, but it is somewhat verbose. Each sentence conveys relevant detail, yet some redundancy exists (e.g., repeating local-only nature). Overall, it is appropriately sized for the complexity and manages to stay organized.
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 tool with one parameter and no output schema, the description is remarkably complete. It explains all return fields, edge cases (e.g., null indexed_pct when nothing checked), the meaning of action counts, and how to interpret the data. It also situates the tool among siblings for stale-vs-fresh scenarios.
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 refers to 'one property' and implies the `site` parameter is that property identifier, but it does not explicitly describe the parameter's format, allowed values, or how to obtain it. With schema description coverage at 0%, the description should compensate more, but it adds only minimal meaning beyond the schema's title.
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 identifies the tool's function: reporting the current indexation position for one property from the local store. It uses specific verbs and resource scope, and distinguishes itself from sibling tools by explicitly naming gsc_find_unindexed as an alternative for stale data.
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?
The description provides explicit usage guidance: it states this is a local read-only operation with no quota cost, and instructs to run gsc_find_unindexed first if the picture is stale. It also cautions about the correct interpretation of 'submittable' and urges reading each row's 'action' before spending quota slots.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses local-only operation, no network/quota/token usage, no filesystem paths returned, privacy guarantees about email addresses, and the exact meaning of tri-state flags (has_extension, matches_authorised_account). It also explains error states. This exceeds typical expectations.
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 long but front-loaded with a one-sentence summary and purpose. Each paragraph adds essential caveats (privacy, tri-state semantics, edge cases). While not terse, every section is necessary given the tool's complexity, so it earns its length without being bloated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description must document the return structure, and it does so exhaustively: the flat list format, each field's meaning, tri-state behavior, empty-list case, and error format. It also explains the 'recommended' field and reasons. This makes the description fully self-contained.
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 there are no parameter semantics to explain. Per the rubric, a baseline of 4 is appropriate because there is nothing to add; the description focuses on output semantics instead.
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 opening sentence 'List the Chromium browser profiles on this machine and recommend one' clearly states the action and scope. It also explicitly distinguishes itself by saying 'Answers "which browser profile should I drive?", nothing else', setting it apart from sibling tools like gsc_use_browser.
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 states when it is safe to call ('safe to call before signing in') and defines its boundary relative to other tools ('opens no browser and changes no setting'). It does not explicitly name alternative tools, but the context signals (sibling gsc_use_browser) make the guidance clear.
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 the full burden and excels. It discloses that numbers are an estimate, biased as lower/upper bounds, explains that `used` is a lower bound and `free` an upper bound, and details the origin of `last_refusal_at` as the only figure from Google. It also explains the difference between `free` and `spendable_free` and the reserve-adjusted arithmetic, providing deep behavioral insight beyond a simple 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 long but well-structured, using clear section breaks and a logical flow from overall purpose to local-only nature to detailed field semantics. It is front-loaded with the key caveat ('THESE NUMBERS ARE AN ESTIMATE') early on. While every sentence is informative, the length is considerable; it could be trimmed without losing critical information, but the complexity of the quota semantics justifies most of the 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 complexity and the presence of an output schema, the description is thoroughly complete. It covers return values for all scenarios (empty store, per-property entries, `free` vs `spendable_free`), explains edge cases like `bounding` being 'refused' or `None`, and clarifies relationships to sibling tools like gsc_list_sites. The description ensures an agent can correctly interpret and act on the results, even without additional documentation.
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 there is nothing to document. The description goes beyond by explaining the output structure in detail (e.g., `submission`, `inspection`, `binding` blocks and their sub-fields). Since there are no parameters, a baseline of 4 is appropriate; the description adds significant semantic value to the tool's output, even if not to parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Report Request-Indexing and URL Inspection budget for every property the store currently knows about.' It identifies a specific verb ('Report') and resource ('budget'), and distinguishes itself by emphasizing it is local-only and makes no Search Console API call, which separates it from siblings like gsc_check_status.
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 explicit usage context: 'safe to call at any time, including before signing in' and clarifies that an empty store (nothing synced via gsc_list_sites or gsc_check_status) returns []. It also advises against telling users 'you have N submissions left' without the estimate caveat, effectively providing when-to-use and when-to-caution guidance. It lacks an explicit statement of when *not* to use this tool in favor of an alternative, 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it excels: it reveals that error messages are deliberately omitted for security, that all checks run even if one fails, that 'could not be checked' is distinct from 'not installed', and that at most one API call is made. It also discloses the exact return contract.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with a one-sentence purpose, then organized into focused paragraphs covering checks, security, order rationale, cost, and return value. Every sentence adds substantive detail without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and the absence of an output schema, the description is remarkably complete. It explains the seven checks, failure handling, security constraints, fix strings, local vs API costs, ordering rationale, and the exact return shape — leaving little ambiguity for an agent.
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 input schema has 100% coverage by being empty. Per the baseline rule for parameterless tools, this scores 4; the description adds no parameter-specific meaning because none is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Diagnose whether gsc-mcp is set up to talk to Search Console.' It further clarifies the tool's scope by listing the seven checks, clearly distinguishing it from sibling tools like gsc_setup or gsc_check_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear context for when to use the tool — to verify setup health — and explicitly states it only diagnoses, not repairs. However, it does not name specific alternatives or state when not to use it, stopping short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavioral traits: the non-standard default of data_state='all', the 3-day lag warning for 'final', the exact error response formats (auth_required, not_configured, and generic failure with start/end/note), and the refusal of incomplete date ranges. This goes well beyond basic expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but well-structured with a clear summary, bulleted shapes, separate sections for date windows, data_state, and error handling. Each sentence adds necessary operational detail, and the organization aids quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no output schema or annotations, the description covers input modes, output shapes, date logic, data_state semantics, and error handling, making it highly complete for the tool's complexity. The only minor gaps are limit and search_type, but these do not undermine overall completeness.
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?
Given 0% schema description coverage, the description explains most parameters (site, dim, start_date, end_date, days, data_state) in detail, including valid dim values and date defaults. However, 'limit' and 'search_type' are not described, leaving their behavior 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 identifies the tool as retrieving Search Analytics performance metrics (clicks, impressions, CTR, position) and details three output shapes based on parameters. This makes it distinct from sibling tools like gsc_list_sites (site listing) and gsc_quota (quota checks).
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 usage guidance for parameter combinations (e.g., no site → portfolio aggregate, site+dim → per-dimension rows) and date window behavior, including the refusal of start_date without end_date. It does not explicitly contrast with sibling tools or state when not to use this tool, but the context is clear enough to select it appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so admirably. It discloses the BLOCKING nature, pacing (130-180 seconds), quota per property (roughly eleven slots), early-stop on throttle/captcha/signed-out, and details the return structure including error format. This goes well beyond a simple tool summary.
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 compact yet information-dense. Every sentence adds distinct value: purpose, pacing, alternative tool, quota, call order, return shape, early-stop condition, and error shape. It is structured logically, front-loading the core purpose and moving to caveats and outputs.
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 no output schema, the description compensates by clearly listing the return keys and explaining the early-stop behavior and refusal format. It also covers operational context (quota, pacing, browser profile) that integrates well with sibling tools like gsc_quota and gsc_start_indexing_job. This is a fully specified tool from the agent's perspective.
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 0% coverage—the description doesn't explain the format of each URL string. However, it does add a meaningful constraint: 'up to five URLs' and the behavioral nuance 'one at a time.' For a single, self-evident parameter named 'urls' this is adequate, but it leaves room for more detail (e.g., URL validation, required protocol).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb-resource pair: 'Submit up to five URLs to Google's Request Indexing.' It further clarifies the method ('through the browser extension in your own signed-in profile') and even distinguishes itself from a sibling tool ('Use gsc_start_indexing_job for anything larger'). This fully clarifies the tool's purpose and scope.
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?
The description explicitly states when to use this tool vs. the alternative ('Use gsc_start_indexing_job for anything larger') and provides a critical prerequisite ('Call gsc_quota first to see what is spendable; act on spendable_free, not free'). It also implicitly warns about blocking/slowness, setting user expectations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It thoroughly discloses idempotency, safety, that it spends no Search Console indexing quota, makes at most one API call, re-reports entire state, returns the same URL for pending consent, never raises, and gives privacy guarantees. This goes beyond basic expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is lengthy but every sentence serves a purpose: usage pattern, idempotency, step enumeration, return format, parameter semantics, privacy, and error behavior. It is well-structured with clear paragraphs and no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema, the description fully explains the return object structure, including ok, done, pending, next, and the meaning of null next. It also covers edge cases like unexpected faults. All necessary behavioral and operational details are present for the agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only lists open_browser as a boolean with a default, with 0% description coverage. The description fully compensates by explaining exactly what open_browser does: opens the consent URL when a new consent starts, and that a repeat call while pending returns the same URL and opens nothing. This adds critical 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 'Set this server up, one step at a time' and enumerates the four specific steps (oauth_client, consent, browser, extension), distinguishing it from sibling tools that handle jobs, status, performance, etc. The resource and action are specific.
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 iterative usage guidance: 'Call it, do what it says, call it again — repeat until ok is true' and explains that if you lose track, just call again. It also covers open_browser behavior on repeat calls. However, it does not explicitly mention when not to use it or contrast with alternative tools.
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 carries the full burden and does so outstandingly. It discloses idempotency, host-matching routing, persistence behavior, the refusal-to-guess safeguard, return shapes, and all auth/error handling (auth_required, not_configured, unexpected). No behavioral blind spots remain.
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 lengthy but every sentence earns its place. It is front-loaded with the core action, then organizes complex behavioral details into logical sections covering parameter use, refusal behavior, return shape, and error handling. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the tool's complexity and the presence of an output schema, the description fully specifies input semantics, expected return entries, persistence side effects, and every failure mode. It is complete enough for an agent to invoke the tool correctly and interpret results without additional context.
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 input schema only defines an optional nullable 'sitemaps' array with no description. The description compensates fully by explaining that it is a list of sitemap URLs routed via host-matching, that omitting it resubmits all recorded sitemaps, and that if no sitemaps are known it will return a specific error rather than guessing. This adds substantial 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 opens with a specific action: 'Submit one or more sitemaps to Search Console (PUT, idempotent -- safe to resubmit an already-known sitemap).' It clearly identifies the verb, resource, and core operation, and distinguishes itself from siblings like gsc_list_sites and gsc_check_status, which are about listing or checking status rather than submitting.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context on when to use the tool and how to use the optional 'sitemaps' parameter: omit it to resubmit every sitemap already on record, or provide a list to target specific sitemaps. It also explains the refusal-to-guess behavior when no sitemaps are known. However, it does not explicitly name sibling tools or state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It extensively discloses behavioral traits: read-only nature, that it spends URL Inspection quota with specific limits, the concurrency default, automatic local-store sync, exact return format including stale quota field semantics, the meaning of 'unverified' status, and auth error return patterns. This goes far beyond minimal disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Although lengthy, every paragraph addresses a distinct concern: purpose, budget/quota, concurrency, store sync, return schema, and error handling. The core purpose is front-loaded in one sentence, and the complex quota timing caveats justify the additional detail. There is no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, but the description fully details the return structure, including a full list of status enum values, the 'no_property' and 'unverified' edge cases, and auth error return objects. It also explains quota measurement timing issues that could otherwise lead to misuse. For a complex tool, this is comprehensive.
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, so the description must compensate. It explicitly explains the concurrency parameter's default via config.load() and the per-URL quota implication, and implies urls semantics with 'each URL' and 'one call per URL inspected'. However, it doesn't specify URL format requirements (e.g., absolute vs. relative, scheme), so it's not fully exhaustive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence states precisely what the tool does: 'Check whether each URL is indexed by Google Search, via the URL Inspection API.' It clearly distinguishes itself from requesting indexing ('answers a different question and spends a different budget doing it') and references sibling tools like gsc_quota, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when NOT to use it, stating an assistant asked to get a URL indexed 'should say so rather than reaching for this one'. It also references gsc_quota for quota details and gsc_list_sites for the property store, with added context about automatic first-call syncing, providing clear guidance on use vs. 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 discloses persistence behavior (upsert by URL), no-side-effect on sitemaps, exact return format, detailed error handling for token missing/expired/rejected, not_configured, api_error, and unexpected, and importantly clarifies that an empty list means the account has no properties, not a refused call.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured into clear paragraphs: a summary, cost/persistence behavior, return and error formats, and explicit non-scope exclusions. Every sentence provides valuable information; no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (listing, persistence, error cases), the description covers all important aspects: API cost, side effects, return schema, error contract, and alternative tools. Output schema exists but description independently explains return values and error objects, making it self-sufficient.
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 schema is trivially 100% covered. The description correctly adds no parameter details because there are none. Baseline for 0 params is 4, and the description appropriately focuses on behavior and return semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' with a clear resource: 'every Search Console property this account can see.' It clearly scopes the operation and differentiates from siblings by explicitly stating what it does not do (fetch sitemaps, index status, analytics).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit guidance on when to use this tool: mentions the one API call cost, persistence of properties to the local store, and contrast with sibling tools via 'see gsc_doctor, gsc_check_status, and gsc_performance for those.' It also notes a routine refresh won't erase sitemaps, clarifying a common concern.
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 the full burden of behavioral disclosure. It richly discloses many non-obvious behaviors: `limit` caps inspected URLs not returned, quota is ~11 inspections per day per property, `fresh: true` only means this run didn't inspect the URL, and the distinction between `undetermined` and `skipped_quota`. It also details the error response format. This far exceeds typical tool descriptions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but every sentence earns its place by explaining a nuance or an edge case that affects the agent's decision-making. It is well-structured: starts with a one-sentence purpose, then parameter semantics, then behavioral caveats, then output and error formats. No filler or redundancy; the length is justified by the complexity of the tool's behavior.
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?
There is no output schema, so the description must explain return values and it does so comprehensively: `candidates_total`, `inspected`, `limited`, `fresh`, `reason`, `action`, `submitting_helps`, `undetermined`, `status`, `skipped_quota`, and the error response format. It also places the tool in context with sibling tools (e.g., `gsc_request_indexing`) and addresses quota/timing implications, making it complete for an AI 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.
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 explains `source` (sitemap vs store vs both) and `limit` (caps inspections, not output, affects sampling) in depth. Although `site` is not explicitly described, the description repeatedly references 'the property' and 'registered sitemaps', making it clear that `site` identifies the property. This is sufficient semantic clarification for all parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The first line states precisely what the tool does: finding which URLs of a property are not in Google's index and why. It specifies the resource (property URLs) and the action (identifying unindexed ones), clearly distinguishing it from sibling tools like gsc_request_indexing (which requests indexing) and gsc_performance (which measures performance).
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?
The description provides explicit guidance on using the tool's output: it advises acting on `submitting_helps` before calling `gsc_request_indexing` and discusses when submission is a waste. It also explains the `source` parameter choices and the meaning of `limit`, including when a run is a sample rather than a full survey. This directly addresses when to use the tool and how to interpret its results vs. 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?
No annotations, so description carries full burden. It discloses local-only writes, no network/quota/token, validation-before-save, absolute pin behavior, dangling-pin failure, and persistence. No contradictions.
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?
Front-loaded with one-line purpose, then structured paragraphs for constraints, usage, params, validation, and edge cases. Every sentence adds operational knowledge.
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?
Without output schema, it describes return shape and error response. Covers all parameters and non-happy-path behavior, making it complete for reliable invocation.
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 has no descriptions, but description fully explains browser as key from gsc_detect_browsers, profile as directory string with omit behavior, and clear as override that ignores other params.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States verb 'Choose' and resource 'browser profile', and explicitly frames as overriding detection. Distinguishes itself from gsc_detect_browsers by explaining it selects rather than detects.
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 tells when to use: when detection recommends a profile that doesn't hold the account. It also contrasts with gsc_detect_browsers, clarifying that detection can rank but cannot know user's browser.
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/Mrshahidali420/google-search-console-mcp/badges/card.svg)](https://glama.ai/mcp/servers/Mrshahidali420/google-search-console-mcp)

Score Badge

Copy to your README.md:

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

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