Skip to main content
Glama

MCP for Claude & ChatGPT

Upload a file

file_upload_url

Get a short-lived URL to upload ONE file from disk to Tuqui, without retyping it. Only for a client that can run commands: you run curl on the file in your disk. Without a shell (a web chat), ask the user to attach the file in Odoo instead. Pass the file's size in bytes and its sha256, read from the commands: the upload is refused unless what arrives matches both. Returns a ready curl command and a reference 'tuqui-upload:' that stands for the file in ONE later call: upload_refs of odoo_message_post attaches it to a record's chatter, an image goes inside an html field as alt with odoo_html or odoo_write, and upload_files of odoo_create / odoo_write puts it in a Binary field. Up to 10 MB: images, PDF, CSV, text, JSON, office, zip and audio.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "filename": "<filename>",
      "mimetype": "<mimetype>",
      "size": "<size>",
      "sha256": "<sha256>"
    },
    "name": "file_upload_url"
  }
}

Input Schema

NameRequiredDescriptionDefault
sizeYesSize in bytes, from `stat -c %s <file>` (or `wc -c < <file>`).
sha256YesSHA-256 of the file's bytes, in hex — the output of `sha256sum <file> | cut -d' ' -f1`. Read it from the command; do not compute it yourself.
filenameYesThe file's name as it should appear in Odoo, e.g. 'captura.png'.
mimetypeYesThe file's MIME type, e.g. 'image/png' or 'text/csv'.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.6/5.0
Behavior4/5

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

Goes well beyond the annotations, which only say it is a non-read-only, non-destructive, closed-world operation. The description discloses the short-lived URL lifetime, the integrity precondition ('the upload is refused unless what arrives matches both' size and sha256), the 10 MB ceiling, and a supported-format list — none of which appear in structured fields. The only modest gap is that it does not say how long the URL stays valid.

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 core action and the client precondition before any downstream plumbing. The prose is dense — long colon-chained sentences packing ref-lifecycle detail — which costs some readability, but no sentence is filler.

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?

For a four-required-param tool with no output schema, the description supplies everything an agent needs: the return value shape (a ready curl command plus a 'tuqui-upload:<id>' ref), how that ref is consumed in later calls, the size limit, and the shell-vs-chat fallback. Nothing material is left to inference.

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 schema already defines all four fields and their derivation commands, making 3 the baseline. The description adds meaning above that by framing size and sha256 as a validation contract that can cause refusal, and by emphasizing 'ONE file' as a hard cardinality constraint on each call.

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 — 'Get a short-lived URL to upload ONE file from disk to Tuqui' — and immediately distinguishes itself from attachment-based siblings by requiring a shell-capable client. An agent can tell from the first sentence that this does not upload anything itself; it mints an upload target.

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?

Explicit when-to-use ('Only for a client that can run commands: you run curl on the file in your disk'), explicit when-not with a concrete alternative ('Without a shell (a web chat), ask the user to attach the file in Odoo instead'), and it names the three downstream consumers of the returned ref with the exact field for each.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.