Run an AI visibility prompt now
run_ai_visibility_promptAsk the AI engines one tracked prompt now and record the answers.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| siteId | Yes | ||
| monitorId | Yes | ||
| projectId | Yes | ||
| idempotencyKey | Yes |
run_ai_visibility_promptAsk the AI engines one tracked prompt now and record the answers.
| Name | Required | Description | Default |
|---|---|---|---|
| siteId | Yes | ||
| monitorId | Yes | ||
| projectId | Yes | ||
| idempotencyKey | Yes |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false and openWorldHint=true, so the agent knows this writes state and reaches external AI engines. The description adds that answers are 'recorded', implying a persisted run record, but says nothing about cost, latency, rate limits, or what happens if the same prompt is run repeatedly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no filler; the action and its effect are stated immediately and nothing is repeated from the structured fields.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a non-read-only tool with four required, undocumented parameters and no output schema, the description is too thin: it does not explain how to specify the prompt, the role of the idempotency key, or what the recorded result looks like.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% across four required parameters (projectId, siteId, monitorId, idempotencyKey). The phrase 'one tracked prompt' loosely implies the monitorId identifies the target, but idempotencyKey, whose behavior is the most consequential, is entirely unexplained in both schema and description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a concrete action on a concrete resource: ask AI engines one tracked prompt and record the answers. This clearly separates it from configuration siblings like create_ai_visibility_prompt or update_ai_visibility_prompt, but it never names those siblings or explicitly contrasts the execution semantics with list_ai_visibility_prompt_runs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The word 'now' hints at on-demand execution, but there is no explicit when-to-use guidance, no prerequisites, and no mention of alternatives such as bulk_create_ai_visibility_prompts for multiple prompts or list_ai_visibility_prompt_runs for checking prior results.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.