get_pull_requestFetch a pull request or merge request and its reviews/approvals from GitHub or GitLab in one call, with cross-referenceable IDs for testing integrations.
Fetch one PR (GitHub) / MR (GitLab) plus its reviews (GitHub) / approvals (GitLab). Returns both in one result; each carries provider-form ids for cross-referencing.
| Name | Required | Description | Default |
|---|---|---|---|
| repo | No | ||
| number | Yes | ||
| provider | Yes |
Changes observed during successful MCP inspections.
v0.3.14Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It usefully discloses that the call returns both the PR and its reviews in one result and that ids are provider-form for cross-referencing, but it omits read-only/auth requirements and any rate-limit or pagination behavior. Fetch/Get implies a safe read, so the gap is moderate rather than severe.
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 dense sentences with the payload ('one PR/MR plus reviews/approvals') front-loaded and the cross-referencing note last, with no filler. The slash-heavy provider hedging makes it slightly harder to parse than it needs to be.
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 a 3-param tool with no annotations and no output schema, the description does explain what comes back (PR + reviews/approvals, provider-form ids), so return-value coverage is adequate. It falls short on `repo` semantics, provider scope, and any operational constraints, leaving real gaps an agent must guess at.
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% across three parameters, and the description compensates only partially: it explains `provider` in terms of GitHub vs GitLab and implies `number` identifies the single PR. The `repo` parameter is never mentioned, and the schema's 21-value provider enum is far broader than the two providers the description names.
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 verb and resource ('Fetch one PR/MR') and spells out the bundled payload (reviews on GitHub, approvals on GitLab) and the cross-referencing id format. 'One' implicitly distinguishes it from the sibling list_pull_requests, though no sibling is named explicitly, keeping it short of a 5.
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?
Usage is only implied: you call this when you need a single PR/MR together with its reviews/approvals. There is no explicit when-not guidance versus list_pull_requests, and no prerequisites stated (e.g. whether `repo` is mandatory for github/gitlab).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.