Skip to main content
Glama

submit_sample

Submit suspicious files or URLs to a cloud detonation sandbox for malware analysis. Supports Hybrid Analysis, Triage, and ANY.RUN backends.

Instructions

Submit a suspicious file or URL to a cloud detonation sandbox.

WARNING: on the free tiers of Hybrid Analysis and tria.ge, submitted files/URLs and their analysis results are PUBLIC and shared with third parties; tria.ge community submissions cannot be deleted. Do not submit confidential or internal files unless you are using a private/enterprise instance.

Because of that, for the 'hybrid_analysis' and 'triage' backends this tool REFUSES to submit unless acknowledge_public_submission=true. First call without it to receive the warning, confirm with the user, then re-call with acknowledge_public_submission=true.

This tool returns IMMEDIATELY with a task_id; detonation runs asynchronously and typically takes 2-10 minutes. Poll the result with get_report(task_id), respecting its poll_after_seconds hint.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
targetYesLocal file path (target_type='file') or an http(s) URL (target_type='url'). Files are uploaded as-is; this server never executes them locally.
sandboxYesDetonation backend: 'hybrid_analysis', 'triage', or 'anyrun' (anyrun requires a paid plan key). 'malwarebazaar' cannot detonate -- use search_hash for static hash intel instead.
environmentNoOptional VM/environment selector. Hybrid Analysis accepts an environment id ('100','110','120','140','200','300') or a fuzzy name ('win10', 'windows 11', 'linux', 'android'); default is Windows 10 64-bit. tria.ge auto-selects and ignores this. ANY.RUN passes it through as env_os.
target_typeYes'file' or 'url'.
acknowledge_public_submissionNoMust be true to actually submit to the public-tier backends (hybrid_analysis, triage) -- see the warning above.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Behavior5/5

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

With no annotations provided, the description fully discloses key behaviors: immediate return with task_id, asynchronous detonation (2-10 min), polling via get_report, refusal without acknowledge_public_submission=true, and public data implications. This adds significant value beyond the schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

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

The description is front-loaded with the main purpose and structured with warnings and workflow steps. While it has multiple paragraphs, every sentence earns its place given the complexity of the tool. Could be slightly shorter but still efficient.

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?

Given 5 parameters, 100% schema coverage, output schema present, and sibling tools listed, the description is highly complete. It covers return behavior (task_id), asynchronous nature, polling, public submission handling, and limitations of backends, leaving no major gaps.

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?

Schema description coverage is 100%, so baseline is 3. The description adds meaning beyond the schema by explaining the two-step submission process (first call without ack, then with ack) and the warning about public tiers, which enriches parameter understanding.

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?

The description clearly states the verb 'Submit' and resource 'suspicious file or URL to a cloud detonation sandbox'. It distinguishes from siblings like search_hash (for static intel) and get_report (for polling results), making the purpose specific and unambiguous.

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?

The description provides explicit when-to-use guidance, including a two-step workflow for public backends, warning about public data, and alternatives like using search_hash for malwarebazaar. It also notes paid plan requirement for anyrun, giving comprehensive usage instructions.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/inadvisable-hibiscusfarragei279/Malware-Sandbox-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server