Skip to main content
Glama

Get an issue with its current version — call this before update_issue

get_issue
Read-onlyIdempotent

Get an issue with its current version — call this before update_issue.

Returns the full issue and its current version. Call this before update_issue, transition_issue, assign_issue, move_to_sprint, rank_issue, link_issues, unlink_issues or delete_issue, and pass the version it returns. People in it (reporter, assignee, created_by, updated_by) are user ids — list_people gives their names. Custom fields (D129): frontmatter.fields holds the values keyed by field id (definitions in get_project fields); flags are the template flags computed now (overdue, bill_due, sla_over …, never stored); computed has the formula fields' values; children summarises its subtasks — for a Sales & Billing deal its installments: count, done (paid), amount_total, paid_total, paid_count. Installments themselves are subtasks: search_issues with parent = the deal key lists them with their own fields and flags. Links (spec D131): frontmatter.links holds what you wrote (type, id — an issue key of this or another project of the company, or a release KEY/R-n for delivers); linked[] resolves each one live, same order: kind issue | release, project_key / project_name, readable (false = you cannot open that project or the target is gone — only the key is known, never guess the rest), and for a readable issue title, status, status_name, category, progress (100 when done else 0), for a readable release title, state, progress (% of its issues past the last gate; shipped = 100). computed also carries rollup fields (e.g. a goal's progress and linked) and fn: rice scores; flags may say on_track / at_risk / off_track for a Roadmap & Goals goal. Agent work context (D179): frontmatter.working / touches say what the assignee is doing and what it changes (working_at, working_by, working_by_agent); each readable linked issue also carries assignee, updated_at, working, working_at, touches and agent_live (an agent account called a tool on it in the last 10 minutes; last_tool_at) — read them before you change what they touch; a person's working older than a day may be stale. Before you START a card, get_issue_context gives all of this plus parent, siblings, comments and handoffs in one text.

Input Schema

NameRequiredDescriptionDefault
issue_keyYesIssue key `{PROJECT}-{n}`, e.g. `KJ-101`.
project_keyYesProject key, e.g. `KJ`. 2–10 chars, uppercase letters and digits, starts with a letter.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior5/5

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

Annotations already declare a safe, idempotent read, and the description goes well beyond them: it discloses staleness semantics ('a person's `working` older than a day may be stale'), a 10-minute liveness window for `agent_live`, and that `readable: false` means the target cannot be opened so 'never guess the rest'. Those are agent-affecting behaviors nothing in the structured fields conveys.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The critical instruction is front-loaded in the first two sentences, which is right. But the remainder is a single dense wall of text loaded with internal spec codes (D129, D131, D179) and deep payload detail that is disproportionate for a two-parameter read.

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?

With no output schema, the description carries the full burden of explaining the return value and does so thoroughly: version, user-id fields, frontmatter fields/flags/computed/children, link resolution, and rollups. It omits error behavior (e.g., missing issue or unknown project key) and any permission notes, which keeps it short of a 5.

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

Parameters3/5

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

Schema coverage is 100% and both parameters are documented in-schema with patterns and examples, so the baseline applies. The description adds no additional meaning about project_key/issue_key (its only key-related content is nested keys like `KEY/R-n` inside the returned links), so it neither enhances nor compensates.

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?

States a specific verb and resource ('Get an issue') and immediately scopes it by its distinguishing feature — it returns the current `version` needed for optimistic concurrency. It is clearly separated from the nearest sibling by noting that get_issue_context returns this plus parent, siblings, comments and handoffs.

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?

Explicitly enumerates when to call it — before update_issue, transition_issue, assign_issue, move_to_sprint, rank_issue, link_issues, unlink_issues, delete_issue — and what to do with the result ('pass the `version` it returns'). It also names the richer alternative (get_issue_context) and the condition for preferring it, plus a caveat to read `working`/`touches` before changing what they touch.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources