Bernhard the Builder
AboutAppsBlogNewsDDDD

How to Install Cursor MCPs

The complete guide to setting up GitHub and Firebase MCP servers in Cursor - understanding the fundamental difference between token-based and CLI-based authentication.

How to Install Cursor MCPs
Guide
Bernhard The Builder
2026-01-13
5 MIN READ
Download Resources
AI Directive

How to Install Cursor MCPs: When the Docs Leave You Stranded

I opened Cursor today, ready to connect my AI agent to GitHub and Firebase. I followed the docs. I copied the config.
Nothing worked. My frustration spiked when I realized the documentation never explains the fundamental difference between these two tools. One needs a token.
One doesn't. Why? Because they work completely differently under the hood - GitHub is remote, Firebase is local.
Once I understood that, installing Cursor MCPs became simple. Here's how to install Cursor MCP servers, configure GitHub tokens, set up Firebase CLI, and get both working in one config file.
>
The Core Discovery: GitHub requires a static token because Cursor talks to GitHub's servers remotely. Firebase uses your local CLI session because Cursor operates on your machine. Understanding this difference is the key to making both work.

The Master File: mcp.json

Before I dive into the authentication strategies, you need to know one absolute fundamental fact: There is one config file that controls all MCP installations. This is the mcp.json file.
This single file is the brain of your MCP setup. Every MCP server you install - GitHub, Firebase, or any other - gets configured in this one file. Understanding this from the start prevents confusion later.
How to Access It:
  1. Open Cursor Settings (File → Preferences → Settings, or Ctrl+, / Cmd+,)
  2. Navigate to Features → MCP
  3. Click Edit config.json or Manage MCP Servers
This opens the mcp.json file where all your MCP servers are configured.
Cursor MCP Settings
The Single Source of Truth //
All MCP servers live in one file: mcp.json. You can access it instantly through Cursor Settings → Features → MCP. This is where you'll configure GitHub, Firebase, and any other MCP servers you install.
Here's the complete guide to installing both MCP servers in Cursor - with the logic explained, not just the steps. This is how I install Cursor MCPs every time.
MCPCursorGitHubFirebase

Why This Matters

MCP servers give your AI agent superpowers. GitHub MCP lets it read your repositories, create issues, manage pull requests. Firebase MCP lets it interact with your database, manage your project, deploy your apps.
But if you don't understand the authentication difference, you'll spend hours debugging why one works and the other doesn't.
The old way: Copy-paste configs. Hope they work. Get frustrated when they don't.
The new way: Understand the authentication strategy. Configure each tool correctly. Get both working in minutes.

The Core Concept: Authentication Strategy

MCP Configuration
Before writing any code, understand the fundamental difference:
GitHub = Remote Server = Needs Token
Cursor talks to GitHub's servers over the internet. GitHub doesn't know "who you are" without a passport. That passport is a Personal Access Token - a static string that proves your identity.
Firebase = Local Machine = Uses CLI Session
Cursor runs on your computer. Firebase CLI also runs on your computer. Cursor can "borrow" the active session from your terminal.
It doesn't need a static token string because it's using your local authentication state.
The Logic //
This is why GitHub needs a token in the config file, but Firebase doesn't. One is remote authentication. One is local state. Understanding this prevents hours of confusion.

Part 1: GitHub MCP (The "Token" Method)

GitHub needs a static token because Cursor talks to GitHub's servers remotely. It doesn't know "who you are" without a passport.

Step 1: The Token Generation

Use "Classic" tokens because modern MCP tools often fail with the strict scoping of "Fine-Grained" tokens.
  1. Navigate to GitHub Settings, then go to Developer Settings → Personal access tokens → Tokens (classic).
  2. Click Generate new token (classic).
  3. Configuration:
    • Expiration: Set to "No expiration" (or 90 days for security).
    • Scopes (Critical):
      • ✅ repo (Check the main box. This auto-selects all sub-items like public_repo, repo:status). Reason: Allows the AI to read your code.
      • ✅ user (Check the main box). Reason: Allows the AI to see issues assigned to "you".
      • ✅ project (Optional, for Kanban boards).
  4. Save: Generate and copy the string starting with ghp_.
Why Classic Tokens? //
Fine-Grained tokens have stricter scoping rules that many MCP tools can't handle. Classic tokens are more permissive and work reliably. If security is a concern, set expiration to 90 days and rotate regularly.

Step 2: The Logic

Why Classic? Stability. Modern fine-grained tokens have complex permission models that break MCP servers.
Why repo scope? Without it, the AI is blind to your private code. It can only read public repositories.
Why user scope? The AI needs to know "who you are" to filter issues, see your assigned tasks, and understand your context.
MCP GitHub Installation
>
The Token Strategy: GitHub is a remote server. Cursor needs a passport to prove identity. That passport is a Personal Access Token - a static string that never changes (until you revoke it).

Part 2: Firebase MCP (The "CLI" Method)

Firebase uses Local State (CLI) because Cursor operates on your machine. It "borrows" the active session from your computer's terminal. It does not need a static token string.

Step 1: The Global Check

Perhaps you wonder if npm install -g needs to be run in your project folder. It does not.
-g (Global): Installs the tool into your computer's "brain," not the specific folder. You do this once per machine.
The Check: Run firebase --version in any terminal. If you see a number (e.g., 13.x.x), Firebase CLI is installed.
Global vs Local //
Global installation means the tool is available system-wide. You don't need to install it in every project. One installation. All projects can use it.

Step 2: The Session Check

Since Firebase doesn't use a token, ensure your computer is logged in.
  1. Run firebase login in the terminal.
  2. If: "Already logged in as..." → You are ready.
  3. If: It asks for permission → Type Y and login via browser.
Firebase Login Check
Session State //
Firebase MCP uses your local CLI session. If you're not logged in, the MCP server will fail. Always verify with firebase login before configuring Cursor.

Step 3: Project Awareness

While the tool is global, the context is local. Ensure you run firebase init inside your specific project folder eventually so the AI understands your specific database structure.
>
The CLI Strategy: Firebase runs on your machine. Cursor can "borrow" your terminal session. No token needed. Just make sure you're logged in.

Part 3: The Master Configuration

This is where I combine both strategies in the mcp.json file I showed you earlier.
Location: Cursor Settings → Features → MCP → Edit config.json (the same file shown earlier).
json
MCP Configuration
Critical Steps //
  1. Replace ghp_YOUR_ACTUAL_TOKEN_HERE with your actual token from Part 1. 2. Make sure Firebase CLI is installed globally (npm install -g firebase-tools). 3. Verify you're logged into Firebase (firebase login). 4. Restart Cursor completely after saving the config.
MCP Installation Complete

Final Checklist

Before you celebrate, verify everything:
  • [ ] GitHub: Did you replace the placeholder text with your actual ghp_ token?
  • [ ] Firebase: Did you confirm firebase login says "Success" in your terminal?
  • [ ] Cursor: Did you restart Cursor or click "Retry" in the MCP settings?
  • [ ] Success Indicator: Both lights in the MCP settings panel are Green.
Firebase Installation Check
Mission Accomplished //
When both lights are green, your AI agent has superpowers. It can read your GitHub repos, manage your Firebase projects, and help you build faster. The setup is complete. Relief.
>
The Takeaway: Two different authentication strategies. One remote (token). One local (CLI session). Understanding this difference makes configuration simple. Both servers. One config file. Everything working.

Latest Blog Posts

Manifesto2026-05-02

The Rise of the Agentic Internet

The era of building website content is dead. The digital world just hasn't seen the body yet. I am moving to Full Agentic AI — and the implications will dismantle the current server-based software industry.

2026-02-12

LM Studio vs. Ollama

LM Studio runs Llama 4 Scout on local GPUs - but even 96GB VRAM has limits. Context length matters. Kilo Code bridges your IDE to local models. Here is what I learned.

Best Practices2026-02-08

Why You Must Run ESLint Before You Touch the "Cloud"

Running ESLint locally isn't optional - it's your first defense against broken Vercel deployments. I learned this the hard way when my code pushed to Git, triggered Vercel, and failed after 5 minutes of waiting. The fix? A 0.5-second local ESLint check that catches errors before they reach production. Here's why ESLint prevents deployment failures, code rot, and invisible performance bugs.

Achievement2026-02-08

Building a Neural Link Architecture: Zero Link Rot with AI-Powered Semantic Linking

I got absolutely fed up with broken internal links and manual link maintenance. The problem? Hardcoded links rot when slugs change. The solution? A neural link architecture that uses vector embeddings, hybrid ranking algorithms, and AI to automatically inject semantically relevant links at render-time. This system eliminates link rot, scales to thousands of articles, and ensures every link is contextually relevant. Here's how I built a semantic linker that treats websites as living knowledge graphs for AI citation systems.

A
B
C

This article is part of a Semantic Cluster. All links are managed by the Digital Architect AI.