Skip to main content
Glama

write_download_media

Destructive

Download a profile photo or video by hash to a new local file, choosing an absolute save path; existing files are not overwritten, and the download is hash-checked.

Instructions

Download one of the profile's photos or videos (by hash, see read_workout or read_exercise) to a new file on this computer. saveTo is an absolute path (~/ allowed): a directory gets "."; a file name must end in the extension of the file's type (.jpg, .png, .webp, .gif, .mp4, .mov, .webm). An existing file is never overwritten. The download is checked against its hash.

Input Schema

NameRequiredDescriptionDefault
hashYes
saveToYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.1.0

TDQS

A4.4/5.0
Behavior4/5

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

Annotations declare a write/destructive/open-world operation, and the description adds concrete behavioral context beyond them: existing files are never overwritten, the file name must match the media type extension, and the download is verified against its hash. It stops short of describing failure modes or the returned value.

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?

Three tight sentences, front-loaded with the core action, then the hash source, then the saveTo rules. No filler and every clause adds operational information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a two-parameter write tool with no output schema, the description covers the payload construction and the key safety rule (no overwrite). It could still say what happens on hash mismatch or what path is reported back, but the essential call information is present.

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 0%, so the description carries the load, and it does so for saveTo (directory vs. file semantics, allowed extensions, absolute path, ~/ expansion). The hash parameter is only indirectly explained (via the pointer to read_workout/read_exercise), leaving its 64-hex format to the schema pattern.

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 (download), resource (profile photo/video), and destination (new file on this computer), plus the identity key (hash). It is clearly distinguishable from siblings like read_media_usage, write_attach_media, or delete_media.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tells the agent where the hash comes from (read_workout or read_exercise) and constrains output targets (absolute path, ~/ allowed, extension rules, no overwrite). It gives clear context for use but never states when NOT to use it or what alternative applies for other media operations.

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