Skip to main content
Glama

Upload attachment

upload_attachment

Attach a local file to an OpenProject element (work package, wiki, meeting, document, budget, or comment) with local size validation before transfer.

Instructions

Attach a local file to a work package, wiki page, meeting, document, budget or comment.

Use it when a file that already exists on the server's machine should be added to an existing container. The file's existence and its size against this instance's maximumAttachmentFileSize are checked locally first, so an oversized file fails instantly instead of after the transfer.

Returns the created attachment row (id, file_name, size_bytes, content_type, description, author, created_at, status) — the id feeds download_attachment.

Pitfalls: uploading to a container needs edit permission on that container, so to give a brand-new work package its files use create_work_package(attachment_paths=[...]) instead, which uploads the files unattached and claims them on create. Instances may restrict extensions; a rejected type comes back as validation_failed with the allowlist hint and nothing is stored. The stored name comes from file_name (or the path's basename), never from the multipart part.

Related: list_attachments shows what a container already holds; download_attachment is the reverse direction.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
file_nameNoName to store the file under, with extension. This is the only thing that decides the stored name: OpenProject ignores the multipart filename and re-detects the content type from the bytes. Defaults to the basename of file_path.
file_pathYesAbsolute path of the file to upload, on the machine running this server. Existence and size are checked locally before anything is transferred.
descriptionNoOptional caption shown next to the file in OpenProject.
container_idYesNumeric id of the container: work package id, wiki page id, meeting id, document id, budget id, or activity id for 'comment'.
container_typeYesKind of object to attach the file to. Use 'comment' to attach to a work-package comment and pass its activity id as container_id.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
idNoAttachment id; pass it to download_attachment.
authorNoUser who uploaded the file.
statusNoVirus-scan state: 'uploaded'/'scanned' are downloadable, 'quarantined' is not, anything else is still being scanned.
file_nameNoStored file name including extension.
created_atNoISO 8601 UTC upload timestamp.
size_bytesNoFile size in bytes.
descriptionNoCaption stored with the file.
content_typeNoMIME type detected by OpenProject from the bytes.
Behavior5/5

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

The description discloses substantial behavioral detail beyond annotations: local existence/size pre-checks causing instant failure, the edit-permission requirement on the container, extension-restriction behavior with validation_failed and allowlist hint, and the filename source (file_name vs multipart). This fully surfaces operational traits without contradicting the annotation hints (readOnlyHint=false, destructiveHint=false).

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 long but every sentence adds value: usage, pre-check behavior, return fields, pitfalls, alternative tool, and related tools. It is structured into clear scannable segments and avoids redundancy with the schema. For a tool with this complexity, the length is warranted.

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?

The description covers permissions, error conditions (extension restrictions, oversized files), naming semantics, the return row and its downstream use (id feeds download_attachment), and guidance for the brand-new container case. With an output schema present and five parameters, nothing essential is left unexplained.

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% and each parameter already has a thorough description, so the baseline is 3. The description adds extra semantics for file_name ('This is the only thing that decides the stored name... ignores the multipart filename') and clarifies container_id usage for comment (activity id). These additions go beyond the schema, justifying a 4.

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: 'Attach a local file to a work package, wiki page, meeting, document, budget or comment.' This clearly distinguishes it from sibling tools like download_attachment, list_attachments, and delete_attachment while naming the exact containers it targets.

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 guidance is given: 'Use it when a file that already exists on the server's machine should be added to an existing container.' It also names an alternative with a concrete parameter hint: 'to give a brand-new work package its files use create_work_package(attachment_paths=[...]) instead.' Related tools are listed for reverse operations.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/kar-thik/openproject-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server