Skip to main content
Glama
russjeffery

google-search-console-mcp

by russjeffery

Remove a sitemap

delete_sitemap
DestructiveIdempotent

Remove a sitemap from a Search Console property to unsubmit it. The sitemap file and indexed URLs remain unaffected, but submission history is lost.

Instructions

Remove a sitemap from a property. This unsubmits the sitemap from Search Console; it does not delete the file from the site and does not remove any indexed URLs. It is destructive only in that the submission history for that sitemap is lost.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
siteUrlYesSearch Console property, exactly as it appears in `list_sites`. URL-prefix properties include the scheme and a trailing slash ("https://example.com/"); domain properties use the "sc-domain:" prefix ("sc-domain:example.com"). These are distinct properties with different data.
feedpathYesFull URL of the sitemap to remove, e.g. "https://example.com/sitemap.xml".

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A4.5/5.0
Behavior5/5

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

Annotations already indicate destructiveHint=true and readOnlyHint=false, but the description adds valuable context by specifying that destruction is limited to loss of submission history. It also clarifies open-world effects: the sitemap file remains on the site and indexed URLs are unaffected. This exceeds what the annotations alone provide and does not contradict them.

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 sentences with no filler. The first sentence states the core action, while the second and third add critical caveats that prevent misuse. Each sentence earns its place.

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 two-parameter tool with fully documented schema, safety annotations, and no output schema, the description covers all essential behavioral context: what the tool does, what it does not do, and the precise destructive impact. There is no meaningful gap for an agent to call this tool 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?

The input schema already documents both parameters with full 100% coverage, including examples and distinctions for siteUrl. The description adds little parameter-specific meaning beyond restating the general context of a 'property' and a 'sitemap', so it does not compensate meaningfully beyond the schema baseline.

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 action ('Remove a sitemap from a property') and then clarifies the actual behavior: it unsubmits from Search Console rather than deleting the file or indexed URLs. This distinguishes it clearly from sibling tools like submit_sitemap or list_sitemaps.

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 by explaining what the tool does and does not do: it unsubmits a sitemap, does not delete the site file, and does not remove indexed URLs. This acts as an implicit usage boundary, though it does not explicitly name alternative sibling tools or provide a direct 'use when...' condition.

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