Skip to main content
Glama
Mrshahidali420

Google Search Console MCP Server

gsc_quota

Check Request-Indexing and URL Inspection quota budgets per property, showing free/spendable slots, next-free times, and which budget is exhausted.

Instructions

Report Request-Indexing and URL Inspection budget for every property the store currently knows about.

Local-only: reads the store and the config file, makes no Search Console API call, and needs no OAuth token — safe to call at any time, including before signing in. An empty store (nothing synced yet via gsc_list_sites or gsc_check_status) returns [].

One entry per property: {"property", "submission", "inspection", "binding"}.

THESE NUMBERS ARE AN ESTIMATE, NOT A MEASUREMENT, and the estimate is biased in one direction. The store counts only the slots THIS TOOL spent: a URL submitted by hand in Search Console, from a phone, or on another machine never reaches it. So used is a lower bound and free an upper bound — a property reported with headroom can still be refused by Google, and that is expected behaviour rather than a defect. Do not tell a user "you have N submissions left" without that caveat, and do not conclude anything about Google's own rules from these counts. counts and free_is_upper_bound restate this in the payload so it survives being read without the docstring.

"submission" is the Request-Indexing slot budget: {"free", "spendable_free", "used", "slots", "daily_reserve", "next_free_at", "counts", "free_is_upper_bound", "last_refusal_at"}. last_refusal_at is the last time Google actually said Quota Exceeded for this property (ISO-8601, or None) — the only figure in the block that came from Google rather than from local arithmetic. free is the RAW free-slot count and ignores daily_reserve. spendable_free is computed against the RESERVE-ADJUSTED ceiling — max(0, (slots - daily_reserve) - used) — NOT simply free minus daily_reserve: that arithmetic breaks at the clamp (slots=11, daily_reserve=2, used=10 gives free=1, but spendable_free is 0, not -1). ACT ON spendable_free, NOT free: daily_reserve exists to hold slots back from every tool, and a caller that submits up to free instead will be refused once spendable_free runs out. next_free_at is an ISO-8601 string, or None when a slot is free right now — it is already computed against the reserve-adjusted ceiling too, so it can report a wait even while free (the raw count) is nonzero.

"inspection" is the URL Inspection API budget: {"daily_free", "minute_free", "daily_limit", "minute_limit"} (2000/day, 600/minute, per property — the same quota gsc_check_status spends).

"binding" names whichever budget is exhausted for that property right now — "submission" (the Request-Indexing ceiling, reserve applied), "refused" (Google said Quota Exceeded recently and a short cooldown is running), "inspection_daily", or "inspection_minute" — or None when every budget has headroom. On "refused", spendable_free may be nonzero: the local estimate is being overruled by what Google actually answered, and next_free_at is when to ask again rather than a moment a slot is known to exist.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
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.

Install Server

Other Tools

Latest Blog Posts

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