PreClick — An MCP-native URL preflight scanning service for autonomous agents.

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

Annotations cover safety profile (readOnlyHint, destructiveHint) and external data access (openWorldHint). Description adds crucial behavioral context not in annotations: the async lifecycle (immediate return, task_id generation, required polling pattern) and temporal expectations. Does not contradict annotations.

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?

Three sentences with zero waste: purpose front-loaded, procedural workflow second, sibling differentiation third. Efficient use of text to convey async pattern and tool relationships without redundancy.

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?

Despite lacking output schema, description compensates by specifying the return value (task_id) and the complete multi-step retrieval process. Adequately covers the complexity of async operations and the ecosystem of related tools.

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?

Input schema has 100% description coverage for the single 'url' parameter, including protocol assumptions. Description references 'URL' in the purpose statement but does not add semantic details beyond the schema, warranting the baseline score of 3.

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?

Opens with specific verb 'Submit' and resource 'URL for asynchronous security analysis', clearly defining scope. Explicitly identifies itself as 'Async counterpart of url_scanner_scan', distinguishing from both the sync version and the sibling polling 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?

Provides explicit workflow guidance: 'Returns immediately with a task_id. Poll with url_scanner_async_task_status to check progress, then url_scanner_async_task_result'. Also clarifies selection criteria: 'for clients without native MCP Tasks support', establishing clear when-to-use logic.

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

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

The description states 'Submit... Returns immediately with a task_id' and references polling for task status, which implies the creation of a persistent task resource (state modification). This directly contradicts the readOnlyHint=true annotation which indicates no state modification. The description also implies side effects (task creation) while annotations declare the tool is read-only.

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?

Four well-structured sentences progress logically from purpose to return value to workflow to sibling differentiation. No redundant information; every sentence advances understanding of how to invoke and integrate the tool.

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 lack of output schema, the description adequately explains the immediate return (task_id) and the complete async workflow. It appropriately delegates final result structure to the sibling tool description. Minor gap: could briefly characterize what 'security analysis' entails (malware, phishing, etc.).

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?

With 100% schema description coverage, the schema already fully documents parameter semantics (URL format requirements, optional intent). The description mentions these parameters in context but does not add semantic detail beyond what the schema provides, meeting the baseline expectation.

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 specific action ('Submit a URL... for asynchronous security analysis'), identifies the core resource (URL), and explicitly positions itself as the 'Async counterpart of url_scanner_scan_with_intent', effectively distinguishing from the synchronous sibling.

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?

Provides explicit workflow guidance ('Poll with url_scanner_async_task_status... then url_scanner_async_task_result') and clearly defines when to use this tool versus alternatives ('for clients without native MCP Tasks support').

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

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

Adds substantial context beyond annotations: explicitly states 'Non-blocking' (execution trait), explains the dual-state behavior (completed vs running), and enumerates specific return fields (risk_score, confidence, agent_access_directive) despite no output schema. Does not contradict readOnlyHint=true.

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?

Four efficient sentences with zero waste: purpose declaration, success case with data preview, pending case with polling instruction, and behavioral trait. Front-loaded with the core function.

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 result-retrieval tool, description is complete. Compensates for missing output schema by listing example result fields and explaining the polling protocol. No gaps given the tool's limited scope.

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% (task_id fully described), establishing baseline 3. Description does not explicitly discuss the parameter, but none is needed given complete schema documentation. No additional semantic context provided, but no gap created.

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?

States specific verb ('Retrieve') + resource ('result of an asynchronous scan task'). Explicitly references 'asynchronous' to distinguish from synchronous 'url_scanner_scan' siblings, and 'result' distinguishes from 'url_scanner_async_task_status'.

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?

Provides clear polling guidance ('If still running, returns status with retry_after_ms — call again after that interval'), explaining the async workflow. Lacks explicit contrast with sibling 'url_scanner_async_task_status', though the distinction is implied by emphasizing 'full scan result' retrieval.

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

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

Adds valuable context beyond readOnlyHint annotation by specifying exact status values returned ('working, completed, failed, cancelled') and explicitly stating 'without blocking,' clarifying the non-blocking polling mechanism.

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?

Three sentences with zero waste: purpose declaration, behavioral specification (status values + non-blocking), and usage guidance. Information is front-loaded and every clause earns its place.

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 simple single-parameter tool, adequately compensates for missing output schema by documenting the four possible status return values. Annotations cover safety profile; workflow guidance covers typical usage context.

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?

Input schema has 100% description coverage for the single 'task_id' parameter. The description does not add parameter-specific semantics, which meets the baseline expectation given the complete schema documentation.

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?

States specific verb 'Check' with clear resource 'status of an asynchronous scan task'. Explicitly distinguishes from sibling url_scanner_async_task_result by contrasting status checking versus result retrieval, and implies distinction from synchronous scan 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?

Provides explicit workflow guidance: 'Use url_scanner_async_task_result to retrieve the result once completed,' clearly indicating this tool is for polling status during async operations while naming the specific sibling for the next step.

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

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

Annotations declare readOnlyHint and destructiveHint, but the description crucially adds 'synchronous, blocks until complete or timeout' which defines the execution model. It also discloses return values (risk score, confidence, agent access guidance, intent_alignment) despite no output schema existing. Minor gap: doesn't specify timeout duration or failure modes.

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?

Two sentences with zero waste. First sentence covers purpose, blocking behavior, and return structure. Second sentence handles alternative selection. Information density is high with no redundant phrases.

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 no output schema exists, the description admirably documents return values and distinguishes from five sibling tools. Annotations cover safety profile. Minor gap regarding specific timeout thresholds or error handling keeps it from a 5.

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?

With 100% schema description coverage, the baseline is 3. The description does not add parameter-specific semantics beyond the schema, but the schema already comprehensively documents the URL parameter (HTTP/HTTPS requirements, default scheme behavior).

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 uses specific verb 'Analyze' with clear resource 'URL' and purpose 'security threats'. It effectively distinguishes from siblings by noting 'synchronous' vs async variants and explicitly stating 'intent_alignment (always not_provided for this tool; use url_scanner_scan_with_intent for intent context)'.

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?

Explicitly states when to use (synchronous scans) and when to prefer alternatives: 'For long-running scans, prefer url_scanner_async_scan' and references polling via 'url_scanner_async_task_result'. Also directs users to 'url_scanner_scan_with_intent' for intent context needs.

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

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

Annotations declare readOnlyHint=true and openWorldHint=true. Description adds critical behavioral context: synchronous execution ('blocks until complete or timeout'), specific return values ('risk score, confidence, agent access guidance, intent_alignment'), and timeout behavior. Does not mention rate limits or error states, preventing a 5.

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?

Three sentences with zero waste: 1) Purpose + sync behavior, 2) Return values, 3) Alternative recommendation. Front-loaded with critical blocking behavior. Every clause earns its place.

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 2-parameter tool with 100% schema coverage, good annotations, and no output schema, the description is complete. It compensates for missing output schema by listing return fields, and provides sufficient context for agent selection vs 5 sibling tools.

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%, establishing baseline 3. Description mentions 'optional user intent context' which aligns with the intent parameter's optional nature, but does not add semantic meaning beyond what the schema already provides (e.g., no examples of intent strings, no format details for URL beyond schema).

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?

States specific verb 'Analyze', resource 'URL', and distinguishing feature 'security threats with optional user intent context'. Clearly differentiates from sibling 'url_scanner_scan' by mentioning intent, and from async variants by noting 'synchronous' nature.

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?

Explicitly states when-not-to-use: 'For long-running scans, prefer url_scanner_async_scan_with_intent'. Also provides the complete alternative workflow (returns task_id, polling via url_scanner_async_task_result). Mentions blocking behavior which is critical for agent decision-making.

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