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

Goes well beyond the annotations by disclosing quota consumption per call, that an ID is not authorization, that results are untrusted data, and the intended-operation disambiguation via request_id. These are exactly the operational traits annotations don't 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?

Front-loads the core action, then the scoping and operational caveats in short sentences. Slightly dense, but each sentence adds routing or behavioral value rather than restating 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?

Covers purpose, usage routing, auth/quota caveats, and data trust, and the annotations carry the safety profile, so no output schema is needed. Adequate for correct invocation with only minor format details left implicit.

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 coverage the description must carry parameter meaning, and it does: request_id is described as the receipt's request_id used to disambiguate a reused analysis ID, and analysis_id as the sole requirement for file calls. The mapping is clear though not exhaustive on format expectations.

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 ('Read one analysis registered to the current VTAI account') and explicitly distinguishes itself from the report tools by clarifying it returns the analysis's own pending/completed results, not the latest report. An agent can separate it from get_file_report and get_submission without opening a 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?

Gives concrete routing conditions: pass request_id for network analyses if VirusTotal reused an analysis ID, and analysis_id alone suffices for file calls. It also lists what the tool does not do (poll, upload, initiate another analysis), which narrows usage. It stops short of naming a specific sibling to use instead for 'latest report' lookups.

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, openWorld and non-destructive, so the safety profile is covered. The description adds genuinely new behavioral context beyond them: a query quota is applied, Unicode domain names are normalized, and the result is not exhaustive for the domain's URLs. It does not cover auth requirements or error behavior.

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 core action, then preconditions, then caveats; every sentence carries information. Slightly fragmented across four short lines, but nothing is wasted or repeated.

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 with no output schema, the definition covers the input contract, the quota/normalization behavior, and the coverage limitation, while annotations carry the safety profile. What the report actually contains and how unknown domains are handled remain unstated, but the essentials for correct invocation are present.

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% — the schema only labels the field 'Domain' with no description — so the description carries the burden and does so: it specifies the accepted format (no scheme, path or port) and notes Unicode normalization. That is meaningful semantic guidance beyond the schema, though no examples are given.

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 ('look up existing intelligence for a DNS domain name') and immediately bounds the scope with 'without resolving or visiting it', which implicitly separates it from the sibling reanalyze_domain that triggers a fresh scan. An agent can tell what this retrieves and what it does not do.

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 an input-format precondition (domain without scheme, path or port) and implies this is a passive lookup, but it never explicitly says when to choose this over reanalyze_domain, get_url_report, or get_ip_report. Usage is inferable rather than stated.

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?

With annotations already covering readOnly/idempotent/destructive, the description adds crucial operational context: quota consumption, no upload/rescan, missing report semantics, and a safety note about AI insights not being executable instructions. This is behavior beyond what annotations 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?

Front-loaded with the core action and accepted formats. Each sentence serves a purpose, though the wording is somewhat dense and the final AI insights sentence is a bit tangential to tool invocation.

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 read tool with no output schema, the description covers what the tool does, identifier requirements, side effects (none), quota usage, and negative alternatives. It stops short of explaining what a report contains, but annotations and the context make it sufficiently complete.

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% for a single 'hash' parameter, so the description must compensate. It specifies the three accepted hash algorithms and notes the hash should be verified, adding meaningful semantics. Slightly less than 5 because it doesn't explicitly state format constraints beyond algorithm names.

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 (file report) with the exact acceptable identifier formats (MD5, SHA-1, SHA-256). Clear differentiation from siblings that handle URLs, domains, and IPs.

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 it: 'Does not upload or rescan the file' and 'never authorizes a submission or starts an analysis', which routes the agent to submit_file/reanalyze tools. It stops short of naming those alternatives directly, so not quite 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?

Annotations already cover readOnly/idempotent/openWorld/no-destructive, and the description goes further by disclosing that VTAI normalizes the address, that the call consumes query quota, and that a missing report does not establish safety. Those are real behavioral traits an agent needs and none are in the structured fields.

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 short sentences, each doing work: purpose and non-contact semantics first, then input format, then quota cost, then the not-found caveat. Nothing is redundant and the most important framing is 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?

With no output schema, the description still tells the agent what the call costs (quota), what it does not do (contact the host), and how to interpret an empty result. Report field contents are left unexplained, which is a minor gap for a lookup tool whose annotations already cover the safety profile.

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% for the single `ip` parameter, so the description carries the load and does so usefully: no brackets, no port, no zone, no CIDR suffix. It adds format constraints absent from the schema, though it could also note accepted literal formats (e.g. bare IPv6) more explicitly.

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 intelligence for one IPv4/IPv6 address) with the scope qualifier 'without contacting it', which distinguishes it from the sibling reanalyze_ip that would trigger a fresh analysis. An agent can pick this tool over its siblings from the description alone.

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 phrase 'without contacting it' implicitly routes the agent away from the reanalysis siblings and toward cached intelligence lookups, and the missing-report caveat sets expectations about results. It stops short of naming reanalyze_ip as the alternative or stating explicit when-not conditions.

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/closed-world, so the bar is lower, and the description still adds material context: no upload, upstream call, or query quota is consumed, and it documents the status lifecycle (Submitted, Unknown permanent, Rejected terminal). It does not describe what happens if zero or both identifiers are supplied, which is the main remaining gap.

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 core constraint is front-loaded in the first sentence and no sentence is pure filler. The remainder is telegraphic and dense ('Submitted yields the original analysis ID. Unknown can be permanent'), which costs some readability but not accuracy.

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 covers the return semantics an agent needs (Submitted yields the original analysis ID; status outcomes). It omits the degenerate input cases (neither/both identifiers) and the receipt's own shape, leaving a small but real gap.

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% — the schema only has bare 'sha256' and 'request_id' names. The description fully compensates, defining sha256 as file identity, request_id as a retained UUIDv4 for a network operation, and imposing the mutual-exclusion rule the schema does not encode (both are nullable/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?

States a specific verb+resource: 'Recover the current account's receipt' keyed by sha256 or request_id. The sha256-vs-request_id distinction ('a file' vs 'a network operation') separates it from hash-only siblings like get_file_report, but it never explicitly names get_analysis or get_file_report as the alternative, so the differentiation is inferential rather than stated.

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?

Gives real context: 'exactly one' of the two identifiers, plus explicit state-dependent guidance ('do not automatically repeat a POST or generate a new request ID' on Unknown; 'Rejected is terminal... correct the cause or wait'). It stops short of naming which sibling to call instead in the retrieval case, so it is strong implied usage rather than full when/when-not routing.

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 the safety profile (readOnly, idempotent, non-destructive, openWorld), and the description adds materially more: the full URL including query and fragment is shared with VTAI and VirusTotal, the indicator is normalized, a query quota is applied, and unknowns are reported as unknown rather than inferred. That is exactly the kind of privacy, quota and result-fidelity context annotations cannot carry.

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 short sentences, front-loaded with purpose and scope, then privacy warning, then mechanics. No filler; every sentence changes how an agent would call 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?

No output schema exists, yet the description covers what matters for this read-only, single-param lookup: scope, alternative, data-sharing surface, quota behavior and explicit handling of unknown results. Nothing required for a correct call 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 a single parameter and 0% schema description coverage, the description must carry the load, and it does add meaning: the whole URL including query and fragment is transmitted, so the caller knows what not to include. It stops short of stating format expectations (scheme requirements, normalization effects on matching).

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 ('Look up existing intelligence for an HTTP(S) URL') and immediately bounds the scope with 'without visiting or submitting it', which cleanly separates it from the submit_url sibling. An agent can pick this tool over its neighbours without opening a 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?

Gives an explicit alternative and the condition that selects it: 'use get_domain_report when domain scope is sufficient'. It also adds a caution ('Avoid URLs containing secrets') and implicitly routes submission intents away via 'without visiting or submitting it'.

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 non-read-only, destructive, idempotent, open-world behavior, and the description adds substantial context on top: standard sharing, no per-call confirmation, consumption of current rights/quota, and the caveat that a domain analysis does not establish the safety of each URL on that domain. The request_id reuse and recovery semantics further disclose behavior the annotations cannot express.

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 and the explicit-request gate are front-loaded, and the operational notes are dense but mostly earn their place. The request_id and recovery guidance is necessary but slightly overloads a single short block.

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-param POST with no output schema, the definition covers the input format, request_id lifecycle, quota/sharing implications, failure recovery, and a scope caveat. It stops short of describing what the immediate POST response contains, but the get_submission/get_analysis path mitigates that gap.

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 both parameters, and it does: the domain must omit scheme, path, and port, and request_id must be a new canonical lowercase UUIDv4 generated before the call and reused only for the same operation. This meaningfully compensates for the absent 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 a specific verb and resource ('Request standard VirusTotal reanalysis of a domain') and immediately constrains the input format ('without scheme, path or port'). This clearly differentiates it from siblings like reanalyze_ip and get_domain_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?

Explicitly gates invocation: 'Reanalyze only when the user explicitly requests analysis of this domain,' and gives an interruption-recovery path via get_submission then get_analysis with an instruction never to auto-repeat the POST. It does not name sibling alternatives (e.g., reanalyze_ip, submit_url) for comparison, so it stops short of full routing guidance.

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 only declare the write/safety profile (readOnlyHint=false, destructiveHint=true, idempotentHint=true, openWorldHint=true). The description adds substantive behavior beyond that: no per-call confirmation, standard sharing, consumption of current rights/quota, recovery via get_submission(request_id) and get_analysis, an explicit ban on automatic POST retries, and the caveat that completion is not a safety verdict.

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 trigger conditions, then parameter constraints, then recovery semantics. It is dense and somewhat clipped in style, but each sentence carries operational information with little waste.

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?

With no output schema and only two undocumented parameters, the description supplies the missing pieces an agent needs: input formatting, ID lifecycle, quota/sharing implications, and the interruption-recovery path. Return-value shape is left unstated, which is the only notable gap for a submission-style 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%, so the description must carry both parameters, and it largely does: the ip format is constrained (no port, brackets, zone or CIDR) and request_id is specified as a new canonical lowercase UUIDv4 retained across calls. Only minor details (e.g., explicit error behavior for a malformed IP) are absent.

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 (reanalyze) and resource (one IPv4 or IPv6 address) with the exact service (VirusTotal), which cleanly separates it from the sibling reanalyze_domain and from the get_*_report readers. 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?

Gives an explicit trigger and exclusion: 'Reanalyze only when the user explicitly requests analysis of this IP address,' which rules out speculative/pre-emptive use. It does not name the alternative tool (e.g., get_ip_report) for the non-explicit case, so routing guidance is clear but not fully complete.

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 destructiveHint=true, openWorldHint=true, idempotentHint=false, so the safety bar is lower, yet the description adds substantial context beyond them: content is shared with the VirusTotal community and partners, bytes are visible to the MCP host/model, no tool-level confirmation is added, identity/quota carry over without credentials in arguments, and existing reports short-circuit a new analysis. This is exactly the extra behavioral disclosure annotations cannot express.

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 key technical constraint is front-loaded in sentence one, but the body is a dense run of fragments with overlapping ideas ('Never downloads a URL or interprets content as a filesystem path' vs. 'A remote server cannot read your local path') and no grouping between technical limits, confidentiality warnings, and recovery guidance. Most sentences earn their place, but the structure is loose for the amount of content.

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?

With no output schema, the description still tells the agent what comes back (existing reports without a new analysis, and an analysis ID to feed to get_analysis) plus size limits, confidentiality, and failure recovery. The response object's shape is not described, but the chaining information an agent needs to proceed is present.

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 it partially does: it clarifies that content_base64 is decoded to at most 24,000,000 bytes (a tighter, decoded-size constraint vs. the schema's 32,000,000 maxLength) and that the sha256 must match those bytes. It never explains where the sha256 comes from, whether it is caller-computed, or the base64 canonicalization format, leaving real gaps for a 0%-coverage 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 a specific verb and resource: submit canonical base64 bytes matching a SHA256, with a decoded size ceiling. It actively distinguishes itself from siblings by ruling out URL submission, path interpretation, and pointing larger files to a client with file-submission capability, so an agent can separate it from submit_url and submit_local_file without opening a 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?

Explicit when-to-use (only on explicit user request), when-not (ask before sharing user documents, internal code, credentials, personal data, unfamiliar files), and alternatives/routing (get_submission for recovery, get_analysis for the returned analysis ID, a client-side capability for large files). Conditions are stated rather than implied.

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 cover the safety profile (destructive, non-idempotent, open-world), and the description adds genuinely non-derivable traits: standard submission is not confidential and content is shared with the community and partners, the tool adds no confirmation, host permissions and quota still apply, it never retries a POST, and cancelling locally does not withdraw an accepted file.

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 core action and constraint, then organized as short standalone lines, so it scans well and no sentence is filler. It is still a dense block of many statements delivered as a single paragraph, which costs it the top mark.

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 destructive, non-idempotent, open-world submission tool with no output schema, this covers everything an agent needs: identity, size and locality limits, consent policy, confidentiality consequences, confirmation and retry behavior, cancellation semantics, and how to interpret the result ('submitted/unknown is not completion or a security verdict').

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%, so the description must carry both parameters, and it largely does: 'path' is constrained to the local server's filesystem and to a single regular file of at most 32000000 bytes, and 'expected_sha256' is described as optional but required to match the hashed copy. It stops short of giving path format expectations (absolute vs relative) or SHA256 formatting, so not quite 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?

States a specific verb and resource ('Submit one local regular file... in standard mode') with explicit scope limits (single file, 32000000 bytes). The line 'Reads the local server's filesystem, never a remote client's path or a URL' separates it from submit_url and from remote-path siblings without the agent opening any 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?

Gives explicit gating conditions: submit only on an explicit user request for this file, and ask first before sharing personal documents, internal code, credentials, attachments or unfamiliar files. It also names the follow-up alternatives ('use get_submission and get_analysis'), so both when-to-use and what-to-do-next are covered.

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?

Goes well beyond annotations: discloses that VirusTotal may visit the URL and share it with community and partners including query and fragment, that no tool-level confirmation is added, that host permissions and VTAI rights/quota apply, that canonical lowercase UUIDv4 must be retained, and that the same ID is reserved for the same operation with target changes conflicting. This is rich operational context that annotations 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?

Front-loaded with the core action, then conditional guidance and operational details. Slightly dense with multiple constraints packed into a few lines, but every sentence carries necessary instruction for a destructive, non-idempotent-feeling submission 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?

Covers purpose, consent requirements, side effects (community sharing), quota/permission constraints, ID lifecycle, and recovery routing. For a destructive open-world submission tool with no output schema, this is complete enough for an agent to call correctly and recover from errors.

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%, so the description must compensate. It gives format guidance for request_id (new canonical lowercase UUIDv4, same ID reserved for same operation, changing target conflicts) and clarifies URL must be HTTP(S). It does not fully document the url parameter's constraints (length, validation), but the request_id semantics are unusually well specified.

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+resource: requesting standard VirusTotal analysis of one HTTP(S) URL. It distinguishes from sibling read tools (get_url_report) by being a submission. However it doesn't explicitly contrast with submit_file or reanalyze_domain, so 4 not 5.

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?

Explicit when-to-submit ('only when the user explicitly requests analysis of this URL'), when to ask first (URLs containing user's own documents, internal code, credentials or personal data), and error recovery routing ('use get_submission(request_id), never a new ID or an automatic POST retry'). Names the alternative tools to use after uncertainty.

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