Skip to main content
Glama

indexnow_key

Read-only

Generates an IndexNow key and key file to publish at your site root, enabling Bing, Yandex, and other IndexNow engines to verify and index content. Not for Google.

Instructions

Generates (or echoes INDEXNOW_KEY) an IndexNow key and the key file to publish at the site root. Bing/Yandex/etc only, not Google.

Input Schema

NameRequiredDescriptionDefault
siteYesProperty: "https://example.netlify.app/", "example.com" (URL-prefix, https assumed) or "sc-domain:example.com" (domain property).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.8/5.0
Behavior4/5

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

readOnlyHint=true is already declared, and the parenthetical '(or echoes INDEXNOW_KEY)' usefully explains why a 'generate' operation is nonetheless read-only — the value may come from an environment variable. It further discloses the required deployment step (publish the key file at the site root) and the supported engines, which annotations cannot convey.

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 tight sentences with no filler; the artifact produced and the deployment requirement come first, with the engine restriction as a compact qualifier. Every clause 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?

With one fully documented parameter and no output schema, the description covers the essentials: what is produced, where it must be published, and which engines honor it. It stops short of explaining idempotency or the relationship to the ping/submission flow, a minor gap for a tool this simple.

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% and the single 'site' parameter is documented with three concrete URL/domain formats, so the schema carries the semantics. The description adds no additional meaning about the parameter, which is the baseline-3 case.

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 names a specific verb and resource ('Generates ... an IndexNow key and the key file') and states where the artifact must go ('to publish at the site root'). It is clearly distinguishable from indexnow_ping and get_verification_token, though it does not name them explicitly.

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 engine scope note ('Bing/Yandex/etc only, not Google') tells the agent when this key is useful, which is real routing value. However, it never says when to call this versus the sibling indexnow_ping, nor whether it must precede submission, leaving the workflow implied rather than stated.

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