Generate signed download URLs for dataset file keys from list_files so authenticated users can retrieve Parquet files; the first download each month counts toward plan allowance.
Signed download URLs for file keys from list_files. Needs KALSHIEYE_API_KEY.
The first download of a file in a month counts toward the plan's monthly allowance.
| Name | Required | Description | Default |
|---|---|---|---|
| keys | Yes |
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds real context beyond the annotations: an API key is required, and quota is consumed on a per-file, first-download-of-the-month basis. This explains the otherwise puzzling readOnlyHint=false and complements idempotentHint=true (repeat downloads in a month do not double-charge). It does not mention URL expiry or whether one URL is returned per key.
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?
Two short sentences, front-loaded with the core purpose, followed by the two facts an agent cannot infer (auth and quota). No filler or restated name.
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 one-parameter tool with an output schema covering the return shape, auth and billing context are the main gaps and both are addressed. Missing only operational details like URL lifetime and maximum keys per request.
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 'keys' parameter, so the description carries the burden — and it does, stating that keys are file keys obtained from list_files. That is the key missing semantic. It does not say whether keys must be exact matches or how many can be batched per call.
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?
The description names a specific output (signed download URLs) for a specific resource (file keys), and anchors the resource to the sibling tool that produces it (list_files). An agent can tell this apart from search, get_series, or list_files without 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?
It clearly implies the usage chain: call list_files first, then pass those keys here. The auth prerequisite (KALSHIEYE_API_KEY) is stated explicitly. It stops short of naming when not to use it or any limits on batch size, so it is strong but not exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.