Check in CI (GitHub Action)

The on-demand check is also a GitHub Action. After each deploy it probes your remote MCP server, writes the result to the job summary with a shareable link, and fails the step when the gate you set is not met. It catches regressions before your users or a directory review do: annotations dropped from a tool, a tool list that grew to thousands of tokens, a broken OAuth metadata document, a server that stopped answering the 2026-07-28 protocol.

The action is open source: protogrid-dev/check-action, one JavaScript file with no dependencies.

Before you start

• Your server must be reachable from the internet. The checker refuses private, loopback and internal addresses, so run the step after deploying to staging or production, not against a server started inside the runner.
• You need a free API key: sign in at protogrid.dev with GitHub, create a key, and store it as a repository secret named PROTOGRID_API_KEY.

Workflow

jobs:
  deploy:
    # ... your deploy to staging ...
  mcp-check:
    needs: deploy
    runs-on: ubuntu-latest
    steps:
      - uses: protogrid-dev/check-action@v1
        with:
          url: https://staging.example.com/mcp
          api-key: ${{ secrets.PROTOGRID_API_KEY }}
          min-score: 75
          directories: openai

input	default	meaning
url	required	Public URL of the remote MCP server.
api-key	required	Your protogrid API key, from a secret.
min-score	none	Fail when the quality score is under this; a server that cannot be scored fails it too.
directories	none	claude, openai or both: fail on any blocker of those directories.
timeout-seconds	120	How long to wait for the result.

The step always fails when the server does not answer the probe. A server that answers with an OAuth challenge counts as answering. Warnings and heuristic “review” items are reported but never fail the step.

Outputs: check-id, page, outcome, score, label, claude-blockers, openai-blockers and passed, for later steps.

What you get

The job summary shows the quality score and label, the score of each category, every check that warns or fails with its reason, and the directory readiness counts with each open item. The same result is on protogrid.dev behind the page link for 30 days.

Limits

Every run is a fresh check (it never reuses a result from before your deploy) and counts against your account’s hourly allowance of on-demand checks: 30 an hour with a free key. One server host can be checked 12 times an hour in total, whoever asks, so check once per deploy rather than on every commit of every branch.

The check never uses credentials and never calls your tools: servers behind OAuth or an API key get the authorization checks, and the tool checks are not applicable. No audit is implied.