ProjectPulse MCP vs Stackpulse

A side-by-side look at the ProjectPulse MCP and Stackpulse MCP servers: transport, auth, tools, quality signals, and the config to install either one in Claude, Cursor, Windsurf or VS Code.

ProjectPulse MCP logoProjectPulse MCPMonitoring · Local subprocess (stdio)Monitor GitHub repo health, DORA metrics and CI signals from your AI assistant.64GoodAuth: not declared
S
StackpulseMonitoring · Remote HTTP/SSE
8,900+ services' status, and your Stackpulse dashboards and URL monitors. Needs Pro.51GoodAuth: not declared

Verdict: choose ProjectPulse MCP for monitoring work as a local process; choose Stackpulse for monitoring over a hosted endpoint. You can also run both side by side in one mcpServers block.

Which MCP server should you choose?

ProjectPulse MCP logoChoose ProjectPulse MCP when

  • You need dedicated capabilities in the Monitoring domain.
  • You prefer a local stdio subprocess transport.
  • You have the keys it needs: GITHUB_TOKEN.
  • You want tools like check_ci_status, get_repo_health, analyze_dependencies.
Explore ProjectPulse MCP

S
Choose Stackpulse when

  • You need dedicated capabilities in the Monitoring domain.
  • You prefer a remote HTTP/SSE transport.
  • You want tools like search_services, get_service, list_outages.
Explore Stackpulse

Feature & specification comparison

Rows where the two servers differ are marked.

SpecProjectPulse MCP logoProjectPulse MCP
S
Stackpulse
CategoryMonitoringMonitoring
Quality signal64/100 · Good51/100 · Good
Install commandConfirmedConfirmed
TransportLocal subprocess (stdio)Remote HTTP/SSE
AuthNot declaredNot declared
PricingFreeNot declared
Required env varsGITHUB_TOKENNone listed
Verified ownerCommunity listingCommunity listing
GitHub stars1—
Directory activity 4 views 0 installs 0 upvotes 1 views 0 installs 0 upvotes
Tools816

Tools & capabilities

ProjectPulse MCP tools 8

  • check_ci_statusFetches recent CI/CD workflow runs (GitHub Actions) for a GitHub repository. - Side effects: None. This is a strictly read-only operation. - Data sources: GitHub REST API (actions/runs). - Auth requirements: No authentication required for public repositories. Uses configured token if available. - Rate limits: Subject to standard GitHub API limits. - Return shape: Returns a JSON array of workflow runs including name, status, conclusion, head_branch, created_at, updated_at, and html_url. - Usage guidelines: Use this tool ONLY to check raw GitHub Actions workflow history and CI build statuses. DO NOT use this tool for other analyses: - For a computed A-F health score grading, use 'get_health_score' instead. - For retrieving basic repository stats (stars, forks), use 'get_repo_health' instead. - For calculated DORA metrics, use 'get_dora_metrics' instead.
  • get_repo_healthFetches basic repository metadata and statistics from the public GitHub API. - Side effects: None. This is a strictly read-only operation. - Data sources: Public GitHub REST API (GET /repos/{owner}/{repo}). - Auth requirements: No authentication required for public repositories. Uses configured GitHub token if available. - Rate limits: Subject to standard GitHub API limits (60 requests/hour unauthenticated, 5000 requests/hour authenticated). - Return shape: Returns a JSON object containing specific metadata: full_name (string), description (string), stargazers_count (number), open_issues_count (number), language (string), license (string, SPDX ID), pushed_at (ISO 8601 string), default_branch (string), archived (boolean), and forks_count (number). - Usage guidelines: Use this tool ONLY to retrieve basic raw metadata (like stars, forks, language, and issue counts). DO NOT use this tool for other specific analyses: - For a computed A-F health score grading, use 'get_health_score' instead. - For checking CI/CD workflow run statuses, use 'check_ci_status' instead. - For package vulnerabilities and dependency graph, use 'analyze_dependencies' instead. - For code security and static analysis, use 'analyze_code_scanning' instead.
  • analyze_dependenciesFetches Dependabot alerts for a GitHub repository to analyze vulnerable package dependencies. - Side effects: None. This is a strictly read-only operation. - Data sources: GitHub REST API (dependabot/alerts). - Auth requirements: Requires GITHUB_TOKEN with appropriate permissions (dependabot alerts are often restricted). - Rate limits: Subject to standard GitHub API limits. - Return shape: Returns a JSON array of vulnerable package dependencies including summary, severity, package_name, state, and html_url. - Usage guidelines: Use this tool ONLY to find vulnerable package dependencies (npm, pip, etc.). DO NOT use this tool for other checks: - For static code security vulnerabilities (CodeQL), use 'analyze_code_scanning' instead. - For a computed A-F health score grading, use 'get_health_score' instead.
  • analyze_code_scanningFetches or triggers open Code Scanning (CodeQL) alerts for a GitHub repository. - Side effects: Read-only by default. If trigger_scan=true, writes to GitHub Actions by creating a workflow_dispatch event. - Data sources: GitHub REST API (code-scanning/alerts and actions). - Auth requirements: Requires GITHUB_TOKEN with appropriate permissions (security-events). - Rate limits: Subject to standard GitHub API limits. - Return shape: Returns a JSON array of alert objects including rule_id, severity, rule_description, state, location paths, and html_url. - Usage guidelines: Use this tool ONLY for deep static code vulnerability scanning (CodeQL). DO NOT use this tool for other checks: - For package/dependency vulnerabilities, use 'analyze_dependencies' instead. - For a computed A-F health score grading, use 'get_health_score' instead. - For checking standard CI/CD workflow statuses, use 'check_ci_status' instead.
  • get_health_scoreCalculates a 0-100 health score and A-F grade for a GitHub repository. - Side effects: Writes a trend snapshot to local disk for history tracking. Read-only against GitHub API. - Data sources: GitHub REST API (repos, actions, dependabot) and OpenSSF Scorecard API. - Auth requirements: No authentication required for public repositories. Uses configured token if available. - Rate limits: Subject to standard GitHub API limits (heavy usage across multiple endpoints). - Return shape: Returns a JSON object with a grade (A-F), total score, detailed category breakdown (CI, freshness, security, community, maintenance), improvement suggestions, and historical trend data. - Usage guidelines: Use this tool ONLY for deep analytical grading and overall repository health assessment. DO NOT use this tool for quick metadata checks: - For basic raw metadata (stars, language, etc.), use 'get_repo_health' instead. - For raw CI workflow statuses, use 'check_ci_status' instead. - For deep code vulnerability scanning, use 'analyze_code_scanning' instead. - For DORA metrics, use 'get_dora_metrics' instead.
  • get_dora_metricsCalculates DORA proxy metrics (deployment frequency, lead time, change failure rate, MTTR) for a GitHub repository. - Side effects: None. This is a strictly read-only operation. - Data sources: GitHub REST API (releases, actions/runs, pulls). - Auth requirements: No special authentication required for public repositories. Private repositories require GITHUB_TOKEN. - Rate limits: Subject to standard GitHub API limits. Heavy API usage due to multiple list endpoints being queried. - Return shape: Returns a JSON object with calculated DORA metrics over the specified period. - Usage guidelines: Use this tool ONLY to evaluate DORA metrics and team delivery performance. DO NOT use this tool for other checks: - For raw workflow statuses, use 'check_ci_status' instead. - For a computed A-F health score grading, use 'get_health_score' instead. - For general repository metadata, use 'get_repo_health' instead.
  • compare_reposCompares health scores of multiple GitHub repositories (2-5 repos) and ranks them. - Side effects: None. This is a strictly read-only operation. - Data sources: GitHub REST API and OpenSSF Scorecard API (via get_health_score logic). - Auth requirements: No authentication required for public repositories. Uses configured token if available. - Rate limits: Subject to standard GitHub API limits. Multiplies API calls by the number of repositories compared. - Return shape: Returns a JSON object containing a ranked list of repositories (owner, repo, rank) with their detailed health breakdown (score, CI, freshness, security, community, maintenance). - Usage guidelines: Use this tool ONLY when you need to compare or rank multiple repositories against each other based on their health scores. DO NOT use this tool for analyzing a single repository: - For getting the health score of a single repository, use 'get_health_score' instead. - For comparing raw metadata instead of health scores, query 'get_repo_health' individually.
  • check_best_practicesChecks whether a GitHub repository follows open-source community best practices. - Evaluates 12 checks: README, LICENSE, SECURITY.md, CONTRIBUTING.md, CODE_OF_CONDUCT, issue/PR templates, branch protection, Dependabot, CI/CD, description, and topics. - Returns a weighted 0-100 score with A-F grade, per-check pass/fail/unknown status, and actionable suggestions for missing items. - Side effects: None. Read-only operation. - Rate limits: ~6 GitHub API calls per invocation. - Branch protection check requires admin access — returns "unknown" (not penalized) if token lacks permission. - Use this tool to audit repo quality and discoverability. For a computed health grade based on CI/security/activity, use 'get_health_score' instead.

Stackpulse tools 16

  • search_servicesFinds services in the catalog of 9,700+ status pages by name, with their status now. Use it to find a service’s slug.
  • get_serviceOne service’s status from its official status page: what’s wrong, the components with a problem, 90 days of history and recent incidents.
  • list_outagesServices reporting a problem right now, the newest first: the 25 best-known, unless all is true or a limit is given.
  • list_dashboardsThe account’s dashboards (the ones this connection can see), with how many services and URL monitors each has and its worst status now.
  • get_stack_statusWhat’s going on now on a dashboard: a summary, then every service and URL monitor with a problem, with when the problem began and when its current status did. A URL monitor that’s down lists what started around then. Without a dashboard, every dashboard.
  • get_incident_historyIncidents on a dashboard in a window: the ones that started in it (with what else started at the same time) and the ones already going on. As far back as the plan’s history goes.
  • get_monitorOne of the account’s URL monitors: its status, its uptime over the last 30 days (or since it started) with the failed checks apart, response times, its certificate and its latest checks.
  • get_reliabilityHow reliable a dashboard’s services and URL monitors were over 7, 30 or 90 days: the least reliable first, with the share of time without a reported problem (minor issues count, so one long minor issue makes it low), time in each severity, incidents and recovery, and what tends to break together.
  • create_dashboardMakes a dashboard with a name and, optionally, services by slug (search_services finds them), within the plan’s dashboards and services. Answers with its address.
  • rename_dashboardRenames a dashboard. Its status page shares the name.
  • add_servicesAdds services to a dashboard by slug (search_services finds them), within the plan’s limit.
  • remove_servicesTakes services off a dashboard. Their history stays; adding one back shows it again.
  • +4 more on the listing page

Ready-to-paste client configs

Paste either block (or both) into your client config, e.g. claude_desktop_config.json or ~/.cursor/mcp.json. We only show a config when the install command is confirmed.

ProjectPulse MCP

mcpServers (Claude Desktop / Cursor)
{
  "mcpServers": {
    "projectpulse-mcp": {
      "command": "npx",
      "args": [
        "-y",
        "projectpulse-mcp"
      ],
      "env": {
        "GITHUB_TOKEN": "YOUR_GITHUB_TOKEN_HERE"
      }
    }
  }
}

Stackpulse

mcpServers (Claude Desktop / Cursor)
{
  "mcpServers": {
    "stackpulse": {
      "url": "https://stackpulse.app/mcp"
    }
  }
}

Frequently asked questions

ProjectPulse MCP is categorized under Monitoring and uses a local stdio subprocess. Stackpulse belongs to Monitoring and uses a remote HTTP/SSE transport. Pick ProjectPulse MCP for monitoring work and Stackpulse for monitoring.

Copy the mcpServers block from the config section on this page into your client's config (for example claude_desktop_config.json or ~/.cursor/mcp.json), then fully restart the client.

ProjectPulse MCP is listed as free. Stackpulse has no declared pricing — check the project's own site. If a server needs environment variables such as API keys, define them under the env key in your client's MCP config.

Yes. MCP clients support multiple servers: add projectpulse-mcp and stackpulse as separate keys in the same mcpServers object, and your assistant will call tools from either one.

On AllMCPs, ProjectPulse MCP has a quality signal of 64/100 (Good) with 4 views, 0 installs and 1 GitHub stars. Stackpulse has 51/100 (Good) with 1 views, 0 installs and 0 GitHub stars.