Extend MCP

Get the result of a user file upload

get_file_upload

Read-onlyIdempotent

Get the status and uploaded file ids of an upload link created by upload_file (files group). Default is one instant status check; wait: true blocks until the user finishes or the wait budget runs out. Statuses: pending (the user has not completed the upload — call again with wait: true once they say they are done); completed (files lists the uploaded file ids, usable as { "id": "file_..." } inputs in any file-accepting tool); expired or cancelled (the link is no longer usable — call upload_file for a fresh one).

Input Schema

TableJSON Schema

Name	Required	Description
`wait`	No	true = block until the user completes the upload or the wait budget runs out. Default false: one instant status check.
`uploadId`	Yes	Upload session id (upl_...) from upload_file.
`environment`	Yes	"TEST" = the Test (development) environment, "PRODUCTION" = live. Must match a granted target from get_me (an API key pins one environment).
`workspaceId`	Yes	Target workspace (ws_...). Must be a granted workspace — get_me lists the accepted values.

Output Schema

TableJSON Schema

Name	Required	Description
`files`	No	Present once completed: the uploaded file ids.
`status`	Yes	pending \| completed \| expired \| cancelled
`uploadId`	Yes
`expiresAt`	No	Present while pending: when the link stops accepting uploads.
`completedAt`	No
`completedBy`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedSep 20, 2026

changedInput schema / properties / uploadId / description

Previous value: -"Upload session id (upl_...) from request_file_upload."New value: +"Upload session id (upl_...) from upload_file."

addedOutput schema / properties / expiresAt / description

Added value: +"Present while pending: when the link stops accepting uploads."

addedOutput schema / properties / files / description

Added value: +"Present once completed: the uploaded file ids."

removedOutput schema / properties / llmContext
```
Removed value: -{
-  "type": "string"
-}
```

addedOutput schema / properties / status / description

Added value: +"pending | completed | expired | cancelled"

First observedSep 3, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Annotations already mark the tool as read-only, idempotent, and non-destructive. The description adds valuable behavioral context beyond that: wait-budget blocking, status transitions, and that completed file ids are usable as file_ inputs in other tools. No contradiction with annotations.

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?

The description is dense but well-organized: purpose first, then wait behavior, then statuses with follow-up actions. Every sentence contributes necessary information without padding.

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?

Given the annotations, full parameter schema, and output schema, the description covers all the behavior an agent needs to decide when to call this tool and how to interpret its result. Status semantics and next steps are fully specified.

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 100%, so the baseline is 3. The description adds extra operational meaning beyond the schema: what pending means in practice, when to retry with wait:true, and that completed ids become valid file_ references. This pushes it above baseline, though it does not fundamentally compensate for missing schema documentation.

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?

The description names a specific verb and resource: get status and uploaded file ids of an upload link created by upload_file. It clearly distinguishes this from upload_file (which creates the link) and get_file (which retrieves file content).

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?

It gives explicit guidance on the wait parameter, explains what each status means, and prescribes the next action: call again with wait:true while pending, use the file ids once completed, or call upload_file for a fresh link when expired/cancelled. This is actionable and resolves ambiguity.

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

All Extend MCP tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?