Skip to main content
Glama
VirusTotal

VirusTotal MCP

Official

Get a VirusTotal URL report

get_url_report
Read-onlyIdempotent

Retrieve existing threat intelligence for an HTTP(S) URL without visiting or submitting it; use domain report when domain-level scope is enough.

Instructions

Look up existing intelligence for an HTTP(S) URL, without visiting or submitting it.

The full URL is shared with VTAI and VirusTotal, including query and fragment. Avoid URLs containing secrets; use get_domain_report when domain scope is sufficient. VTAI normalizes the indicator and applies its query quota. Unknown stays unknown.

Input Schema

NameRequiredDescriptionDefault
urlYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.9.1

TDQS

A4.9/5.0
Behavior5/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.