How to Set Up the GitHub MCP Server Safely: Hosted, Governed, No Local Install
Short answer: run the GitHub MCP server hosted on MCP Trail instead of on a laptop. Your GitHub token stays in an encrypted server-side vault, read-only tools like code search and issue reads run automatically, and write actions like opening or merging a pull request wait for a human to approve them. Setup takes about five minutes and nothing gets installed locally.
The GitHub MCP server is one of the most useful integrations you can give an AI assistant — and one of the most dangerous. It exposes tools that read repositories, search code across an org, and read issues and pull requests, but also tools that create issues, comment, push files, open PRs, and merge them. A GitHub personal access token with repo scope is write access to your source of truth. The default setup pastes that token in plaintext into claude_desktop_config.json on every machine that needs it, with no audit trail and no way to stop the model from merging a PR on its own.
This guide sets it up the governed way: one hosted, gated endpoint where you decide exactly which GitHub actions the AI can take unassisted and which ones need sign-off.
Why host the GitHub MCP server behind a gateway?
- Your token never touches client configs. The GitHub credential lives server-side; Claude, Cursor, and teammates only ever see a revocable MCP Trail bearer token.
- Write actions can require approval. Opening a PR, merging, pushing, or deleting a branch can route to an approval queue instead of executing on the model’s word.
- Read-only tools stay fast. Search and reads are allowlisted to run automatically, so governance doesn’t slow down the common case.
- Every call is logged. The audit log records who called
create_pull_request, when, and with what arguments — evidence, not guesswork. - One endpoint for the whole team. No per-laptop npm installs, no Node version drift, no “works on my machine.”
What you’ll need
- A GitHub account, and either a personal access token or a GitHub App install (more on scopes below)
- A free MCP Trail account
- An MCP client — Claude Desktop, Claude Code, Cursor, or any client that supports HTTP MCP servers
Step 1: Create your free MCP Trail account
Go to app.mcptrail.com and sign up. The free tier includes hosted servers, the audit log, human approvals, and the built-in playground, so you can complete this whole tutorial without a card.
Step 2: Connect GitHub from the MCP Marketplace
In the left sidebar, open MCP Marketplace and search for GitHub. Click Connect on the GitHub server card and the setup wizard opens.
Step 3: Provide your GitHub credential (and mind the scopes)
The wizard asks for a GitHub credential. You have two realistic options:
- Fine-grained personal access token — the safer default. Scope it to only the repositories the AI needs, and grant just the permissions in play: read access to contents, issues, and pull requests for a read-only setup, plus write on issues and pull requests if you want the AI to create and comment. For organization data, add
read:org. Avoid classic tokens with blanketreposcope unless you truly need it. - GitHub App install — better for teams and orgs. You install an App on selected repositories with a defined permission set, which gives you org-level control and revocation without one person’s PAT being the single point of trust.
Whichever you use, MCP Trail stores it in an encrypted per-user vault, injects it into the server only at runtime, and never exposes it in any client config. You can rotate or disconnect it at any time from Vault in the sidebar.
Scope tip: start read-only. Grant a token with no write permissions first, confirm the AI does useful work with search and reads, then add write permissions deliberately — paired with the approval policies below.
Step 4: Watch the server come online
The wizard provisions a hosted runtime, boots the GitHub MCP server, completes the MCP handshake, and lists the discovered tools — repository reads, code search, issue and PR reads, issue creation, commenting, and PR open/merge — all live in the setup log. When the checks turn green, your server is running.
Step 5: Set your governance policy (the part that matters)
This is where a hosted GitHub MCP server stops being a liability. Open the server’s Policies tab and decide, per tool, what runs freely and what waits for a human. The rule of thumb: reads auto-run, writes get approved, destructive writes always get approved.
Concretely: an agent reading an issue or searching code runs freely — no interruption. An agent that decides to open a pull request stops and waits; the request sits in the Approval queue with the full arguments (title, branch, body) until someone signs off. A merge or a branch delete is never automatic. This is the same human-in-the-loop pattern you’d use to block destructive actions anywhere else — applied to your codebase.
A sensible starting policy:
| GitHub tool (typical) | Read / Write | Recommended policy |
|---|---|---|
| Search code / search repositories | Read | Auto-allow |
| Get / list issues | Read | Auto-allow |
| Get / list pull requests | Read | Auto-allow |
| Read file contents | Read | Auto-allow |
| Create issue | Write | Auto-allow or HITL |
| Comment on issue / PR | Write | HITL |
| Create / update file (push) | Write | HITL |
| Open pull request | Write | HITL |
| Merge pull request | Write (destructive) | HITL (always) |
| Delete branch / ref | Destructive | HITL (always), or disable |
You can also disable any tool outright — if the AI should never merge, turn off the merge tool entirely rather than relying on approvals alone.
Step 6: Turn on DLP scanning
GitHub responses are a common exfiltration path: a .env committed by mistake, an API key in an old issue comment, a token in a CI log. Enable DLP scanning on the server so secret-shaped strings in tool arguments and results are blocked or redacted before they reach the model, with Custom DLP rules for org-specific patterns like internal hostnames or ticket IDs. This is the protect-sensitive-data control, pointed at your repos.
Step 7: Connect Claude, Cursor, or any MCP client
Every Guardian server exposes one HTTP endpoint of the form https://<gateway>/v1/proxy/<your-slug>, authenticated with a bearer token. Click Connect an agent on the server card and pick your client — the panel generates the exact snippet, including one-click deep links for Cursor and VS Code. The full client walkthrough covers every editor.
For Claude Code it’s one command:
claude mcp add --transport http github "https://<your-endpoint>" \
--header "Authorization: Bearer <your-token>"For Cursor (.cursor/mcp.json) and other JSON-config clients:
{
"mcpServers": {
"github": {
"url": "https://<your-endpoint>",
"headers": { "Authorization": "Bearer <your-token>" }
}
}
}Step 8: Verify it works
Ask your assistant something concrete:
List my most recently updated repositories and summarize the open issues on the top oneThat exercises only read tools, so it runs straight through. Now ask it to open a PR — you’ll see the request land in the Approval queue and wait. Approve it and it executes; decline it and nothing happens. Either way, open Audit log in the sidebar and both calls are there, with arguments and status.
GitHub-specific gotchas
- Rate limits are real. GitHub caps API requests per hour, and a chatty agent in a loop can burn the quota fast. Set a rate limit or budget on the server so a runaway loop throttles instead of exhausting your org’s quota.
- Org vs. personal repos. A personal token only sees what your account can. Org-owned repos may require SSO authorization on the token or, better, a GitHub App installed on the org. If the AI “can’t find” a repo it should see, this is usually why.
- Fine-grained tokens expire and are per-repo. They’re the safer choice, but you pick repositories and permissions explicitly and they have an expiry — plan to rotate. Classic tokens are broader and more dangerous; prefer fine-grained.
- Least privilege beats policy alone. Gateway approvals are a strong backstop, but a token scoped to three repos simply cannot touch the fourth. Use both.
Prefer to run it locally?
You still can — install the GitHub MCP server via npx and set GITHUB_TOKEN in your client’s MCP config. That path works for solo experiments; the trade-off is a plaintext repo-scope token in config files, no audit trail, no approval gate on merges, and per-machine setup. For anything shared or long-lived, the hosted route above is the safer default.
FAQ
Can the AI merge a pull request on its own?
Only if you let it. On MCP Trail you can put the merge tool behind human approval — so the AI can request a merge, but it waits in the approval queue until a person signs off — or disable the merge tool entirely. The default we recommend is HITL on every write and always-HITL on merges and deletes.
What token scopes does the GitHub MCP server need?
Match scope to intent. Read-only usage needs read access to repository contents, issues, and pull requests, plus read:org for organization data. To let the AI create issues, comment, push files, or open PRs, add the corresponding write permissions. Prefer a fine-grained token scoped to specific repositories, or a GitHub App install, over a classic token with blanket repo scope.
How do I stop the AI from leaking a secret it finds in a repo?
Turn on DLP scanning. Secret-shaped strings in tool arguments and results are blocked or redacted before the model sees them, and Custom DLP rules catch org-specific patterns. It complements least-privilege tokens rather than replacing them.
Can multiple people share one GitHub MCP server?
Yes. The server runs once on MCP Trail; each client connects with the endpoint and a bearer token, and every call lands in one shared audit log. You revoke a client by rotating its token — no laptop visits required.
Explore features · Use cases · Open MCP Trail