How is this different from listing issues?

Listing returns many issues with their state, for triage. Getting returns one issue's full detail, the description, comments, and labels, for actually working it. An agent lists to find the issue, then gets it to read the whole thing.

Does it include the comments?

On GitHub, yes: issue_read returns details, comments, and labels together. Linear adds attachments and branch info. Jira and GitLab return the issue's fields by key or id; whether comments come inline or need a follow-up call depends on the server.

MCP servers that can get issue details

4 verified servers expose a tool that can get an issue's details

Working an issue means reading it first: the full description, the comments, the labels, the current state. Getting one issue pulls all of that, so an agent can answer a question about it or act on it from the real record rather than a one-line title.

These verified servers let an agent get the details of a single issue.

Top pick

GitHub

Official

GitHub's official remote MCP server for repos, issues, pull requests, Actions, and code search.

version-control30,334

Tool:

issue_read

GitHub's issue_read returns an issue's details, comments, and labels in one call, enough to understand a bug without chasing separate endpoints.

Pick 2

Linear

Official

Linear's official remote MCP server lets agents create, search, and update issues and projects.

productivity

Tool:

get_issue

Linear's get_issue goes wide: it returns the issue plus its attachments and the linked git branch, useful when the fix and the ticket are connected.

Pick 3

Atlassian (Jira & Confluence)

Atlassian

Official

Atlassian's official remote MCP server for Jira and Confluence: read, search, create, and update issues and pages.

project-management746

Tool:

getJiraIssue

getJiraIssue retrieves a Jira issue by id or key, the single-issue read for teams whose tracker is Jira.

Pick 4

GitLab

Official

GitLab's official, built-in remote MCP server for issues, merge requests, pipelines, and code search via OAuth.

version-control

Tool:

get_issue

On GitLab, get_issue retrieves the detailed information for one issue, the same read inside the platform that hosts the repo and pipelines.

What to know

Listing issues tells an agent what is open; getting one tells it what the issue actually says. To summarize a bug, draft a reply, or decide a next step, the agent needs the body and the thread: the description, the comments, the labels, who is assigned. The trackers here return that for one issue by id or key. GitHub bundles details, comments, and labels in a single read; Linear adds attachments and the linked git branch; Jira and GitLab return the issue by its key or id.

An issue read once is worth carrying into the next session. An agent that already pulled and understood a bug should not re-read the whole thread to pick up where it left off; remembering what it learned, and what it already replied, keeps a follow-up focused on what changed.

Questions

How is this different from listing issues?: Listing returns many issues with their state, for triage. Getting returns one issue's full detail, the description, comments, and labels, for actually working it. An agent lists to find the issue, then gets it to read the whole thing.
Does it include the comments?: On GitHub, yes: issue_read returns details, comments, and labels together. Linear adds attachments and branch info. Jira and GitLab return the issue's fields by key or id; whether comments come inline or need a follow-up call depends on the server.