GitHub Assistant MCP Server

list_pull_requests

Retrieve pull requests from any GitHub repository. Filter by open, closed, or all states and limit results to review proposed or recently merged code changes.

Instructions

List pull requests for a GitHub repository.

Use this when the user wants to see what code changes are proposed or recently merged — e.g. "what PRs are open in fastapi/fastapi?", "show me recent merged PRs in torvalds/linux".

Args: owner: Repository owner (GitHub username or organisation). repo: Repository name. state: Filter by PR state: "open" (default), "closed", or "all". limit: Max number of PRs to return (1-50, default 20).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "owner": "<owner>",
      "repo": "<repo>"
    },
    "name": "list_pull_requests"
  }
}

Input Schema

Name	Required	Default
`repo`	Yes
`limit`	No
`owner`	Yes
`state`	No	open

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Aug 30, 2026

TDQS

A4.4/5.0

Behavior3/5

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

With no annotations, the description must carry behavioral disclosure, and it does convey that this is a read-only listing action with state and limit controls. However, it does not mention authentication, rate limits, pagination, or ordering behavior. There is no contradiction, but the behavioral profile is only minimally fleshed out.

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?

The description is compact, front-loads the core purpose, and uses a short example block plus an Args list. Every sentence earns its place, with no redundant restatement of the tool name.

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 low conceptual complexity, the presence of an output schema, and full parameter documentation in the description, nothing essential is missing for an agent to select and call the tool. It covers what the tool does, when to use it, and how to fill each argument.

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

Parameters5/5

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

Schema description coverage is 0%, yet the description explains all four parameters in plain language: owner, repo, state ('open', 'closed', or 'all'), and limit (1–50, default 20). This fully compensates for the bare schema, adding value beyond the field names and types.

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 names a specific verb and resource — 'List pull requests for a GitHub repository' — and adds a distinguishing use case: showing proposed or recently merged code changes. Example queries like 'what PRs are open in fastapi/fastapi?' make it easy for an agent to separate this from sibling tools such as list_issues.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly says 'Use this when the user wants to see...' and gives realistic example queries. It does not state when-not-to-use or name an alternative tool, but the context is clear enough for list-related PR requests.

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

Deploy Server