ProjectPulse MCP

What ProjectPulse MCP does

ProjectPulse MCP MCP server exposes GitHub repository analysis through MCP tools. It covers raw repository metadata, recent GitHub Actions runs, Dependabot alerts, CodeQL or other code-scanning alerts, calculated health scores, DORA proxy metrics, repository comparisons, and open-source best-practice checks.

The tools are separated by purpose. Use get_repo_health for fields such as stars, forks, language, license, issue count, default branch, and archive status. Use check_ci_status for workflow history rather than for an overall repository grade. get_health_score combines CI, freshness, security, community, and maintenance categories into a 0–100 score with an A–F grade, suggestions, and trend information from prior checks.

How it works

The server queries GitHub REST API endpoints for repositories, Actions runs, releases, pull requests, Dependabot alerts, and code-scanning alerts. Health scoring also uses OpenSSF Scorecard data. DORA calculations are proxies derived from GitHub activity, including releases, workflow runs, and pull requests; they are not direct measurements from a separate deployment system.

Most operations are read-only. The exception is get_health_score, which records a trend snapshot on local disk, and analyze_code_scanning when trigger_scan=true, which dispatches a GitHub Actions workflow. compare_repos applies the health-score logic to between two and five repositories and returns a ranking with category details.

Setup and configuration

ProjectPulse MCP MCP server requires Node.js 18 or later and npm. It can be launched from an MCP client with the npm package through stdio, using npx -y projectpulse-mcp. Claude Code can add it with claude mcp add projectpulse -- npx projectpulse-mcp; Claude Desktop and other clients need an MCP server entry containing the command, arguments, and environment.

Set GITHUB_TOKEN when accessing private repositories or security information, or when higher GitHub API limits are useful. Public repository metadata and several analyses can work without a token. Dependabot access requires suitable Dependabot permissions, and code scanning requires security-events permissions. The README specifies read-only access for code-scanning alerts, Dependabot alerts, and repository metadata when creating a fine-grained token.

Tools and capabilities

• check_ci_status: returns recent GitHub Actions workflow runs with status, conclusion, branch, timestamps, and links.
• get_repo_health: returns basic repository metadata and statistics.
• analyze_dependencies: lists vulnerable dependencies from Dependabot, including severity and package details.
• analyze_code_scanning: retrieves code-scanning alerts and can optionally trigger a scan.
• get_health_score: calculates a graded repository health assessment and stores history locally.
• get_dora_metrics: calculates deployment frequency, lead time, change failure rate, and MTTR proxies for a selected period.
• compare_repos: ranks two to five repositories by calculated health score.
• check_best_practices: evaluates 12 repository-quality checks and reports pass, fail, or unknown results with suggestions.

Limitations and notes

GitHub API rate limits apply. Unauthenticated requests have lower limits, while authenticated requests generally allow more access. Security endpoints may return incomplete data without the required token permissions. Branch protection is reported as unknown, without penalty, when the token lacks administrative access.

The tools should be chosen according to the question: raw CI history is distinct from the health grade, dependency alerts are distinct from CodeQL findings, and repository metadata is distinct from calculated DORA metrics. Comparing repositories makes multiple API calls, and health or DORA analysis can make several endpoint requests, so heavy use may consume rate limits quickly.