md-doc

file_upload

Adjunta un archivo a una nota, issue o línea de registro (como "Adjuntos" en la web; en una carpeta compartida hace falta rol editor y el archivo cuenta en el espacio del dueño). El contenido va en el mensaje: texto tal cual (encoding "text", p. ej. un .md, .csv o .txt que generes) o binario en base64 (encoding "base64", también vale una data URL), hasta 5 MB. Si el archivo está en disco y tienes terminal, o pesa más, usa file_upload_link: no pasa el contenido por la conversación. Tipos admitidos: PDF, Office/OpenDocument, imágenes, texto/CSV/JSON/XML y comprimidos. target: note (nota), issue, task (tarea recurrente) o expedient_line (registro/expediente: los adjuntos de un registro van en una de sus líneas de actuación; búscala con expedient_lines_list o créala con expedient_line_add). id: el de ese elemento.

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": {
      "target": "<target>",
      "id": "<id>",
      "filename": "<filename>",
      "content": "<content>"
    },
    "name": "file_upload"
  }
}

Input Schema

Name	Required	Description
`id`	Yes	ID de la nota, issue, tarea recurrente o línea de registro
`target`	Yes	Dónde está el adjunto
`content`	Yes	Contenido: texto o base64 según encoding
`encoding`	No	text (por defecto) o base64
`filename`	Yes	Nombre con extensión, p. ej. "informe.pdf"; de ella sale el tipo
`mimeType`	No	Tipo MIME si la extensión no basta

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 12, 2026

TDQS

A4.4/5.0

Behavior3/5

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

No annotations are supplied, so the description carries the full behavioral burden, and it does well: it discloses the 5 MB cap, that content transits the conversation, that a shared folder requires the editor role, that the file consumes the owner's quota, and which file types are accepted. It does not cover error behavior, overwrite/duplicate handling, or the shape of the response, which is a meaningful gap for a mutation tool with zero annotation coverage.

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 action and scope, then limits, then the alternative, then parameter clarification – a sensible order. It is a single dense paragraph with several parentheticals that could be split for scannability, but every sentence carries usable information.

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 six-parameter mutation tool with no annotations and no output schema, the description covers limits, encoding semantics, role/quota implications, accepted file types, alternative routing, and the indirection through expedient_line. Nothing an agent needs in order to call it correctly is missing.

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, but the description adds real meaning: it explains that content is raw text under encoding "text" (e.g. a .md or .csv you generate) or base64/data-URL under "base64", and it unpacks the four target values, noting that expedient_line attachments live on an actuación line that must be found or created first. id is tied to that target element, reinforcing the relationship the schema only states flatly.

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 opens with a specific verb + resource: 'Adjunta un archivo a una nota, issue o línea de registro', and immediately distinguishes the operation from its sibling file_upload_link. An agent can tell exactly what the tool does and where the file lands (note, issue, task, expedient_line) without opening 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 Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It names the alternative explicitly and the condition that selects it: if the file is on disk and a terminal is available, or it exceeds 5 MB, use file_upload_link instead. It also explains the expedient_line case, directing the agent to expedient_lines_list or expedient_line_add to locate or create the line – the only route whose prerequisite is non-obvious.

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

All md-doc 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?