Skip to main content
Glama
Sign In

Kosmodrom

by ai.kosmodrom
OverviewDiscussionsAdmin

file_upload

Uploads a file for attachment: attachToken goes into a task, bug or feature spec / result, fid into chat message attachments; one fid can be attached in several places. With dataBase64 (up to 2097152 bytes) the file is saved at once. Without it, provide the exact size in bytes (up to maxSize), PUT the file to uploadURL using the required headers from the ticket (Content-Length must match size), then complete the upload by calling file_upload with fid. Files cannot be deleted through MCP.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "file_upload"
  }
}

Input Schema

NameRequiredDescriptionDefault
fidNofid of a URL upload whose content has been PUT - completes the upload.
nameNoFile name with extension, e.g. "screenshot.png"; the extension sets the type
sizeNoExact file size in bytes; required for upload via URL and must match PUT Content-Length
dataBase64NoFile content in base64, up to 2097152 bytes; omitted for upload via URL

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / size
      Added value: +{
+  "description": "Exact file size in bytes; required for upload via URL and must match PUT Content-Length",
+  "exclusiveMinimum": 0,
+  "type": "integer"
+}
  2. Changed3 schema fields changed
    • removedInput schema / $schema
      Removed value: -"http://json-schema.org/draft-07/schema#"
    • addedInput schema / properties / fid
      Added value: +{
+  "description": "fid of a URL upload whose content has been PUT - completes the upload.",
+  "format": "uuid",
+  "type": "string"
+}
    • removedInput schema / required
      Removed value: -[
-  "name"
-]
  3. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations only establish readOnlyHint=false, destructiveHint=false, openWorldHint=false; the description adds real behavioral context on top: hard size caps (2097152 bytes / maxSize), the multi-step PUT handshake, the requirement that Content-Length match size, re-attachment of one fid in several places, and the explicit absence of any delete path. That is substantive disclosure beyond structured fields.

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 two-mode upload flow is front-loaded and every clause carries operational weight (limits, header requirements, finalization step). It is dense and long-ish for a single paragraph, but nothing is filler; splitting the base64 path and URL path would improve scanability slightly.

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?

With no output schema and a 4-param write tool, the description compensates fully: it explains both upload paths end to end, the size limits, what uploadURL and attachToken/fid are for after the call, and the deletion limitation. An agent has everything needed to invoke it correctly in either mode.

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 coverage is already 100%, so baseline is 3; the description earns more by explaining what each value is *for* (attachToken for tasks/bugs/feature specs, fid for chat attachments and to finalize URL uploads, base64 size ceiling). Minor friction: attachToken is discussed as a key concept but is not a declared parameter, which could momentarily confuse an agent mapping inputs.

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?

Opens with a specific verb+resource ('Uploads a file for attachment') and immediately disambiguates the tool's role versus the related file retrieval siblings by explaining where attachToken vs fid are consumed. An agent can identify this as the write-side upload tool without consulting the 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 explicit operating guidance for both modes: with dataBase64 the file is saved at once, without it the agent must provide size, PUT to uploadURL with ticket headers, and then call file_upload with fid to complete. It also states a clear negative constraint ('Files cannot be deleted through MCP'), though it never names which sibling to use for retrieval or how this compares to file_url/file_get.

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
Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources