Submit a URL for asynchronous security analysis. Returns immediately with a task_id. Poll with url_scanner_async_task_status to check progress, then url_scanner_async_task_result to get the scan result. Async counterpart of url_scanner_scan for clients without native MCP Tasks support.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The URL to analyze. Must be HTTP or HTTPS. If no scheme provided, https:// is assumed. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context: the asynchronous nature, immediate return with task_id, and the required polling sequence. It doesn't discuss failure modes or edge cases, but the core behavior is transparent.
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 two sentences with zero waste. The first sentence states the core function and return, the second explains the workflow and the alternative case. All content is essential and front-loaded.
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 single-parameter tool with full schema coverage and clear annotations, the description provides everything needed: the action, the async workflow, the sibling relationships, and the reason to choose this tool. The lack of an output schema is compensated by mentioning task_id.
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?
The input schema has 100% description coverage for the sole parameter 'url', including the default scheme behavior. The description adds nothing about the parameter itself, so the schema carries the full burden. Baseline 3 is appropriate.
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 action ('Submit a URL for asynchronous security analysis') and names the return value (task_id). It distinguishes itself from siblings by explicitly labeling itself as the async counterpart of url_scanner_scan and referencing the polling/result tools.
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 usage guidance: when to use this tool ('for clients without native MCP Tasks support') and the full workflow (poll with url_scanner_async_task_status, then retrieve with url_scanner_async_task_result). This directly addresses when to use it versus alternatives.
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: sync vs async scan, with/without intent, and task status vs result retrieval. The descriptions explicitly clarify when to use each, leaving no ambiguity about which tool to select.
Names follow a predictable url_scanner_ prefix pattern with consistent suffixes for intent ('_with_intent') and sync/async distinction. The minor inconsistency is mixing 'async_scan' for submission with 'async_task_status'/'async_task_result' for polling, but the pattern remains readable and understandable.
Six tools is well-scoped for a URL scanning service: it covers the sync/async dimension, intent context, and the full task lifecycle (submit, check status, get result). No redundant or missing categories for the core purpose.
The core scan lifecycle is fully covered (sync and async, with intent, status polling, result retrieval). The only notable gap is the lack of a cancel operation for async tasks, which could be useful for long-running scans, but this is a minor omission not likely to cause agent failures.
