Skip to main content
Glama

List attachments

list_attachments
Read-onlyIdempotent

List attachments on an OpenProject container (work packages, wiki pages, meetings, documents, budgets, comments) with IDs, sizes, and virus-scan status to identify downloadable files before downloading.

Instructions

List the files attached to one container.

Containers are work packages, wiki pages, meetings, documents, budgets and comments. Use this to discover attachment ids before calling download_attachment, or to check what a work package already carries. The upstream collection is not paginated, so it is fetched in full: the envelope always reports has_more=false and a total equal to the row count.

Returns the standard list envelope; each row has id, file_name, size_bytes, content_type, description, author, created_at and status. status is the virus-scan state — 'uploaded' and 'scanned' are downloadable, 'quarantined' files are not, and anything else is still being scanned and is readable only by its uploader.

Pitfalls: container_id identifies the container, not the file. A 404 means the container does not exist or the module providing it (meetings, budgets, documents) is not enabled on this instance. Forum posts are a valid API container but have no discovery path here.

Related: download_attachment fetches the bytes for one row, upload_attachment adds a file to the same containers, and get_work_package(include=['attachments']) returns these rows inline for a single work package.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
container_idYesNumeric id of the container itself: the work package id, wiki page id, meeting id, document id, budget id, or activity id. Never an attachment id.
container_typeYesKind of object that owns the files. Use 'comment' for files attached to a work-package comment — those live on the activity, so pass the activity id from list_work_package_comments as container_id.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
sumsNoPresent only when show_sums was requested.
itemsNoThe page of results.
notesNoDegradation markers: capped aggregations, unavailable modules, …
groupsNoPresent only when group_by was requested.
paginationYesTotal/page/page_size/has_more.
Behavior5/5

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

The description discloses significant behavioral traits beyond the annotations: the upstream collection is not paginated and has_more is always false; the status field represents virus-scan state with downloadable vs. quarantined values; and a 404 can indicate an invalid container or a disabled module. This adds context that the readOnly and idempotent hints do not cover.

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 structured logically with a clear first sentence, then a definition of containers, usage guidance, return format, pitfalls, and related tools. Every sentence earns its place; there is no unnecessary verbosity. It is long but information-dense and well-organized.

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 tool's moderate complexity (multiple container types, virus scan status, pagination behavior), the description covers all necessary aspects: what it does, when to use it, return row fields, pitfalls, and related tools. The presence of an output schema is acknowledged but the description still explains the envelope and status semantics, making it complete for an agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

While the schema already provides descriptions for both parameters, the description adds crucial semantics: 'container_id identifies the container, not the file,' and explains that container_type='comment' requires passing an activity id from list_work_package_comments. This extra detail goes beyond the schema, clarifying ambiguous cases.

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 begins with 'List the files attached to one container,' which is a specific verb+resource statement. It defines containers as work packages, wiki pages, meetings, documents, budgets, and comments, and explicitly differentiates itself from related tools like download_attachment, upload_attachment, and get_work_package(include=['attachments']).

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?

The description explicitly states when to use the tool: 'Use this to discover attachment ids before calling download_attachment, or to check what a work package already carries.' It also names alternatives in the 'Related' section, clarifying when not to use this tool. Pitfalls, such as the 404 meaning, further guide usage context.

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