GitHub MCP Server

create_pr_review

Submit a review on a GitHub pull request to approve changes, request modifications, or add comments for code collaboration.

Instructions

Create a review on a pull request.

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>",
      "pull_number": "<pull_number>",
      "event": "<event>"
    },
    "name": "create_pr_review"
  }
}

Input Schema

Name	Required	Description
`owner`	Yes	Repository owner
`repo`	Yes	Repository name
`pull_number`	Yes	Pull request number
`event`	Yes	Review action (APPROVE, REQUEST_CHANGES, COMMENT)
`body`	No	Review comment body (required for REQUEST_CHANGES and COMMENT)

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Mar 8, 2026

TDQS

B3.1/5.0

Behavior2/5

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

With no annotations provided, the description carries full burden for behavioral disclosure but offers minimal information. It states the action but doesn't describe what 'create a review' entails operationally - whether this submits a final review, requires specific permissions, affects PR status, or has side effects. The description doesn't mention the event parameter's significance or the body requirement for certain events.

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 extremely concise at just two sentences with zero wasted words. It's front-loaded with the core purpose and doesn't include unnecessary elaboration. Every word serves a clear purpose in communicating the tool's function.

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

Completeness3/5

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

Given the tool's moderate complexity (5 parameters, mutation operation) and the presence of an output schema, the description is minimally adequate but lacks important context. It doesn't explain the review creation workflow, how this differs from commenting, or what permissions are required. The output schema existence means return values are documented elsewhere, but the description should still provide more operational context.

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?

With 100% schema description coverage, the baseline is 3. The description doesn't add meaningful parameter context beyond what's already documented in the schema - it doesn't explain relationships between parameters (like how 'event' determines 'body' requirements) or provide usage examples. The schema already documents all parameters adequately.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Create a review') and target resource ('on a pull request'), providing a specific verb+resource combination. However, it doesn't distinguish this from the sibling 'create_review_comment' tool, which appears to serve a related but different function.

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

Usage Guidelines2/5

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

The description provides no guidance about when to use this tool versus alternatives like 'create_review_comment' or 'update_pull_request'. There's no mention of prerequisites, appropriate contexts, or exclusions for this review creation operation.

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

Deploy Server