Convert Base64 data into a Redmine upload token for attaching files to issues or projects. Send encoded content and filename, then use the returned token to add attachments seamlessly in Redmine workflows.
Upload attachment file from Base64 encoded content to Redmine and get upload token
| Name | Required | Description | Default |
|---|---|---|---|
| pathParams | Yes |
Changes observed during successful MCP inspections.
v1.3.2Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint: false already indicates a write operation, and the description states 'upload' which aligns with that. The description adds the behavioral detail that the operation returns an upload token, which is useful for downstream steps. However, it does not mention any side effects, authentication needs, or token lifespan, so it adds minimal context beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly packed sentence that conveys all essential information without redundancy. It is front-loaded with the action and resource, and the token outcome is mentioned. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core purpose and output (token) adequately for a simple upload operation. It clearly identifies the input format, which differentiates it from the local-file sibling. It does not mention that the token is typically used in subsequent operations, but that is arguably implied by the Redmine workflow. Given the tool's simplicity and the clarity of the description, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not add meaning beyond the input schema. The schema already provides descriptions for 'content' (Base64 encoded file content) and 'filename' (Filename to use in Redmine). The description merely repeats 'Base64 encoded content' without further elaboration. Since schema coverage is low (0% in tool description), the description should compensate, but it does not, though the schema itself is self-explanatory.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (upload), the resource (attachment file), the source (Base64 encoded content), the destination (Redmine), and the result (get upload token). It immediately distinguishes this from the sibling uploadAttachmentFromLocalFile by naming the input encoding, so an agent can tell them apart without opening schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by specifying the input type (Base64), so an agent can infer this tool is for Base64 content rather than local files. However, it does not explicitly state when to use this versus alternatives like uploadAttachmentFromLocalFile, nor does it give any exclusions or prerequisites. The context is clear but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.