Skip to main content
Glama
saidsef

GitHub PR Issue Analyser

by saidsef

get_pr_diff

Fetch the raw patch/diff text for a specific GitHub pull request to analyze code changes and review modifications.

Instructions

Fetches the diff/patch of a specific pull request from a GitHub repository. Args: repo_owner (str): The owner of the GitHub repository. repo_name (str): The name of the GitHub repository. pr_number (int): The pull request number. Returns: str: The raw patch/diff text of the pull request if successful, otherwise None. Error Handling: Logs an error message and prints the traceback if the request fails or an exception occurs.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
repo_ownerYes
repo_nameYes
pr_numberYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Implementation Reference

  • The handler function that executes the core logic of fetching the raw patch/diff for a specific GitHub pull request using the dedicated GitHub patch-diff API endpoint.
    def get_pr_diff(self, repo_owner: str, repo_name: str, pr_number: int) -> str:
        """
        Fetches the diff/patch of a specific pull request from a GitHub repository.
        Args:
            repo_owner (str): The owner of the GitHub repository.
            repo_name (str): The name of the GitHub repository.
            pr_number (int): The pull request number.
        Returns:
            str: The raw patch/diff text of the pull request if successful, otherwise None.
        Error Handling:
            Logs an error message and prints the traceback if the request fails or an exception occurs.
        """
        logging.info(f"Fetching PR diff for {repo_owner}/{repo_name}#{pr_number}")
        
        try:
            # Fetch PR details
            response = requests.get(f"https://patch-diff.githubusercontent.com/raw/{repo_owner}/{repo_name}/pull/{pr_number}.patch", headers=self._get_headers(), timeout=TIMEOUT)
            response.raise_for_status()
            pr_patch = response.text
            
            logging.info("Successfully fetched PR diff/patch")
            return pr_patch
            
        except Exception as e:
            logging.error(f"Error fetching PR diff: {str(e)}")
            traceback.print_exc()
            return str(e)
  • Dynamic registration of all public methods (including get_pr_diff) from GitHubIntegration instance as MCP tools via FastMCP.add_tool()
    def register_tools(self, methods: Any = None) -> None:
        for name, method in inspect.getmembers(methods):
            if (inspect.isfunction(method) or inspect.ismethod(method)) and not name.startswith("_"):
                self.mcp.add_tool(method)
  • Calls the register_tools method on the GitHubIntegration instance (self.gi) to register get_pr_diff and other methods as MCP tools.
    def _register_tools(self):
        self.register_tools(self.gi)
        self.register_tools(self.ip)
  • Helper method used by get_pr_diff to generate authenticated HTTP headers for GitHub API requests.
    def _get_headers(self):
        """
        Constructs the HTTP headers required for GitHub API requests, including the authorization token.
        Returns:
            dict: A dictionary containing the required HTTP headers.
        Error Handling:
            Raises ValueError if the GitHub token is not set.
        """
        if not self.github_token:
            raise ValueError("GitHub token is missing for API requests")
        headers = {
            'Authorization': f'token {self.github_token}',
            'Accept': 'application/vnd.github.v3+json'
        }
        return headers
Behavior4/5

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

With no annotations provided, the description carries full burden. It discloses key behaviors: it returns raw patch/diff text (not structured data), handles errors by logging and printing traceback, and returns None on failure. However, it lacks details on rate limits, authentication needs, or whether it's read-only (implied but not explicit).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with sections for Args, Returns, and Error Handling, making it easy to parse. It's front-loaded with the core purpose. However, the error handling section is slightly verbose ('prints the traceback') and could be more concise without losing clarity.

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

Completeness4/5

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

Given 3 parameters with 0% schema coverage and an output schema (implied by Returns section), the description is reasonably complete. It covers parameters, return value, and error behavior. It could improve by mentioning authentication or rate limits, but for a read operation with output schema, it provides sufficient context for basic use.

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?

Schema description coverage is 0%, so the description must compensate. It clearly explains each parameter's purpose: 'repo_owner' as the repository owner, 'repo_name' as the repository name, and 'pr_number' as the pull request number. This adds essential meaning beyond the bare schema, though it doesn't specify format constraints (e.g., string patterns).

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 clearly states the specific action ('Fetches') and resource ('diff/patch of a specific pull request from a GitHub repository'), distinguishing it from siblings like 'get_pr_content' (which likely fetches PR metadata) or 'merge_pr' (which performs an action). It precisely identifies what the tool retrieves.

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 on when to use this tool versus alternatives like 'get_pr_content' or 'list_open_issues_prs'. It mentions fetching a diff, but doesn't specify prerequisites (e.g., PR must exist) or contrast with other tools that might provide similar or related data.

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/saidsef/mcp-github-pr-issue-analyser'

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