Skip to main content
Glama

Kosmodrom

by ai.kosmodrom
OverviewDiscussionsAdmin

file_url

Read-only

Returns a file's metadata (name, mime type, type, size, upload date and author) and a signed, time-limited download URL by fid - for video, archives, design assets and other files not returned inline; downloadURL is null where the storage has no signed links. Access follows the items the file is attached to; a design file ID no longer found was replaced by a re-import. attachToken can be inserted into a spec / result as is.

Input Schema

NameRequiredDescriptionDefault
fidYesFile ID: an attaches key, the fid in attach:<fid> or a design file ID

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • removedInput schema / $schema
      Removed value: -"http://json-schema.org/draft-07/schema#"
    • removedInput schema / properties / entity
      Removed value: -{
-  "description": "Optional owner entity",
-  "properties": {
-    "ID": {
-      "description": "Owner entity ID",
-      "format": "uuid",
-      "type": "string"
-    },
-    "type": {
-      "description": "Owner entity type (task, feature, chatMessage, design, meeting...)",
-      "type": "string"
-    }
-  },
-  "required": [
-    "ID",
-    "type"
-  ],
-  "type": "object"
-}
    • changedInput schema / properties / fid / description
      Previous value: -"File ID: an attaches key and the fid in attach:<fid>"New value: +"File ID: an attaches key, the fid in attach:<fid> or a design file ID"
  2. First observed

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds real behavioral context beyond that: the URL is signed and time-limited, downloadURL may be null depending on storage, access is inherited from the items the file is attached to, and attachToken can be used as-is in a spec/result. This is a meaningful disclosure layer over the safety annotations, though it doesn't cover URL lifetime values or error behavior.

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 return payload, then edge cases and the attachToken note. It is dense and mostly earns its clauses, though the long single sentence with semicolons could be split for faster scanning.

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, so the description must explain returns, and it does: the metadata fields returned, the signed download URL, and the null-downloadURL case. Combined with the access-model note, an agent has everything needed to call and interpret it.

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 coverage is 100% and the single fid parameter is fully documented in the schema (attaches key, fid in attach:<fid>, or design file ID). The description only repeats 'by fid' without adding format or resolution semantics, so the baseline 3 applies.

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 ('Returns a file's metadata ... and a signed, time-limited download URL by fid') and scopes the resource set ('video, archives, design assets and other files not returned inline'), which implicitly separates it from the inline-retrieval sibling file_get. An agent can pick this tool without opening either schema.

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?

Gives clear context for when to use it (files not returned inline: video, archives, design assets) and covers key edge cases (downloadURL null where no signed links exist, design file IDs replaced by re-import). It never names file_get or file_upload explicitly as the alternative, so routing is inferred rather than stated.

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

All Kosmodrom toolsInspect
Try in Browser
Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources