Skip to main content
Glama
stufently

google-webtools-mcp

submit_sitemap

Idempotent

Submit a sitemap URL to Google Search Console so Google can discover and index the pages of that property. Use after publishing or moving a sitemap.

Instructions

Submit a sitemap URL to Google Search Console so Google can discover the pages of that property. Use when the user has published or moved a sitemap and asks to file it. Submitting the same feed again refreshes it and does not delete anything. Call delete_sitemap to withdraw a feed, and call get_sitemap_details to check processing afterwards.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
siteUrlYesThe site URL exactly as it appears in Google Search Console (e.g., "https://example.com/" or "sc-domain:example.com")
feedpathYesThe URL of the sitemap (e.g., "https://example.com/sitemap.xml")

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.2.2

TDQS

A4.5/5.0
Behavior4/5

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

Annotations cover the safety profile (idempotentHint=true, destructiveHint=false, openWorldHint=true), so the description only needs to add non-obvious behavior. It does: resubmission refreshes rather than duplicates and does not delete anything, which directly reinforces the idempotency guarantee in human terms. It stops short of disclosing failure modes (invalid/unauthorized sitemap) or rate limits, so it isn't a 5.

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?

Three tight sentences: purpose, when-to-use, and sibling routing. No filler, and the core action is front-loaded.

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 two-parameter, non-destructive mutation tool with annotations and full schema coverage, the description supplies everything an agent needs: the action, the trigger, idempotency/refresh behavior, and the two adjacent tools. No output schema exists, but for a submit-and-acknowledge operation that is a minor omission.

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

Parameters3/5

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

Schema coverage is 100%, with both siteUrl and feedpath thoroughly described (including the sc-domain: format). The description adds no parameter-level detail beyond what the schema provides, so baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (Submit) and resource (sitemap URL) plus the target system (Google Search Console), and explains the effect: 'so Google can discover the pages of that property.' This distinguishes it clearly from siblings like delete_sitemap and get_sitemap_details.

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 names the trigger scenario ('when the user has published or moved a sitemap and asks to file it') and routes the agent to both relevant alternatives: delete_sitemap to withdraw, get_sitemap_details to verify processing. Nothing is left to inference.

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