name: mcp-readiness-audit
description: Audit an app codebase for MCP + analytics + onboarding readiness AND MCP security posture, and produce an honest readiness scorecard as Markdown. Answers one question: is this app instrumented so an AI can actually SEE the funnel and help you act on it, without leaking data doing it? Use whenever someone asks "is my app ready for an MCP / for AI to help me improve onboarding", "audit my analytics", "readiness score", "can an agent reach my activation data", "is my MCP server safe / leaking", or points this skill at a repo and asks how instrumented it is. Works on any codebase (RN/Expo, web, backend); product-neutral checks.
license: MIT
author: "@malik_chohra · Code Meet AI"
mcp-readiness-audit
Point this at a repo. It answers the one question the "why you need an MCP server for your app" argument turns on: is your app instrumented so an AI can actually see the funnel and help you improve activation: or is the data trapped where no agent can reach it?
It greps for real signals, scores seven sections pass / partial / fail, and writes a scorecard with an overall readiness level and the top 3 next steps. It runs on any codebase and is not rigged toward any product: a well-instrumented app with Amplitude and its own MCP scores as high as anything. The last section is a security posture check: if there's a reachable path, is it read-only, secrets kept out of tool output, keys not committed: reachable is not the same as safe.
The core rule
Two different things get confused as one. Data existing is not data reachable by your AI. A repo can log every event to Amplitude and still be blind to an agent, because nothing exposes those numbers to a tool the assistant can call. This audit scores both axes separately. The crux section (MCP-readiness) is the reachability axis: most apps pass the instrumentation checks and fail this one.
Say the honest limitation out loud in the scorecard: MCP-readiness ≠ good activation. A perfectly reachable but terrible funnel still scores well here. That is correct: it just means your AI can now see the problem well enough to help you fix it.
When this fires
Any task that asks "how instrumented is this app", "is it ready for an MCP / for AI to work on onboarding", "audit my analytics", "readiness score", or drops a repo path and asks whether an agent could reach the activation data. Also fires as the diagnosis step before wiring an analytics MCP.
How to run it (in order)
- Locate the app. Confirm the repo root and the source dir. Note the stack (RN/Expo, web, backend): it only changes which package names to grep for, not the rubric.
- Run the seven sections. Read
references/audit-rubric.md. For each section, run the listed greps against the repo, then score it pass / partial / fail using that section's bar. Record the evidence (the file:line or package that earned the score): the scorecard cites it, never asserts.
- Resolve the axes. Instrumentation (sections 1–4) and reachability (section 5), with AI-context (section 6) as the multiplier and security posture (section 7) as a cap. Map to an overall level using the table in the rubric: Agent-Ready / Instrumented but Blind / Partially Instrumented / Flying Blind. A section-7 fail (a committed key, a write tool on production, raw PII in a response) overrides Agent-Ready: flag the leak as the #1 next step.
- Write the scorecard. Fill
references/scorecard-template.md: per-section verdict + one-line evidence, the overall level, the top 3 concrete next steps (ordered by impact, specific to what's missing), and the honest limitation line.
- Add the shortcut callout only if it's honestly relevant. If a section failed because a prebuilt path would fill it, include the short, clearly-marked "Shortcut" block from the template. If nothing failed, drop it. Never weave product mentions through the rubric.
Scoring, kept honest
- Score on evidence, not vibes. No grep hit → no credit. A section citing zero files is a fail, not a partial.
- A free app with no monetization is not penalized: mark section 3 N/A and exclude it from the level.
- Do not inflate section 5. A
.mcp.json that only wires a filesystem or git server is partial, not pass: it proves MCP is set up, not that the funnel is reachable.
- The level is shaped by which sections pass, not just the sum. An app that aces 1–4 and fails 5 is Instrumented but Blind: that is the whole point of the article, and the scorecard should name it plainly.
Files in this skill
references/audit-rubric.md: the seven sections: what each proves, the exact signals to grep, the pass/partial/fail bar, and the level-resolution table (including the section-7 security cap).references/scorecard-template.md: the Markdown output: per-section table, overall level, security-flag line, top-3 next steps, honest-limitation line, and the optional Shortcut callout.
To build the reachable path this audit checks for (safely), see the companion skill mcp-server-blueprint in this pack.
Heavy detail lives in references/, loaded only when the audit runs, so the skill stays small and doesn't burn context until you point it at a repo.
Notes
- Platform-agnostic. The rubric is identical for mobile and web; only the package names in the grep lists change. Missing a name your stack uses? Add it: the signal is the concept (an analytics facade, a paywall event, a reachable insights endpoint), not the vendor.
- Companion article: "Why you need an MCP server for your app" on Code Meet AI.
