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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable non-obvious behaviors: each call consumes query quota, results are untrusted data, and it does not poll or initiate other analyses. This goes beyond annotations by warning about side effects (quota) and data trustworthiness, which an agent needs to invoke safely.

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 structured with a lead purpose sentence followed by clarifications. Every sentence adds value—quota consumption, exclusions, parameter guidance, and security warnings. It is slightly longer than necessary but avoids redundancy and front-loads the core purpose, making it easy to parse.

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 read-only tool with 2 parameters and no output schema, the description covers purpose, parameter usage, behavioral side effects, and security context. It does not specify the return format or structure, but given the 'untrusted data' note and the tool's simplicity, the information provided is adequate for an agent to call it 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 description coverage is 0%, so the description must compensate. It does: it clarifies that analysis_id is required and sufficient for file calls, and that request_id is needed for network analysis when VirusTotal reuses an analysis ID. This adds meaning beyond the schema's simple type definitions, though it does not describe formats or validation rules.

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 'Read one analysis registered to the current VTAI account' with a specific verb and resource. It differentiates from siblings by noting it returns the analysis's own results, not the latest report, and by listing actions it does not perform (poll, upload, initiate). This distinguishes it from get_file_report, get_url_report, and submission 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 practical usage context: it explains when to pass request_id (network analysis with reused IDs) versus only analysis_id (file calls), and clarifies what the tool does not do (poll, read local path, upload, initiate analysis). It doesn't explicitly name alternative tools but gives enough behavioral cues to route correctly. The 'An ID is not authorization' warning also sets expectations for use.

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 already signal read-only, idempotent, and non-destructive behavior. The description adds valuable context beyond annotations: no DNS resolution or visiting occurs, Unicode names are normalized, a query quota applies, and the result is not URL-exhaustive.

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 short sentences, front-loaded with the core purpose, then input constraints, then scope caveat. Every sentence adds distinct information and there is no filler.

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 one-parameter, read-only lookup with rich annotations and no output schema, the description is complete: it explains the passive nature, input format, normalization, quota, and result scope. Nothing essential is missing for selecting or invoking the tool.

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 0% schema description coverage, the description fully compensates for the single 'domain' parameter by specifying what to omit (scheme, path, port), that Unicode is normalized, and that a quota applies. This is enough for an agent to construct a valid call.

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 a specific verb and resource: 'Look up existing intelligence for a DNS domain name'. It also clarifies what the tool does not do ('without resolving or visiting it') and is clearly distinct from sibling file/URL/IP report 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?

It states the intended use case (existing domain intelligence) and gives concrete input constraints: 'Supply a domain without a scheme, path or port'. It warns that 'The result does not cover every URL on the domain', but it does not explicitly name sibling alternatives such as get_url_report.

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 already declare readOnly/idempotent/non-destructive/openWorld, so the safety profile is covered. The description adds non-obvious behavior: it consumes VTAI query quota, it will not auto-submit, and AI insight/detection text is evidence rather than instructions — real value beyond the 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?

Purpose is front-loaded in the first sentence, followed by quota, non-submission, and fallback guidance. Five short lines all carry information; the prompt-injection warning is slightly tangential but defensible for a security 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?

No output schema exists, yet the description implies a next_steps field and describes the nature of returned evidence, which is enough to interpret results. Coverage of quota, safety, and fallback makes this adequate for a single-parameter read tool.

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 0% and the input schema gives only an untyped 'hash' string. The description compensates by specifying the accepted formats (hexadecimal MD5, SHA-1 or SHA-256), which is exactly the missing detail an agent needs to build a valid call.

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 a specific verb (look up) and resource (existing file report) with the key constraint that it is a lookup, not a scan. The word 'file' cleanly separates it from the url/domain/ip report siblings, so an agent can route correctly without opening schemas.

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 says it does not upload or rescan and never submits automatically, and tells the agent what to do when no report exists: follow next_steps to submit the actual bytes. It stops short of naming the submit_file sibling as the alternative, leaving the agent to infer the specific tool.

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?

Beyond the annotations, the description adds meaningful behavioral detail: the lookup does not contact the address, VTAI normalizes input, query quota applies, and a missing report does not establish safety. These are non-obvious behaviors that materially affect agent expectations and are not present in the annotations alone.

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 concise sentences deliver the core purpose, input constraints, and an important interpretation caveat. There is no filler, and each sentence 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 single-parameter lookup tool with strong annotations and in-description parameter guidance, the description covers correct invocation and interpretation of results. The lack of an output schema is not a critical gap because the report nature is clear from the title and purpose.

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 schema provides only a bare 'ip' string with no description, so the description carries the full semantic burden. It thoroughly explains what an acceptable address looks like: IPv4 or IPv6, no brackets, port, zone, or CIDR suffix, and mentions normalization 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 clearly states the verb ('look up') and resource ('existing intelligence for one IPv4 or IPv6 address'), which is specific and easy to distinguish from file, URL, or domain tools. It does not explicitly name sibling tools, but the address-type framing makes the purpose 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 gives clear context for when this tool is appropriate: looking up existing IP intelligence without contacting the address. It also provides concrete input-format guidance and a safety caveat, though it does not explicitly state when to use an alternative sibling instead.

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 already declare read-only, idempotent, and non-destructive; the description adds valuable state/outcome semantics (Submitted yields analysis ID, Unknown can be permanent, Rejected is terminal) plus a no-quota/no-upstream-call note. This goes well beyond the structured hint coverage and does not contradict it.

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 first sentence is front-loaded with the core action and constraint, and each later sentence adds useful operational detail. It is slightly dense and uses status terms (Submitted/Unknown/Rejected) without explicit labels, but it is not padded or redundant.

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 two-parameter, no-output-schema tool, the description covers parameter selection, safe repeated invocation, quota characteristics, and key result semantics. No critical information needed to invoke the tool correctly is missing.

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 0% schema description coverage and two nullable parameters, the description carries the full burden. It explains that sha256 identifies a file, request_id is a retained UUIDv4 network-operation identifier, and exactly one must be supplied despite the schema making both optional.

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 specific verb ('Recover') and resource ('current account's ... receipt') and imposes the exactly-one-of-sha256/request_id constraint. This distinguishes the receipt-recovery purpose from sibling report/analysis tools like get_analysis and get_file_report.

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?

It gives clear context for when to call it (have a sha256 or retained request_id) and what to avoid (auto-repeat POSTs, generating new request IDs). It does not explicitly name alternatives or draw a when-not-to-use contrast with sibling tools, so it stops short of a 5.

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?

Beyond the readOnly and idempotent annotations, the description discloses that the full URL, including query and fragment, is shared with VTAI and VirusTotal, that the indicator is normalized, that query quota applies, and that unknown stays unknown. This is substantial behavioral context an agent needs before calling.

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 four short sentences, front-loaded with the core action, followed by relevant caveats and an alternative. Every sentence contributes unique information: scope, privacy, alternative, and normalization/quota behavior. There is no 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?

For a one-parameter read-only lookup without an output schema, the description covers the purpose, behavior, privacy implications, quota effects, and alternative tool enough for an agent to decide and invoke correctly. The 'Unknown stays unknown' statement clarifies the no-side-effect nature of the lookup.

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 schema provides only a title for the single `url` parameter and 0% description coverage. The tool description compensates by clarifying the expected input is an HTTP(S) URL, that the full URL with query/fragment is transmitted, and that normalization applies. It does not give explicit syntax examples, but for a single parameter this is a meaningful addition over the 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?

The description opens with a specific verb and resource: 'Look up existing intelligence for an HTTP(S) URL'. It also explicitly states what the tool does not do ('without visiting or submitting it'), distinguishing it from sibling submission tools and other report types.

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?

It gives a clear alternative with the exact condition: 'use get_domain_report when domain scope is sufficient'. It also warns against sending secret-bearing URLs, which is practical when-to-use guidance. The 'without visiting or submitting' phrase separates it from submission-oriented siblings.

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?

Beyond the annotations (destructiveHint=true, idempotentHint=true), the description adds substantial behavioral detail: the recovery workflow with get_submission and get_analysis, the directive to 'never automatically repeat POST,' and the caveat that domain analysis does not establish URL safety. This significantly enriches the agent's understanding of side effects and error handling.

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 structured with a front-loaded purpose statement followed by essential operational details. While it contains six sentences, each earns its place—no fluff. It could be slightly tighter, but the information density is high and well-organized.

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 tool with only two parameters and no output schema, the description is remarkably complete. It covers the purpose, parameter constraints, sharing model, quota implications, recovery procedure, and a critical limitation. Nothing an agent needs to invoke it correctly is missing.

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 0% schema description coverage, the description fully compensates. It explains the domain parameter ('without scheme, path or port') and the request_id parameter (must be a 'new canonical lowercase UUIDv4' and 'Reuse the ID only for the same operation'). This provides all necessary parameter semantics.

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 specific verb ('Request'), resource ('reanalysis of a domain'), and a critical constraint ('without scheme, path or port'), which clearly differentiates it from the sibling reanalyze_ip. An agent can immediately understand what the tool does and how it differs from other reanalysis 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 clear usage context: it mentions 'Standard sharing applies; no per-call confirmation,' 'Uses current rights and quota,' and instructs to 'Reuse the ID only for the same operation.' It also gives recovery guidance. However, it does not explicitly name alternatives (e.g., reanalyze_ip for IPs), though the purpose clarity largely compensates.

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 already provide readOnly=false, destructiveHint=true, and idempotentHint=true, and the description adds material context on top: standard sharing applies, no per-call confirmation, current rights/quota are used, retries are prohibited, and 'completion is not a safety verdict.' These are behavioral facts the binary hints 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

Although the description is comparatively long, it is front-loaded with purpose, and each subsequent clause carries a distinct operational rule—format, ID handling, sharing, quota, recovery, and result semantics. There is no filler; every sentence 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?

It covers input constraints, ID management, quota/rights, recovery via sibling tools, and how to interpret the completion signal, which is nearly everything for a two-parameter endpoint. The only minor omission is an explicit statement of the immediate response envelope, though the recovery guidance partially compensates.

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%, so the description must compensate, and it does. It specifies the IP format (bare IPv4/IPv6, no port, brackets, zone, or CIDR) and the request_id format (new canonical lowercase UUIDv4), giving the agent concrete validation knowledge beyond the empty 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?

The first sentence names the exact operation and resource: 'Request standard VirusTotal reanalysis of one IPv4 or IPv6 address.' This is specific enough to distinguish it from sibling tools like get_ip_report or reanalyze_domain without inspecting their schemas.

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?

It explicitly instructs when to invoke the tool (reanalysis of an IP) and routes recovery through get_submission(request_id) and get_analysis, never an automatic POST retry or replacement request ID. It also clarifies when a new ID is appropriate—a deliberate later reanalysis—which is exactly the decision guidance an agent 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 already flag destructiveHint=true and idempotentHint=false, and the description adds substantial context beyond them: submission is not confidential, content is shared with the community, the bytes are visible to the MCP host, no tool-level confirmation is added, and VTAI identity/quota is reused without passing credentials. It also discloses that existing reports are returned without new analysis.

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?

Front-loaded with the hard size constraint, then safety, then routing. Dense but every sentence carries operational weight; the phrase 'including in attachments or unfamiliar files' slightly restates the preceding clause, and the paragraph is long enough that an agent must read several lines to find the recovery advice.

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 write tool with no output schema, the description covers the safety/consent model, confidentiality implications, size limits, error recovery path, and follow-up polling via get_analysis. Nothing an agent needs to call it correctly is missing.

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%, so the description carries the burden and does so: content_base64 is constrained to canonical base64 at most 24,000,000 decoded bytes (a tighter, decoded-size framing than the schema's 32,000,000 maxLength), and sha256 is described as the match key. The sha256 format itself (hex, case) is left implicit.

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 a specific verb and resource: submit canonical base64 bytes matching a SHA256 to VirusTotal, with an explicit size bound. It implicitly distinguishes itself from siblings submit_url and submit_local_file by stating the bytes are inline ('A remote server cannot read your local path').

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 names when to use it (unfamiliar downloads, attachments, binaries, scripts of unknown origin) and when to ask first (user's own documents, internal code, credentials, personal data). It also routes to alternatives for large files and to get_submission/get_analysis for recovery, which is stronger than most definitions.

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?

Despite annotations already covering the safety profile (destructiveHint, openWorldHint, idempotentHint), the description adds substantial behavioral context: standard submission is not confidential and shares content with the VirusTotal community, no confirmation is added, host permissions and quota apply, POSTs are never retried, and local cancellation does not withdraw an accepted file. It also clarifies that an interrupted call can only recover a receipt via durable reference. No annotation contradiction exists.

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 front-loaded with the actionable core and then layers in constraints, safety guidance, and follow-up semantics. Every sentence carries operational significance for a destructive, open-world submission tool; there is no filler or redundant restatement of the title.

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 complex, non-idempotent, destructive submission tool with no output schema, the description is nearly complete: it covers source semantics, size limit, hashing, confidentiality, quota, retry behavior, cancellation, and follow-up tools. It stops short of explicitly describing the return value or receipt shape, which would be helpful given the absence of an output schema.

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 0% schema description coverage, the description must carry parameter meaning, and it does: 'path' is defined as a local server filesystem path, explicitly not a remote client path or URL, and it notes the 32,000,000-byte limit for the submitted file. 'expected_sha256' is described as an optional value that must match the hashed copy of the bytes. It could still clarify the expected hash format (e.g., hex length) and path format, which keeps this from being a 5.

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 first sentence states a specific verb, resource, and scope: 'Submit one local regular file of at most 32000000 bytes in standard mode.' It immediately distinguishes the local-filesystem source from remote client paths and URLs, which is critical against siblings like submit_file and submit_url. An agent can select this tool without opening another schema.

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 gives explicit when-to-use guidance ('Submit unfamiliar downloads, attachments, binaries or scripts of unknown origin') and when-to-ask-first guidance ('Ask before submitting the user's own documents, internal code, credentials or personal data'). It also names the correct follow-up alternatives, get_submission and get_analysis, rather than leaving completion checking ambiguous.

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 already cover the safety profile (write, openWorld, idempotent, destructive), yet the description adds substantive unseen context: VirusTotal may visit and publicly share the URL including query and fragment, no tool-level confirmation is added, host permissions/rights/quota apply, and the same request_id is reserved for one operation. This is consistent with, and richer than, the 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?

Purpose is front-loaded and most sentences carry distinct operational information, but the middle section is telegraphic ('No tool-level confirmation is added; host permissions and current VTAI rights and quota apply') with some fragments and the slightly awkward 'After uncertainty' phrase.

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 no output schema, the description explains the return semantics ('use the registered analysis_id with get_analysis; submitted is not completed'), privacy exposure, idempotency rules, quotas and error recovery, which is everything an agent needs for a high-impact write tool.

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%, so the description must carry the parameter burden, and it largely does: request_id must be a new canonical lowercase UUIDv4 reserved to one operation, and url is constrained to HTTP(S) with query and fragment included. It stops short of documenting url format limits or whether bare domains are rejected.

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 opening sentence gives a precise verb ('Request ... analysis'), resource ('one HTTP(S) URL') and method ('standard VirusTotal analysis'), which cleanly separates it from the file-oriented siblings submit_file and submit_local_file. An agent can identify the operation without opening the schema.

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?

It states when to submit ('suspicious URLs'), an explicit when-not/ask-first condition (URLs containing the user's own documents, internal code, credentials or personal data), and names the correct follow-up alternatives: get_submission(request_id) after uncertainty instead of a retry or new ID, and get_analysis for results.

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