Skip to main content
Glama

Get GitHub pull request

get_github_pull_request
Read-onlyIdempotent

Retrieve full details of a linked GitHub pull request: body, diff stats, comments, CI check runs, and linked work packages.

Instructions

Read one linked GitHub pull request in full, including its CI check runs.

Use it after get_work_package_git_activity when the summary is not enough: this adds the pull-request body (markdown), the diff size (additions, deletions, changed_files), comment counts, who merged it, and every work package the PR is linked to — plus the same check_runs with status and conclusion.

Pitfalls. github_pull_request_id is OpenProject's id, never the GitHub number; the two are unrelated and there is no lookup by GitHub number. The record is a mirror that OpenProject refreshes from GitHub webhooks, so updated_at is when OpenProject last synced, not when GitHub changed. A 404 usually means the id came from the wrong field or the GitHub module is not installed on this instance.

A pull request appears in OpenProject only when its description or a comment mentions 'OP#123' or the full work-package URL; commits link separately via 'refs #123' in the commit message. Neither link can be created through the API.

Cross-references: find the id with get_work_package_git_activity(work_package_id=…); GitLab merge requests have no per-id tool — they come back in full from that same call.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
github_pull_request_idYesThe **OpenProject-internal** pull-request id — the 'id' field of an entry in get_work_package_git_activity's github_pull_requests. It is NOT the GitHub PR number ('number' in that same entry, the '#481' on github.com); passing the GitHub number fetches the wrong record or 404s.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
idNoOpenProject-internal id. This is what get_github_pull_request takes — NOT the GitHub/GitLab number.
bodyNoPull-request description as markdown (raw); html is dropped.
draftNoTrue while marked draft / work in progress.
stateNoProvider state verbatim: GitHub 'open'/'closed', GitLab 'opened'/'closed'/'merged'/'locked'. Check 'merged' for the merge fact.
titleNoPull/merge request title.
authorNoProvider account that opened it ({id, name}); a GitHub/GitLab user, not an OpenProject user.
labelsNoLabel names; always a list, empty when unlabelled.
mergedNoTrue once merged; a closed request may never have merged.
numberNoThe number humans use on GitHub/GitLab (the '#481' in the PR title). Never pass it to get_github_pull_request.
html_urlNoProvider URL of the request.
additionsNoLines added across the diff.
deletionsNoLines removed across the diff.
merged_atNoISO 8601 UTC merge time, if merged.
merged_byNoProvider account that merged it.
check_runsNoCI check runs GitHub reported for this pull request; always a list.
created_atNoISO 8601 UTC creation time.
repositoryNoRepository slug, e.g. 'acme/web'.
updated_atNoISO 8601 UTC time OpenProject last synced this record.
changed_filesNoNumber of files touched.
work_packagesNoWork packages this pull request is linked to; a PR may reference several.
comments_countNoIssue-style comments.
review_comments_countNoInline review comments.
Behavior5/5

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

Beyond the annotations (readOnly, idempotent, non-destructive), the description explains critical behavioral nuances: the record is a mirror refreshed via webhooks so `updated_at` is sync time, not GitHub change time; a 404 commonly indicates a wrong id or missing GitHub module; and PRs appear only when they mention 'OP#123' or the full work-package URL, with no API-based link creation. This adds substantial context to annotation-provided hints.

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?

Although lengthy, the description is well-structured with clear paragraphs: main purpose, usage context, pitfalls, data-appearance conditions, and cross-references. Each sentence contributes meaningful information; there is no filler or repetition beyond acceptable reinforcement. The use of 'Pitfalls.' and 'Cross-references:' headers improves scannability.

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

Completeness5/5

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

Given the tool's complexity (external data mirror, non-obvious id semantics, linkage constraints), the description is complete. It covers usage flow, error interpretation, data freshness, privacy of linkage, and alternatives. The output schema already documents return values, so the description focuses on behavioral and contextual aspects, making it fully adequate.

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?

The schema already has 100% coverage with a rich description clearly distinguishing `github_pull_request_id` from the GitHub number. The description reinforces this with the pitfall statement ('never the GitHub number… no lookup by GitHub number') and adds a diagnostic hint ('404 usually means the id came from the wrong field or the GitHub module is not installed'). While mostly redundant with the schema, the added 404 context nudges it above the baseline 3.

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 starts with a specific verb and resource: 'Read one linked GitHub pull request in full, including its CI check runs.' It clearly distinguishes this tool from the sibling `get_work_package_git_activity` by specifying that this provides full PR details while the sibling returns a summary. The scope is unambiguous and the resource is precisely identified.

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?

Explicit guidance is given: 'Use it after get_work_package_git_activity when the summary is not enough.' It also documents when not to use it for GitLab merge requests, stating they 'have no per-id tool — they come back in full from that same call.' Cross-references show exactly how to find the id, satisfying the guideline requirement thoroughly.

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/kar-thik/openproject-mcp'

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