Skip to main content
Glama

get_download_url

Read-only

Generate a signed, 1-hour download URL for a dataset you can access: use dataset_id for free data or purchase_id for paid data; call again after expiry.

Instructions

Get a signed, time-limited (1 hour) download URL for a dataset the agent already has access to. All full downloads require account authentication. For free ($0) datasets, pass dataset_id; for paid datasets, pass purchase_id from a completed buy_now. URLs expire after 1 hour — call again for a fresh one. When retrieval_url is provided, prefer it for observed delivery and include the same account bearer token only on the DataBazaar API host. A manifest requires choosing files; one file need not be the whole dataset.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dataset_idNoDataset ID — use this for free ($0) datasets. Account authentication required; no purchase needed.
purchase_idNoPurchase ID from buy_now — use this for paid datasets.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.5.1

TDQS

A4.5/5.0
Behavior5/5

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

Annotations only carry readOnlyHint=true, but the description adds substantial behavior beyond them: the URL is signed and expires in one hour, all full downloads require account authentication, and the bearer token should only be sent on the DataBazaar API host even when a retrieval_url is provided. These are exactly the constraints an agent needs to act safely.

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?

Front-loaded with the core purpose and expiry, then conditions. The 'When retrieval_url is provided...' sentence is dense and references an entity that is not a parameter or sibling, adding mild ambiguity rather than clean guidance.

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 read-only tool with no output schema, the description covers auth, expiry, routing, and manifest expectations well. It stops short of describing what the call returns (e.g. a URL string) and leaves the retrieval_url sentence contextually unexplained.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and the schema already states the free-vs-paid routing for both parameters, so the description largely repeats structured data. The conditional logic adds a little reinforcement but no new syntax or edge cases beyond what the schema documents.

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 ('get a signed, time-limited download URL for a dataset') and immediately scopes it to a dataset the agent already has access to, which cleanly separates it from get_upload_urls and get_dataset.

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?

Explicitly routes the agent: dataset_id for free ($0) datasets, purchase_id from a completed buy_now for paid ones, with authentication called out. It also states the expiry fallback ('call again for a fresh one') and the manifest caveat, leaving little to inference.

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