Skip to main content
Glama
Sign In
indexmachine

IndexMachine MCP server

Official
by indexmachine
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Submit URLs to IndexNow

submit_indexnow

Notify Bing, Yandex, and other IndexNow engines of up to 100 URLs for one site at once; does not reach Google and requires the site's IndexNow key file.

Instructions

Notifies Bing, Yandex and the other IndexNow engines of up to 100 URLs of one site at once; it does not reach Google, and each engine decides when it crawls. It needs the site's IndexNow key file in place (indexnow_ready in list_sites) and takes 20 submissions per site a day. More than 10 URLs at once wait for the user's yes. Clients that can ask their user (MCP elicitation) get a question to confirm, and the answer does not pass through the model; with other clients the tool refuses first with a confirm token, and the call with that token stands for the user's yes.

Input Schema

NameRequiredDescriptionDefault
siteYesThe site: its id (a UUID) or its domain, such as example.com
urlsYesURLs of this site, 100 at most
confirmNoThe confirm token from this tool's refusal, once the user agreed

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.6/5.0
Behavior5/5

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

Goes well beyond the annotations: it discloses that crawl timing is engine-decided (not guaranteed), that requests do not reach Google, the prerequisite key file, the per-site daily quota, and the full confirmation protocol including the elicitation path and the confirm-token fallback. No contradiction with readOnlyHint=false, openWorldHint=true, idempotentHint=false or destructiveHint=false.

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?

placeholder

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?

placeholder

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

Parameters5/5

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

placeholder

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 (notifies engines), the exact resource (up to 100 URLs of one site), the target engines (Bing, Yandex, other IndexNow engines), and explicitly what it does NOT do (does not reach Google). That negative scope cleanly distinguishes it from siblings like request_indexing and check_url.

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?

Gives concrete preconditions (IndexNow key file present, verified via indexnow_ready in list_sites) and a usage cap (20 submissions per site per day), which tells the agent when this call is viable. It implies but never explicitly names the alternative for Google coverage, so routing to a sibling is left to inference rather than stated.

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