Complete Guide to Connecting Cursor AI to the GitHub MCP Server

Cursor's Agent mode can already read and write code and run terminal commands, but by default it can't see what's happening in your GitHub repositories. By connecting the GitHub server through MCP (Model Context Protocol), the Agent can directly query issues, pull pull requests, and read repository information. This article is based on a hands-on demo from the YouTube channel JustBoz and breaks down the full configuration process.

Why It's Worth Connecting the GitHub MCP

MCP is an open protocol proposed by Anthropic that lets AI tools call external services in a standardized way. Cursor, as one of the earlier editors to support MCP, provides a dedicated MCPs management panel in the sidebar. After connecting the GitHub server, you can directly ask the Agent in a conversation to perform operations like "list all my pending pull requests" without manually copying and pasting repository links.

The core value JustBoz emphasizes in the video is this: feeding GitHub context directly to the Agent reduces the back-and-forth of switching between the browser and the editor. For developers who routinely work across multiple repositories, this workflow can significantly cut down the time spent on repetitive operations.

MCP uses a client-server architecture: Cursor acts as the MCP client, reads the server definitions in mcp.json at startup, and launches each server as a subprocess (for example, npx @modelcontextprotocol/server-github). The server exchanges JSON-RPC messages with the client over standard input/output (stdio) and declares to the client which tools, resources, and prompts it provides. When the Agent decides in a conversation to call a tool, the client forwards the call request to the corresponding server, the server then requests the GitHub REST API, and finally returns the result to the model. So connecting an MCP server is essentially adding a set of callable external functions to the Agent, and the token is the credential these functions use to access GitHub.

Step 1: Create a GitHub Personal Access Token

The whole process starts in GitHub's account settings. The path is: Settings → Developer settings → Personal access tokens.

There are two things to keep in mind when creating a token:

• Principle of least privilege. Only check the scopes you actually need; don't select everything just to save effort. What the GitHub MCP server can do depends on token permissions—the fewer the permissions, the smaller the risk surface if leaked.
• Copy it immediately. The token is shown only once when generated and can never be seen again after the page refreshes. If you don't save it, you can only delete it and generate a new one.

This is the most error-prone part of the entire configuration—many people are used to clicking all the options first and then copying, only to lose the token when switching pages midway.

GitHub currently provides two types of personal access tokens: classic tokens (Classic PAT) and fine-grained tokens (Fine-grained PAT). Classic tokens authorize at the scope level, can take effect across all repositories, and are simple to configure; MCP server documentation usually uses them as examples. Fine-grained tokens, by contrast, must specify the accessible repository range and can grant permissions for issues, pull requests, contents, and more separately for read/write, giving more precise permission boundaries. If you only need the Agent to read repository information and PR status, a read-only permission combination on a fine-grained token is already sufficient, and the impact of a leak is limited to the specified repositories. When choosing, you can start from a fine-grained token according to the minimum viable principle and grant permissions item by item if you encounter insufficient permissions.

Step 2: Add the MCP Server in Cursor

Back in Cursor, click Customize in the left sidebar, then open the MCPs panel in the top tab bar. Choose to add a server, and Cursor will automatically open the mcp.json file located in the .cursor folder under your user home directory.

In this JSON file, add an entry named GitHub, and fill the command field with the command that runs the GitHub MCP server. The key point is where to put the token: JustBoz explicitly recommends writing the token into the entry's ENV block rather than putting it in the arguments parameter.

This detail is worth elaborating on. Content in arguments may be recorded by command logs, process lists, or debug output, whereas environment variables are relatively isolated. Although the two approaches are functionally equivalent, from a credential management perspective, the ENV block is the safer choice. This recommendation also aligns with the "config in the environment" principle of the Twelve-Factor App.

Each server entry in mcp.json usually contains three key fields: command specifies the program to execute (such as npx or docker), args are the parameters passed to that program (such as the package name and startup parameters), and env is the environment variables injected into the subprocess as key-value pairs. The GitHub MCP server reads the token from an environment variable at startup (commonly GITHUB_PERSONAL_ACCESS_TOKEN), so putting the token in env is exactly the way the server expects to read it, not an optional preference. In addition, the npx approach downloads the server package temporarily on first run, so Node.js must be installed locally; if you don't want to rely on network fetching, you can also switch to a global installation or a Docker image and adjust command and args accordingly.

Step 3: Verify That the Connection Works

After saving mcp.json, return to the MCPs tab and check whether the status indicator turns green. A green light means the server has started successfully and completed the handshake.

But a green light is only confirmation at the process level; it doesn't mean GitHub authentication has also passed. JustBoz's verification method is to directly ask Cursor's Agent to list your open pull requests. If it returns a real PR list, it means the token permissions, network connection, and server process are all working; if it returns an empty list or an error, you need to go back and check whether the scopes cover the repo-related permissions.

This verification approach is worth adopting—using a real API call instead of an abstract "connection successful" prompt can expose permission configuration problems earlier.

Who This Configuration Is For

From a practical standpoint, the barrier to this process is not high, but there are two prerequisites: first, you are already using Cursor's Agent feature; second, you have a need for cross-repository retrieval. If your workflow is concentrated in a single repository and you rarely handle issues and PRs in the editor, the benefits of connecting MCP are limited.

Conversely, if you frequently need AI to help sort through a repository's change history or batch-check PR status, connecting GitHub as an MCP server is a cost-effective choice. Configure it once, and all subsequent conversations can reuse it.

One reminder: mcp.json is a local configuration file, and the token in it is stored in plaintext. If you include the .cursor directory in version control or sync it to the cloud, be sure to add this file to the ignore list first.

If you want to further reduce the risk of plaintext tokens, you can move the token out of mcp.json and instead reference a system environment variable in the startup command, leaving only the variable name in the configuration file; or store the token in the operating system's keychain and have a script inject it at startup. In addition, regularly rotating tokens and creating separate tokens for different purposes (for example, one read-only token for MCP and another for write operations) can also keep losses within a smaller range if a token is accidentally leaked. These practices don't change the configuration process itself; they just tighten the details of credential management by another layer.

Summary

Three steps and you're done: create a token on GitHub (least privilege, copy immediately), add the server in Cursor (put the token in ENV, not arguments), and verify connectivity with a real PR query. The whole process can be completed in under ten minutes; the difficulty lies not in operational complexity but in the details of credential management.