a2atlassian is an MCP server that gives AI agents secure, read-only-by-default access to Jira (with Confluence planned).
Connection Management:
login — Save an Atlassian connection (validates credentials, supports ${ENV_VAR} token references, read-only by default)
logout — Remove a saved connection
list_connections — List all saved connections without exposing secrets
Supports ephemeral in-memory connections (--register) and connection scoping (--scope) to limit agent access to specific projects
Jira — Read Operations:
jira_get_issue — Retrieve a full Jira issue by key (fields, status, assignee, etc.)
jira_search — Search issues using JQL with pagination (compact TSV output for token efficiency)
jira_get_comments — Fetch all comments for a specific issue
jira_get_transitions — Discover available status transitions for an issue
Jira — Write Operations (requires explicit read-write connection):
jira_add_comment — Add a comment to an issue
jira_edit_comment — Update an existing comment
jira_transition_issue — Move an issue to a new status
Key Design Features:
Read-only by default — write tools require explicit opt-in per connection
Compact TSV output for lists (30–60% fewer tokens), JSON for single entities
Robust error enrichment with field name suggestions and JQL corrections
Built-in rate limiting with exponential backoff
Credentials stored securely (file permissions 0600, never exposed in output)
Works as an MCP server (Claude/Cursor) or standalone CLI; installs via pip/uv without Docker
Roadmap: Full Jira surface (sprints, boards, links, worklogs, attachments) and Confluence integration (pages, comments, search).
Provides AI agents with access to Atlassian Cloud services (Jira and Confluence) through pre-configured connections with scoped access controls, read-only defaults, and support for multiple projects.
Planned support for managing Confluence pages, comments, attachments, labels, and search functionality (Phase 3 roadmap).
Enables issue management via JQL search, status transitions, and comment operations (add/edit) with compact TSV output for lists and error enrichment for invalid fields or JQL syntax.
Agent: "What's the status of PROJ-42? Add a comment with the progress update."
↓
a2atlassian → get issue, add comment, transition to In Progress
↓
Agent: "Done — PROJ-42 updated and moved to In Progress."Existing Atlassian MCP servers (Rovo, sooperset) require Docker, .env files, and mcp-remote bridges. They dump 72 tools into agent context and have known quirks that silently fail. a2atlassian fixes all of that:
No Docker — pip install a2atlassian and you're done
Pre-configured connections — define projects in .mcp.json with --register, agent works immediately
Read-only by default — write access is opt-in per connection
Connection scoping — --scope limits which projects an agent can see
Compact output — TSV for lists (30-60% fewer tokens), JSON for single entities
Dynamic tool loading — MCP clients that support deferred tools (e.g., Claude Code) load tools on demand, keeping context lean
Error enrichment — bad field names get suggestions, JQL typos get corrections, quirks get auto-fixed
Secrets stay in env — ${ATLASSIAN_TOKEN} in configs, expanded only at runtime
Scope today: full Jira surface (issues, comments, sprints, boards, worklogs, links, versions, fields, watchers, projects) and Confluence core (pages CRUD, search, metadata-only writes).
Related MCP server: atlassian-mcp-server
# Recommended — installs globally as a CLI tool
uv tool install a2atlassian
# Or with pip
pip install a2atlassianClaude Code (with pre-configured connection):
claude mcp add -s user a2atlassian -- uvx --from a2atlassian a2atlassian-mcp \
--register myproject https://mysite.atlassian.net user@company.com '${ATLASSIAN_TOKEN}'Claude Code (minimal — agent calls login on demand):
claude mcp add -s user a2atlassian -- uvx --from a2atlassian a2atlassian-mcpClaude Desktop / Cursor / any MCP client (.mcp.json):
{
"mcpServers": {
"a2atlassian": {
"command": "uvx",
"args": [
"--from", "a2atlassian", "a2atlassian-mcp",
"--register", "myproject", "https://mysite.atlassian.net",
"user@company.com", "${ATLASSIAN_TOKEN}"
],
"env": {
"ATLASSIAN_TOKEN": "your-api-token-here"
}
}
}
}Multiple projects:
{
"args": [
"--from", "a2atlassian", "a2atlassian-mcp",
"--register", "myproject", "https://mysite.atlassian.net", "user@a.com", "${TOKEN_A}",
"--register", "personal", "https://personal.atlassian.net", "user@b.com", "${TOKEN_B}"
]
}Scoped connections (limit agent to specific saved projects):
{
"args": ["--from", "a2atlassian", "a2atlassian-mcp", "--scope", "myproject"]
}--register creates ephemeral in-memory connections (process lifetime, no files written). --scope filters which saved connections are visible. Both limit blast radius.
# Save a connection (validates by calling /myself)
a2atlassian login -c myproject \
--url https://mysite.atlassian.net \
--email user@company.com \
--token "$ATLASSIAN_TOKEN"
# Same, pulling the token from 1Password via `op`
a2atlassian login -c myproject \
--url https://mysite.atlassian.net \
--email user@company.com \
--token "op://Personal/Atlassian/token"
# Enable writes
a2atlassian login -c myproject \
--url https://mysite.atlassian.net \
--email user@company.com \
--token "$ATLASSIAN_TOKEN" \
--no-read-only
# List / remove connections
a2atlassian connections
a2atlassian logout -c myprojectTokens accept three forms: literal value, ${ENV_VAR} reference, or
op://vault/item/field (resolved via the 1Password CLI at runtime).
Tool | Description |
| Save a connection — validates by calling /myself first |
| Remove a saved connection |
| List connections (no secrets exposed) |
Tool | Description |
| Get issue by key — full fields, status, assignee |
| Search by JQL with pagination — compact TSV output by default |
| Count-only JQL — cheap pre-check for "is this going to be huge?" |
| Discover custom-field IDs by name |
| List allowed values for a select / multi-select field |
| Get all comments for an issue |
| Get all worklogs for an issue |
| Discover available status transitions |
| List available issue-link types |
| List watchers for an issue |
| List projects accessible to the connection |
| Fetch creation metadata (issue types, required fields) |
| Resolve an email/accountId to a full user profile |
| List agile boards in a project |
| Issues on a board (paginated) |
| List sprints on a board |
| Issues in a sprint (paginated) |
Tool | Description |
| Create a new issue |
| Update fields on an existing issue |
| Delete an issue |
| Move issue to a new status |
| Add comment (wiki markup, API v2) |
| Update existing comment |
| Log time on an issue |
| Link two issues |
| Remove an issue link |
| Replace the watcher set on an issue |
| Create a sprint on a board |
| Update sprint state / dates |
| Move issues into a sprint |
| Create a project version |
Tool | Description |
| Fetch a page by id (body storage, version, space) |
| List direct children of a page (paginated) |
| CQL search; minimal per-match rows |
Tool | Description |
| Batch create-or-update with preserve-on-omit body semantics + per-page status + partial-failure shape |
| Metadata-only write (page_width, emoji, labels) — physically cannot touch body or title |
All tools accept a format parameter:
Format | Default for | Description |
| Lists (search, comments) | TSV with header — shape once, data many. 30-60% fewer tokens than JSON |
| Single entities (get_issue) | Standard JSON with metadata envelope |
List responses use a compact TSV-style format (header row + tab-separated values) inspired by TOON. This is the same approach a2db uses — column names appear once, then just values. For a 50-issue search result, this typically saves 40-60% of tokens compared to JSON.
TSV example (search results):
# search (23 results, 50ms, truncated: False)
key summary assignee status
PROJ-142 Fix auth timeout Alice Smith In Progress
PROJ-141 Add search filters Bob Jones To DoJSON example (single issue):
{
"data": {"key": "PROJ-142", "fields": {"summary": "Fix auth timeout", ...}},
"count": 1,
"truncated": false,
"time_ms": 85
}When something fails, a2atlassian tells the agent what to do:
Field 'asignee' does not exist
Did you mean: assignee?Connection 'myproject' is read-only.
Run: a2atlassian login -p myproject --read-only falseQuirks handled automatically:
Assignee requires display name (not 712020: account IDs) — auto-detected with hint
Parent field must be plain string — {"key": "PROJ-14"} normalized to "PROJ-14" silently
Issue type conversion not supported via API — clear Jira UI instructions provided
Every connection starts read-only. Write tools check the connection flag before executing:
Connection 'myproject' is read-only.
Re-run 'a2atlassian login -p myproject --read-only false' to enable writes.The human operator controls write access — not the agent.
Connections saved via login go to ~/.config/a2atlassian/connections/ as TOML files:
File permissions: 0600 (owner read/write only)
${ATLASSIAN_TOKEN} syntax — env var references stored literally, expanded at runtime
No secrets in output — list_connections shows project name, URL, and mode — never tokens
Ephemeral mode — --register keeps credentials in memory only, never written to disk
Use --scope to limit which saved connections a specific MCP instance can access:
# Project config — only myproject visible, even if other connections are saved
uvx --from a2atlassian a2atlassian-mcp --scope myprojectProject-level MCP configs (.claude/mcp.json) override global configs — each repo sees only its own connections.
Built-in retry with exponential backoff for Atlassian's rate limits (429) and transient server errors (500). Two retries at 1s and 3s intervals before surfacing the error.
Feature | a2atlassian | Rovo (official) | sooperset/mcp-atlassian |
Setup |
| OAuth + Docker | Docker + .env + mcp-remote |
Tools in context | ~35 (loaded on demand) | ~72 | ~72 |
Connection management | TOML + | Per-session OAuth | .env file |
Multi-project | Yes (scoped) | No | One .env per setup |
Read-only default | Yes (per-connection) | No | No |
Output format | TSV + JSON | JSON | JSON |
Error enrichment | Field suggestions, quirk fixes | Generic errors | Generic errors |
Quirk handling | Auto-fix (assignee, parent) | Documented workarounds | Documented workarounds |
Rate limiting | Built-in retry | No | No |
CLI | Yes | No | No |
License | Apache 2.0 | Proprietary | MIT |
Shipped: Jira full surface (v0.3.0) · Confluence core + markdown-to-storage with full CommonMark + GFM fidelity (v0.4.0, v0.5.2) · 1Password op:// token refs (v0.5.1) · metadata-only Confluence writes + preserve-on-omit body semantics (v0.5.2).
Next: confluence_delete_page, Confluence comments + attachments, Confluence integration-test path. Backlog in TODO.md.
# Recommended
uv tool install a2atlassian
# Or with pip
pip install a2atlassian
# CLI
a2atlassian login -p myproject --url https://mysite.atlassian.net --email me@co.com --token "$TOKEN"
# Or add as MCP server (see Quick Start)uv tool install a2atlassian
# Pre-configured — no login needed
uvx --from a2atlassian a2atlassian-mcp --register ci https://mysite.atlassian.net ci-user@co.com "${CI_ATLASSIAN_TOKEN}"make bootstrap # Install deps + pnpm + git hooks
make check # Lint + test + coverage-diff + security (full gate)
make test # Tests with coverage
make lint # agent-harness + jscpd + actionlint (never modifies files)
make fix # Auto-fix + lint
make similar # Advisory: report similarly-named functions/classesLinters: ruff + ty (via agent-harness), yamllint, jscpd (copy-paste
detection via pnpm), actionlint (GitHub Actions workflows). Pre-commit
hooks run agent-harness fix + lint on every commit. Install pnpm and
actionlint via brew install pnpm actionlint.
Apache 2.0
Add a comment to a Jira issue. Uses wiki markup (API v2).
| Name | Required | Description | Default |
|---|---|---|---|
| project | Yes | ||
| issue_key | Yes | ||
| body | Yes | ||
| format | No | json |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full disclosure burden. It adds valuable context that the comment 'body' uses wiki markup and references API v2, but omits mutation side effects, idempotency, or error conditions.
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?
Extremely efficient two-sentence structure. Information is front-loaded with the action, and the second sentence adds critical formatting context without verbosity. No redundant or filler text.
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?
Given the tool has an output schema (relieving the description of return value documentation), the description meets minimum viability by explaining the core action and input format. However, with zero schema descriptions, it lacks sufficient detail for an agent to correctly populate all parameters without guessing.
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?
Schema description coverage is 0%, requiring the description to compensate. It partially compensates by indicating wiki markup applies to the body content, but leaves 'project', 'issue_key', and 'format' parameters completely undocumented with no type hints or examples.
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?
States specific verb ('Add') and resource ('comment to a Jira issue'). Implicitly distinguishes from siblings like 'jira_edit_comment' and 'jira_get_comments' through the action verb, though it does not explicitly name alternatives.
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?
Provides no guidance on when to use this tool versus alternatives (e.g., when to add vs. edit a comment) or prerequisites (e.g., issue must exist). Agents must infer usage solely from the verb.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Edit an existing comment on a Jira issue. Uses wiki markup (API v2).
| Name | Required | Description | Default |
|---|---|---|---|
| project | Yes | ||
| issue_key | Yes | ||
| comment_id | Yes | ||
| body | Yes | ||
| format | No | json |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only notes the wiki markup format requirement; it fails to disclose that this operation overwrites existing content, whether it is destructive/reversible, or error conditions (e.g., invalid comment_id).
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 two-sentence structure is efficient with no wasted words. However, given the lack of schema documentation and annotations, the extreme brevity becomes a liability rather than a virtue, as critical context is omitted.
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?
Despite having an output schema (reducing the need for return value description), the tool requires four identifiers (project, issue, comment, body) with zero schema coverage. The description inadequately explains these inputs or the mutation's side effects, leaving significant gaps for an agent attempting invocation.
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?
Schema description coverage is 0%, requiring the description to compensate. It only partially addresses the 'body' parameter by noting wiki markup. It fails to explain the other four parameters: the relationship between 'project' and 'issue_key', what constitutes a valid 'comment_id', or the purpose of the 'format' parameter.
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 specific action ('Edit') and resource ('existing comment on a Jira issue'), distinguishing it from the sibling 'jira_add_comment'. The mention of 'wiki markup (API v2)' adds necessary technical context about the implementation.
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?
While 'Edit an existing' implies the tool is for modification rather than creation, there is no explicit guidance on when to use this versus 'jira_add_comment', nor any mention of prerequisites like permissions or comment ownership.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all comments for a Jira issue.
| Name | Required | Description | Default |
|---|---|---|---|
| project | Yes | ||
| issue_key | Yes | ||
| format | No | toon |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fails to disclose critical behavioral traits. It does not explain what 'all comments' entails (pagination limits?), valid values for the 'format' parameter (default is 'toon' but alternatives are unexplained), or error conditions (e.g., private issues). The existence of an output schema excuses describing return values, but operational behavior remains undocumented.
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 six-word sentence is grammatically efficient and front-loaded, but suffers from under-specification rather than true conciseness. Every word earns its place, yet critical information is missing, making it too terse for the tool's complexity.
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?
Given three parameters with zero schema documentation and no annotations, the description is insufficient. It omits explanation of the 'format' enum values, the scope of 'all' (pagination behavior), and how 'project' relates to 'issue_key'. The presence of an output schema reduces the burden for return value documentation, but parameter and behavioral documentation remain critically incomplete.
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?
Schema description coverage is 0%, requiring the description to compensate, but it fails to do so. It does not explain the 'project' parameter's relationship to 'issue_key', nor does it clarify the mysterious 'format' parameter (defaulting to 'toon') or what valid formatting options are available. Only 'issue' is implicitly referenced.
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 states a clear verb ('Get') and resource ('comments') with scope ('for a Jira issue'). It implicitly distinguishes from sibling tools like jira_add_comment and jira_edit_comment through the operation type, though it could explicitly clarify when to use this versus jira_get_issue.
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?
No guidance provided on when to use this tool versus alternatives. For example, it does not clarify whether to use this when you specifically need comment history versus the full issue details available from jira_get_issue, nor does it mention any prerequisites like issue visibility permissions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a Jira issue by key. Returns full issue data including fields and status.
| Name | Required | Description | Default |
|---|---|---|---|
| project | Yes | ||
| issue_key | Yes | ||
| format | No | json |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It adds value by specifying the return content ('full issue data including fields and status'), which complements the existing output schema. However, it omits behavioral details like error handling (invalid key scenarios), authentication requirements, or rate limiting.
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 consists of two efficient sentences with no fluff. The first states the operation and target, the second describes the return value. However, given the lack of schema documentation and annotations, this brevity comes at the cost of completeness.
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?
Despite having an output schema (reducing the need for detailed return value explanation), the description is incomplete due to 0% schema coverage and lack of annotations. With three parameters requiring documentation, the description only implicitly covers one ('issue_key'), leaving significant gaps for an agent trying to construct valid arguments.
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?
Schema description coverage is 0%, requiring the description to compensate. While 'by key' implies the 'issue_key' parameter, the description fails to explain the 'project' parameter (whether it expects a key or ID) or the 'format' parameter (what valid values exist beyond the default 'json'). This leaves two of three parameters undocumented.
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 core action ('Get') and resource ('Jira issue') with the specific identifier ('by key'). It implicitly distinguishes from sibling 'jira_search' (which would retrieve multiple issues) and write operations like 'jira_add_comment'. However, it could explicitly differentiate from related read operations like 'jira_get_transitions'.
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 provides no guidance on when to use this tool versus alternatives. It fails to mention that 'jira_search' should be used for listing or querying multiple issues, or that 'jira_get_transitions' is needed for workflow status options. No prerequisites or error conditions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get available transitions for a Jira issue.
| Name | Required | Description | Default |
|---|---|---|---|
| project | Yes | ||
| issue_key | Yes | ||
| format | No | toon |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure but provides minimal information. While 'Get' implies a read-only operation, the description does not confirm lack of side effects, authentication requirements, rate limits, or whether it checks user permissions for the transitions it lists.
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 single-sentence description is efficiently structured with no redundant words. However, extreme brevity becomes a liability given the lack of schema documentation and annotations, leaving critical information gaps.
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?
While an output schema exists (reducing the need for return value description), the tool remains under-documented. With zero schema coverage, no annotations, and three parameters including an opaque 'format' option, the description fails to provide sufficient context for correct invocation.
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?
Schema description coverage is 0%, yet the description adds no parameter context. The 'format' parameter (with cryptic default 'toon') and the relationship between 'project' and 'issue_key' are left unexplained, failing to compensate for the undocumented schema.
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 uses a specific verb ('Get') and resource ('available transitions') with clear scope ('for a Jira issue'). However, it does not explicitly differentiate from the sibling tool 'jira_transition_issue', which likely performs state changes while this tool retrieves options.
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?
No guidance provided on when to use this tool versus alternatives. It fails to mention that this retrieves transition metadata while 'jira_transition_issue' executes transitions, or that this should be called before attempting to transition an issue to validate available states.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Jira issues using JQL. Returns list of matching issues.
| Name | Required | Description | Default |
|---|---|---|---|
| project | Yes | ||
| jql | Yes | ||
| limit | No | ||
| offset | No | ||
| format | No | toon |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, yet the description discloses minimal behavioral information. It does not explain the pagination behavior (limit/offset defaults), the mysterious 'format' default value ('toon'), rate limits, or authentication requirements implied by the login/logout siblings.
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?
Extremely concise at two sentences with no filler. However, given the complexity (5 undocumented parameters) and lack of annotations, this brevity results in under-specification rather than efficient communication.
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?
Inadequate for a tool with 5 parameters and zero schema documentation. While an output schema exists (reducing the need to describe return values), the description provides insufficient context for the input parameters, pagination behavior, or JQL syntax requirements.
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?
With 0% schema description coverage, the description fails to compensate adequately. While 'using JQL' implies the syntax for the 'jql' parameter, it leaves four other parameters unexplained: 'project' (key vs name?), 'limit'/'offset' (pagination behavior), and 'format' (allowed values?).
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 identifies the action (search), resource (Jira issues), and method (JQL). However, it does not explicitly distinguish this from sibling 'jira_get_issue', which also retrieves issues but by specific identifier rather than query.
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?
No guidance provided on when to use JQL search versus retrieving a specific issue directly via jira_get_issue. No mention of prerequisites, required permissions, or when to prefer this over other discovery methods.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Transition a Jira issue to a new status. Use jira_get_transitions to discover available transitions.
| Name | Required | Description | Default |
|---|---|---|---|
| project | Yes | ||
| issue_key | Yes | ||
| transition_id | Yes | ||
| format | No | json |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Fails to disclose this is a destructive/write operation, requires specific Jira permissions (workflow transition rights), or that it triggers workflow post-functions. 'Transition' implies change but lacks explicit behavioral context.
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?
Two sentences, zero waste. Front-loaded with the core action, followed immediately by the critical prerequisite. Every word earns its place.
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?
Minimum viable for a workflow tool with output schema present. Core function and prerequisite stated, but gaps remain: no mention of permission requirements, workflow constraints, or parameter semantics given the completely undocumented schema.
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?
Schema has 0% description coverage. Description compensates minimally—only implicitly hints at transition_id source via the usage guideline. Project, issue_key, and format parameters remain completely undocumented with no types, formats, or examples provided.
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?
Clear verb ('Transition') + resource ('Jira issue') + outcome ('new status'). Distinguishes from jira_get_transitions by implying execution vs. discovery, though it doesn't explicitly characterize this as a state mutation or workflow operation.
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?
Excellent prerequisite guidance: explicitly directs users to 'Use jira_get_transitions to discover available transitions' before invoking this tool, establishing clear sequencing with the sibling tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List saved connections (no secrets shown).
| Name | Required | Description | Default |
|---|---|---|---|
| project | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It successfully discloses that secrets/credentials are not exposed in the output ('no secrets shown'), which is valuable security context. However, it omits other behavioral details like pagination, caching, or the structure of the returned connection objects.
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 efficiently structured with the action front-loaded and a useful parenthetical. However, given the complete lack of parameter documentation, it is inappropriately concise—suffering from under-specification rather than efficient communication.
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?
While the tool has an output schema (reducing the need to describe return values), the description is incomplete because it fails to address the single input parameter at all. For a tool with zero annotations and zero schema coverage, the description should provide more context.
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?
With 0% schema description coverage (the 'project' parameter has only a title, no description), the description must compensate but fails entirely. It does not mention the 'project' parameter, explain its purpose (filtering?), its format, or the behavior when null (default).
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 ('List') and resource ('saved connections'). The parenthetical '(no secrets shown)' adds specific behavioral context about the output. It doesn't explicitly distinguish from siblings (e.g., clarifying these are Jira/Database connections vs. the login/logout tools), but the core purpose is clear.
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 provides no guidance on when to use this tool versus alternatives like 'login' or 'logout', or when to filter by the 'project' parameter. There are no explicit when-to-use or when-not-to-use conditions provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Save an Atlassian connection. Validates by calling /myself.
For security, prefer passing token as ${ENV_VAR} reference (e.g., "${ATLASSIAN_TOKEN}") rather than a literal value. The variable is expanded at runtime, never stored resolved.
| Name | Required | Description | Default |
|---|---|---|---|
| project | Yes | ||
| url | Yes | ||
| Yes | |||
| token | Yes | ||
| read_only | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses validation behavior (calls /myself) and critical security traits (variable expansion at runtime, never stored resolved). However, missing details on failure behavior, idempotency, or whether saving overwrites existing connections.
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?
Three sentences with zero waste. Purpose and validation front-loaded in first sentence; security guidance follows logically. Every sentence earns its place with specific technical value.
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?
For an authentication tool with 5 parameters and 0% schema coverage, the description covers the critical security aspect well but leaves significant gaps in parameter documentation. Output schema exists so return values need not be explained, but the lack of parameter semantics for 'project' and 'read_only' limits completeness.
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?
Schema coverage is 0%, requiring description compensation. It adds essential semantics for 'token' (ENV_VAR pattern and security model) and implies url/email/token are used for auth via the /myself mention. However, 'project' and 'read_only' parameters remain completely undocumented, and the description doesn't explain parameter relationships or formats.
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?
Description explicitly states 'Save an Atlassian connection' with specific verb and resource, and mentions validation via '/myself'. Clearly distinguishes from sibling 'logout' (removes connections) and 'list_connections' (reads connections) by specifying the 'save' action.
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?
Provides critical security guidance on token passing (ENV_VAR vs literal), but lacks explicit guidance on when to use this tool versus siblings or prerequisites (e.g., 'call this before other jira_* tools'). Usage is implied by the name but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove a saved connection.
| Name | Required | Description | Default |
|---|---|---|---|
| project | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but fails to disclose critical behavioral traits: it doesn't confirm this is destructive/destructiveHint (though implied by 'Remove'), doesn't specify error behavior if connection doesn't exist, and doesn't mention whether this affects in-flight operations or session validity.
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?
Extremely terse at four words with no redundancy or filler. However, given the complete lack of schema documentation and annotations, this brevity crosses into under-specification rather than efficient communication.
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?
Inadequate for a destructive operation with undocumented parameters. Despite having an output schema (which could clarify success/failure), the description doesn't explain return values, and leaves the critical 'project' parameter unexplained while failing to provide safety warnings expected for state-mutating operations.
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 schema has 0% description coverage for the 'project' parameter, and the description completely fails to compensate—it doesn't mention the parameter at all, nor explain the semantic relationship between the 'project' parameter and the 'saved connection' resource being removed (e.g., whether project is an ID, name, or connection identifier).
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?
States a specific action (Remove) and resource (saved connection), distinguishing it from sibling 'login' (create) and 'list_connections' (read). However, it doesn't specify that this targets Jira/Atlassian connections specifically, leaving slight ambiguity given the mix of Jira-specific and connection-management sibling tools.
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?
Provides no explicit guidance on when to use versus alternatives, prerequisites (e.g., must be logged in first), or side effects. While it is semantically the inverse of 'login', the description doesn't state this relationship or warn that removal invalidates future operations requiring authentication.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0jira_add_commentjira_edit_commentjira_get_commentsjira_get_issuejira_get_transitionsjira_searchjira_transition_issuelist_connectionsloginlogoutEach tool has a distinct purpose with clear boundaries. Comment operations (add/edit/get) are well differentiated, issue retrieval is separate from workflow transitions, and connection management stands apart from Jira operations.
All tools use consistent snake_case formatting. Jira operations follow a clear jira_verb_noun pattern, while connection management tools use simpler verbs (login/logout/list_connections). The distinction between prefixed and unprefixed tools is logical but creates a minor inconsistency in the naming scheme.
Ten tools represents an appropriate scope for a Jira integration—sufficient to cover comment management, issue retrieval, workflow transitions, and authentication without bloat or fragmentation.
The surface covers reading, commenting, and workflow transitions well, but lacks essential write operations for issues themselves—specifically create_issue and update_issue (for fields). This creates a significant functional gap where agents can comment on and move issues but cannot create or modify issue content.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Connect AI agents to 1000+ apps with managed authentication and tool-calling.
SaaS intelligence for AI agents. 5 unified tools cover 1,000+ services with 91-96% token savings.
Connect your team's living knowledge base — docs, data, issues, CRM — to Claude and ChatGPT.
Safe, read-only Postgres and MySQL access for AI agents. Audit log + column-level controls.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/yoselabs/a2atlassian'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
