Skip to main content
Glama
Sign In
gsc-mcp

gsc-mcp

by mikusnuz
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

indexing_batch_publish

Batch notify Google of up to 100 JobPosting or BroadcastEvent URL updates and removals, with each notification response checked independently; success does not guarantee indexing.

Instructions

Batch notify Google about up to 100 eligible JobPosting or BroadcastEvent URL updates/removals. Each embedded response is checked independently; a successful notification does not guarantee indexing.

Input Schema

NameRequiredDescriptionDefault
notificationsYesArray of eligible URL notifications (1-100 items). Each item has url, contentType, and type.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv1.3.6
    • changedInput schema / properties / notifications / description
      Previous value: -"Array of URL notifications (1-100 items). Each item has a url and type."New value: +"Array of eligible URL notifications (1-100 items). Each item has url, contentType, and type."
    • addedInput schema / properties / notifications / items / properties / contentType
      Added value: +{
+  "description": "Eligible page type: JobPosting, or BroadcastEvent embedded in VideoObject",
+  "enum": [
+    "JobPosting",
+    "BroadcastEvent"
+  ],
+  "type": "string"
+}
    • addedInput schema / properties / notifications / items / properties / url / format
      Added value: +"uri"
    • changedInput schema / properties / notifications / items / required
      Previous value: -[
-  "url",
-  "type"
-]New value: +[
+  "url",
+  "contentType",
+  "type"
+]
  2. First observedv1.3.1

TDQS

A4.2/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full behavioral burden and usefully discloses the batch limit, independent per-item response checking, and the important caveat that successful notification does not guarantee indexing. It does not cover auth requirements or quota behavior beyond the item limit.

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 compact sentences, front-loaded with scope and limits, then the important caveat. Every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter batch notification tool with no output schema, the description covers eligibility, batch size, per-item independence, and the key indexing caveat. It stops short of describing response shape or authentication/quota context, but is otherwise complete enough to call correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents the notification object fields, enums, and 1-100 item range. The description reinforces eligibility and batch size but adds little parameter-level detail 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 uses a specific verb and resource: "Batch notify Google about ... JobPosting or BroadcastEvent URL updates/removals." It distinguishes itself from the likely single-URL sibling indexing_publish through the word "Batch" and the explicit 100-item limit.

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 useful usage context: up to 100 eligible URL updates/removals for JobPosting or BroadcastEvent content. It does not explicitly state when to use indexing_publish instead, but the batch-vs-single distinction is strongly implied.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools