upload_fileFree file hosting (up to 200 MB) for sharing. Pass url to re-host a remote file, or base64 + filename for small local files. For big local files use: curl -F file=@path /v1/files.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | Public URL of the file to re-host. | |
| base64 | No | File contents as base64, when there is no URL. | |
| filename | No | File name with extension, e.g. report.pdf. |
Changes observed during successful MCP inspections.
Input schema / properties / base64 / descriptionAdded value: +"File contents as base64, when there is no URL."Input schema / properties / filename / descriptionAdded value: +"File name with extension, e.g. report.pdf."Input schema / properties / url / descriptionAdded value: +"Public URL of the file to re-host."Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, openWorldHint=true, idempotentHint=false and destructiveHint=false, so the safety profile is covered. The description adds real context beyond that: the 200 MB ceiling, the re-host vs. local-bytes distinction, and the raw-HTTP escape hatch. It does not acknowledge non-idempotency or state that each call yields a new hosted artifact, which is the remaining behavioral gap.
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 sentences, both front-loaded with the highest-value information (size limit and destination first, mode selection second, fallback last). No filler or restatement of the tool 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?
Covers input modes, size limits and the out-of-band path, which is what an agent needs to invoke it correctly. With no output schema, the description arguably should mention that the call returns a hosted/shareable URL, and it does not state auth or permissions; those are the only omissions.
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 description coverage is 100%, so the baseline is 3, but the description adds genuine semantics: 'url' is for re-hosting an existing remote file while 'base64' requires pairing with 'filename' for small local files. That pairing rule and the size threshold are not expressed in the schema itself.
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?
States a specific verb+resource ('upload_file' / 'Free file hosting... for sharing') and quantifies scope with the 200 MB cap. It also names the two supported input modes, so an agent immediately understands what the tool accepts and produces; no sibling in the list does anything comparable, so no differentiation is needed.
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?
Explicitly routes the agent: 'Pass url to re-host a remote file, or base64 + filename for small local files,' and gives the exclusion case with a concrete fallback ('For big local files use: curl -F file=@path <base>/v1/files'). Both when-to-use and when-not-to-use are covered with actionable alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.