Skip to main content
Glama
Nikhilprasad-r

Redmine MCP Server

redmine_attachment_update

Update attachment metadata in Redmine by providing the attachment ID and a JSON object with the desired fields. This tool sends a PUT request to the Redmine API to apply changes.

Instructions

Update attachment metadata (PUT /attachments/:id.json).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYes
attachmentYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.1

TDQS

C2.4/5.0
Behavior2/5

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

With no annotations provided, the description carries the full burden. It implies a mutating operation (PUT) but does not disclose side effects, whether metadata is overwritten in whole or part, authentication requirements, or any consequences. It does not even explicitly state that it modifies an existing attachment. This lack of behavioral context for a mutation tool is a significant gap.

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?

The description is a single clean sentence that starts with the action and includes the endpoint. It has no wasted words and is well-front-loaded. While it is under-specifying, the conciseness itself is appropriate for the information provided.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with an open-object parameter and no output schema, this description is severely incomplete. It does not explain the valid metadata fields, the response format, error conditions, or even whether the operation is partial or full replacement. The agent is left without critical information needed to use the tool correctly.

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

Parameters1/5

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

The schema description coverage is 0%, and the description provides zero parameter information. The 'attachment' parameter is an open object (additionalProperties: {}), so the agent has no idea what properties are valid or expected. The description does nothing to clarify the structure or purpose of the attachment object, making it nearly impossible to construct a correct request without external knowledge.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a clear action: 'Update attachment metadata' and specifies the HTTP endpoint. It distinguishes itself from siblings like redmine_attachment_upload (which would handle file content) and redmine_attachment_delete. However, it doesn't explicitly name any sibling or contrast with them, so it earns a 4 rather than a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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

There is no guidance on when to use this tool versus alternatives, nor does it mention prerequisites, required permissions, or typical scenarios. The description only states what it does, leaving the agent to infer from the sibling list. This is below the minimum viable guidance.

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

Deploy Server

Other Tools