rapid-indexer-mcp

Submit URLs for Google indexing

submit_urls_for_indexing

Submit URLs for indexing to signal Googlebot to crawl each URL, speeding up Google discovery. Use estimate_cost first for large batches to confirm credit usage.

Instructions

Create an indexing task: Rapid Indexer signals Googlebot to crawl each URL so Google discovers it fast. SPENDS CREDITS immediately (standard ~2 credits/URL, VIP ~10 credits/URL). Run estimate_cost first and confirm with the user for large batches. Standard queue starts within minutes; VIP starts immediately with priority. drip_feed spreads submissions over several days for a natural pattern. Returns the task id; poll get_task for progress and get_task_links for per-URL status. Google makes the final indexing decision.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`vip`	No	Use the VIP priority queue (faster, higher cost).
`urls`	Yes	Absolute URLs (https://...). Scheme is added when missing. Max 10000 per task.
`title`	No	Optional label shown in the dashboard.
`engine`	No	google (default) or bing (Bing Indexing only, no Google).	google
`drip_feed`	No	Spread the URLs over drip_duration_days instead of submitting all at once.
`drip_duration_days`	No	Days to spread a drip-feed task over (only when drip_feed is true).

Output Schema

TableJSON Schema

Name	Required	Description	Default
`vip`	Yes
`message`	Yes
`task_id`	Yes
`url_count`	Yes
`is_drip_feed`	Yes
`dashboard_url`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 23, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Discloses immediate credit spending, approximate costs, queue start times, drip-feed spreading behavior, returned task id, polling follow-ups, and that Google makes the final decision. This adds substantial behavioral context beyond the annotations.

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?

The description is a compact six-sentence paragraph with no filler; it front-loads the core purpose and immediately warns about credit spending. It is dense but every sentence contributes useful behavior or guidance.

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?

Covers prerequisites (estimate_cost), side effects (credit spend), follow-up (get_task/get_task_links), and outcome uncertainty (Google decides). The only notable gap is that the description defaults to Google and does not mention the bing engine option, though the schema covers it.

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 all parameters. The description adds some reinforcement around drip_feed and costs, but does not provide new syntactic or semantic parameter details 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 states a specific verb and resource: 'Create an indexing task' and explains the mechanism (signals Googlebot to crawl URLs). It clearly differentiates this submission action from sibling tools like check_index_status or get_task.

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 explicitly tells the agent to run estimate_cost first and confirm with the user for large batches, and explains standard vs VIP queue behavior and drip_feed. It does not explicitly contrast with check_index_status, but the usage context is clear.

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

Deploy Server