Operating ProcedureExecution layer

MCP Census Client MCP Config Audit (Onboarding)

A sequence with 8 steps: Create the MCP Census account and generate an API key.

By InnovaAI ResearchPublished

What are the steps?

sequence

MCP Census Client MCP Config Audit (Onboarding)

  1. 01

    Create the MCP Census account and generate an API key

    Register without a card, then issue a key so lookups draw from the 1,000-credit monthly grant instead of the anonymous 10 unique lookups/day per IP cap. Credits do not roll over, so size the client engagement against the current UTC month.

  2. 02

    Collect the client's .mcp.json and inventory every server entry

    Pull the config from whichever stack the client runs (Claude Code, Codex, Cursor, VS Code) and list each server with its source: registry, GitHub repo, npm package, PyPI package, or hosted endpoint. This list becomes the audit scope line in the client report.

  3. 03

    Run the full config through the /v1/audit endpoint in one call

    Submit the config so each entry returns one of PASS, REVIEW, BLOCK, or UNKNOWN with reasons and an exit code. Capture the raw response as the evidence artifact; do not paraphrase verdicts in the client deliverable.

  4. 04

    Triage REVIEW and UNKNOWN entries before anything ships

    PASS entries clear for install. BLOCK entries come out of the config. REVIEW and UNKNOWN need a human decision, and the client signs off on each one in writing, because Census is a first gate and not a malware scan.

  5. 05

    Stamp the cleared servers and record the evidence

    Use the stamp capability on the Builder tier ($19 monthly, 2,000 credits) or above to attach verdict evidence to each approved server. Store stamps alongside the audit response so the client has a dated record of what was checked and when.

  6. 06

    Embed the gate in the client's agent workflow

    Add the one-line Census rule to CLAUDE.md, AGENTS.md, or .cursor/rules so agents stamp servers before install, and add a preflight step to GitHub Actions so CI fails on BLOCK. This converts a one-time audit into a standing control the retainer can cover.

  7. 07

    Subscribe a webhook watch on the highest-risk servers

    Set watches on the servers most likely to change upstream, then route alerts to the client's channel. Watches and the change feed are paid-tier features, so confirm the plan covers the watch count before promising coverage in the SOW.

  8. 08

    Deliver the risk report and set the re-audit cadence

    Ship a plain-language report listing every server with its verdict, the sign-off on REVIEW and UNKNOWN items, and the watch list. Schedule the next full audit against the client's change feed cursor so the follow-up only re-checks what shifted.