Skip to main content
Glama

Upload attachment

jira_upload_attachment

Attach a file to a Jira issue using only a filename from the server's media directory, with path traversal and size checks enforced.

Instructions

Attaches a file from this server's media directory to an issue. name is a plain file name inside JIRA_MEDIA_DIR — paths, ".." and subdirectories are refused, so nothing else on the host can be uploaded. Requires JIRA_MEDIA_DIR and a file no larger than 50 MiB. A timeout is reported as ambiguous_write and is never retried automatically: re-read jira_list_attachments before sending the file again, or the issue ends up with two copies.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYesFile NAME inside the media directory JIRA_MEDIA_DIR names — never a path. "notes.pdf" is valid; "/etc/passwd", "../secret" and "sub/dir/file" are refused. The file must already be there; this server cannot read anything else on the host.
applyNoSet true to EXECUTE this write. Omit (or false) to get a plan of the request that would be sent. Executing also requires the server to run with JIRA_WRITE_MODE=apply.
issueYesIssue key or numeric id, e.g. ABC-1. Both forms work.
plan_idNoThe single-use id returned by the preceding plan-mode call. Required together with apply: true; a mismatch means the arguments changed since the plan, and the write is refused rather than executed.
profileNoNamed credential profile for this call. Omit to use the active profile. Rejected when the server locks the profile (JIRA_LOCK_PROFILE).
contentTypeNoMime type recorded on the attachment. Defaults to application/octet-stream.
Behavior5/5

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

Annotations only say non-idempotent and non-read-only; the description goes further by explaining the ambiguous_write timeout, the duplicate-copy risk, the never-retry policy, and the path traversal defense. This materially improves an agent's ability to use the tool safely.

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?

Four tight sentences with the main action first, followed by the file-name constraint, environment/size prerequisites, and the timeout/retry warning. Every sentence carries operational value and no filler.

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

Completeness4/5

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

The description is strong on preconditions, security, and failure handling. It leaves the plan/execute mechanics and profile-lock behavior to the rich schema descriptions, which is acceptable, though the top-level description could have referenced the plan-then-execute flow for an agent that only reads it.

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 every parameter already has descriptive text. The description adds security and size semantics for `name` (plain filename, no paths, no subdirectories, 50 MiB limit) that go beyond the schema, so it earns above the baseline.

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 and resource: 'Attaches a file from this server's media directory to an issue.' It plainly distinguishes the action from sibling list/download attachment tools and defines the upload source precisely.

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

Usage Guidelines4/5

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

It gives clear preconditions (JIRA_MEDIA_DIR must exist, file ≤50 MiB) and names the one relevant sibling (jira_list_attachments) for the retry workflow. It does not explicitly state when not to use the tool versus other attachment tools, but the upload niche is clearly scoped.

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/IvanBBaev/jira-mcp'

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