Skip to main content
Glama
Sign In
GitHub PR MCP Server

GitHub PR MCP Server

by Pelado-Nerdworks
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

create_pull_request_review

Create a pull request review with approve, request changes, or comment actions. Include a body for change requests and comments.

Instructions

Crea una review de un Pull Request. Para REQUEST_CHANGES o COMMENT, el body es obligatorio.

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_pull_request_review"
  }
}

Input Schema

NameRequiredDescriptionDefault
bodyNoComentario asociado a la review
repoYesNombre del repositorio
eventYesTipo de review a realizar
ownerYesUsuario u organización propietaria del repositorio
pull_numberYesNúmero del Pull Request

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

B3.4/5.0
Behavior3/5

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

With no annotations provided, the description bears the full responsibility for behavioral disclosure. It does disclose an important constraint: the body is mandatory for REQUEST_CHANGES and COMMENT events. However, it does not mention permissions, side effects beyond creation, or the response format. This is a moderate level of transparency for a simple mutation tool.

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 concise, consisting of two short sentences. It front-loads the main purpose and then adds a precise condition. Every word earns its place; there is no fluff or redundancy.

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?

The tool has a moderate complexity with 5 parameters and no output schema. The description covers the essential purpose and a key constraint, but it omits other useful context such as what the review creation entails (e.g., whether it requires a commit ID), potential errors, or the shape of the response. Given the absence of an output schema, these gaps leave completeness at a 'minimum viable' level.

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?

All parameters have schema descriptions, giving a baseline of 3. The description adds semantic value by clarifying that 'body' is conditionally required for REQUEST_CHANGES or COMMENT, something not explicit in the schema where body is optional. This enhancement justifies a score above baseline.

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: 'Crea una review de un Pull Request' (Creates a Pull Request review). It is specific enough to distinguish from sibling tools like create_pull_request_comment, though it does not explicitly name that alternative. The purpose is unambiguous.

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 explicit guidance on when to use this tool versus alternatives such as create_pull_request_comment. It only mentions a conditional requirement about the body for certain event types, which is a parameter-level note rather than tool-selection guidance. There is no 'use this when...' or 'instead of...' statement.

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

Deploy Server

Other Tools