get_scan_statusCheck whether a queued scan has completed. Lightweight polling endpoint — call every 3-5 seconds with the scan_id returned by submit_scan. Scans typically complete in 5-15 seconds. When status is 'complete', call get_scan_results for the structured findings. When 'failed', surface the error field to the user.
| Name | Required | Description | Default |
|---|---|---|---|
| scan_id | Yes | Scan ID from a prior submit_scan call. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the safety profile is clear. The description adds valuable behavioral context: polling interval (3-5 seconds), expected completion time (5-15 seconds), and status-based next steps. It does not contradict annotations. Slightly more could be said about rate limits or error handling, but it's already strong.
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?
The description is concise, with two sentences that front-load the purpose and immediately provide operational details. Every sentence adds value, and there is no fluff.
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?
Given the simple tool (one required parameter, no output schema), the description covers all necessary context: how to use it, what to expect, and what to do with the results. It is complete for the agent to invoke correctly.
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 coverage is 100% with a clear description for `scan_id`. The description adds context that `scan_id` comes from a prior `submit_scan` call and specifies the polling usage pattern. This enriches the parameter semantics beyond the schema alone.
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 clearly states the tool checks whether a queued scan has completed. It distinguishes itself from siblings like 'get_scan_results' (which returns structured findings) and 'submit_scan' (which queues a scan). The verb 'check' and resource 'scan status' are specific and unambiguous.
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 description provides explicit guidance on when to use this tool: as a lightweight polling endpoint called every 3-5 seconds with the `scan_id` from `submit_scan`. It also tells what to do upon completion or failure, and directs to `get_scan_results` for structured findings. This effectively differentiates it from alternative actions.
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.
Each tool has a clearly distinct purpose: starting scans, polling status, retrieving results, looking up old scans, checking purchase status, purchasing, getting remediation plans, and server documentation. No ambiguity between tools.
Seven tools follow a consistent verb_noun pattern (e.g., get_scan_results, purchase_report). The outlier 'how_to_use' deviates slightly from the pattern. Overall naming is coherent and readable.
Eight tools cover the full SEO scan workflow without being excessive. Each tool serves a necessary step, from submission to remediation, so the count is well-scoped for the server's purpose.
The tool set covers the core workflow: scan submission, status polling, results retrieval, purchase, purchase status, and remediation plan retrieval. A minor gap is the lack of a tool for user account management or scan history beyond email lookup, but these are not essential for the primary use case.