rapid-indexer-mcp

Create CTR (search-and-click) campaign

create_ctr_campaign

Boost search CTR by sending human-like visitors who search your keywords, click your target URL, and browse like real users.

Instructions

Send visitors who search the given keywords on a search engine (Google by default), find the target URL in the results and click it, then browse like a human. SPENDS CREDITS immediately (same rate as traffic, per visitor). Confirm with the user before creating. Use list_search_engines for valid search_engine values.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`days`	No	Spread the visitors over this many days.
`link`	Yes	Target page the visitors should land on.
`title`	No	Campaign name shown in the dashboard.
`device`	No		mixed
`country`	No	Visitor geo. WW = worldwide mix.	WW
`keywords`	Yes	Search queries the visitors will type.
`referrer`	No	Apparent traffic source, e.g. "facebook.com" or a full URL. Empty = direct.
`visitors`	Yes	Total visitors to send (min 30, max 1,000 per scheduled day).
`delay_max`	No	Max seconds on page.
`delay_min`	No	Min seconds on page.
`pages_max`	No	Max internal pages per visit.
`pages_min`	No	Min internal pages per visit.
`ai_enabled`	No	Human-like AI browsing (scrolling, reading, internal clicks).
`bounce_rate`	No	Percent of single-page visits.
`click_links`	No	Paths or CSS selectors the visitor may click, e.g. ["/pricing", "button.cta"].
`search_only`	No	Search without clicking the result (search-volume boost only).
`click_chance`	No	Percent of visitors who click one of click_links.
`video_chance`	No
`search_engine`	No	Engine key from list_search_engines (GOOGLE, BING, YAHOO, DUCKDUCKGO, YANDEX, BAIDU, NAVER, AMAZON, ...).	GOOGLE
`search_language`	No	Search UI language code.	en
`search_pages_max`	No	How many result pages to scan for the target URL.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`days`	Yes
`status`	Yes
`message`	Yes
`task_id`	Yes
`ctr_mode`	No
`visitors`	Yes
`campaign_id`	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?

Goes beyond the annotations by disclosing immediate credit spend at traffic rates, the need for explicit user confirmation, and the human-like browsing behavior. These are non-obvious operational effects that annotations alone 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?

Four short, high-signal sentences. The action is front-loaded, followed by the credit warning, the confirmation requirement, and the validation source. No filler or redundant elaboration.

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 21-parameter creation tool, the rich schema plus output schema cover the inputs and return shape, while the description covers the critical operational context: cost, user confirmation, and search-engine value lookup. Nothing essential is missing for correct invocation.

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 90%, so the schema already documents nearly all parameters. The description adds little beyond restating the default search engine and pointing to list_search_engines, which the schema also mentions. Baseline 3 is appropriate.

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 mechanism (send visitors who search keywords, find the target URL, click it, browse) that clearly distinguishes this from the sibling create_traffic_campaign. The title and description both make the CTR campaign's purpose unambiguous.

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?

Gives useful procedural guidance: confirm with the user before creating, and use list_search_engines for valid search_engine values. However, it does not explicitly say when to choose this over create_traffic_campaign or when not to use it, leaving that to inference.

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

Deploy Server