This server provides a production-readiness audit engine for AI-built apps, enabling deterministic project scanning, scoring, and remediation planning via an MCP interface.
describe: Retrieve the full CheckYourself capability manifest, including commands, schemas, scoring rules, and MCP capabilities.
scan: Run deterministic local discovery and obvious-risk checks (e.g., committed secrets, debug flags, wildcard CORS, missing lockfiles) against a project path, with an optional deep validation mode.
coverage_emit: Generate a 20-surface coverage skeleton for an AI agent to populate with evidence during a full diagnostic audit.
coverage_check: Validate a filled coverage object for completeness and evidence requirements, flagging incomplete or missing entries.
score: Compute the deterministic Production Reality Score (0–100) from findings and optional coverage data, applying severity caps so serious risks cannot be hidden behind polish.
backlog: Prioritize all findings into a complete remediation backlog ordered by harm, reversibility, and learning value, and propose a first approval-ready fix batch.
next: Return the next safest unresolved approval batch from current findings, enabling a guided, incremental fix loop.
validate: Check a JSON artifact against a bundled CheckYourself schema subset to ensure structural correctness.
schema: Fetch a specific bundled JSON schema by name for use in validation or agent workflows.
Integrates with GitHub Copilot to provide pre-launch production-readiness audits for AI-built applications, leveraging file-reading capabilities for diagnostics.
Allows Replit users to run CheckYourself audits directly in the Replit environment, using its file-aware agents to perform read-only production checks.
For AI app builders, CheckYourself runs local challenges to test claimed work, record evidence, and expose risks. Score is not a guarantee.
Check yourself before you wreck yourself — for the apps you ship. Before you launch it, CheckYourself.
CheckYourself is a free, open-source, model-agnostic completion-evidence workflow for apps built with AI coding assistants. It turns any AI assistant — Cursor, Claude, ChatGPT, Gemini, Copilot, Windsurf, Replit, Lovable, Bolt, Codex, or a local agent — into a pre-launch reviewer that inspects your app, records observed and untested behavior, runs verifier-owned challenges, surfaces production gaps, proposes fixes for your approval, verifies local receipts, and writes a learning plan built from the exact gaps your own project had.
Under the hood it is a staged engineering system, not a single canned prompt: an ICM-style context workspace that routes the agent through each stage, an evidence-based 0–100 scoring method with severity caps, verifier-owned challenges across 20 canonical surfaces and 10 scored categories, a 19-capability production-hardening engine spanning auth, data, secrets, CI/CD, observability, privacy, and AI governance, JSON output schemas, report and risk templates, and a public validation suite. You install it as your AI assistant's operating context — no SaaS, no account, no lock-in to any one model.
The 2026-09-05 retrofit checkpoint is backed by 150 tests and 88 subtests, and python3 tools/validate_public.py . passes. These are repository checks, not a production-safety certification.
Related MCP server: Architect-to-Product (A2P)
CheckYourself is an open-source reviewable completion-evidence system — a structured, staged engineering framework of context files, scoring logic, output schemas, templates, and production-hardening guidance. It records what was observed, what was inferred, what remains untested, and which risks still block launch; its verifier executes committed local challenges, rechecks stored executed receipts at score time, and validates report verdict consistency. It does not certify production safety or provide independent external custody of the evidence.
It answers one question that matters to every "vibe coder," indie hacker, and AI-assisted builder: "Is this app actually ready to ship, and if not, what exactly is wrong and how do I fix it?"
Unlike a "top three issues" linter, CheckYourself builds a complete findings register and a complete remediation backlog, produces a bounded 0–100 evidence score, and walks you through fixes one safe, reversible batch at a time. When the audit is done, it generates a bespoke learning plan so you actually learn from what your project was missing. The score remains scoped evidence, not a production-safety guarantee.
It is also organized as an ICM-style context workspace: CONTEXT.md routes the agent to staged folders, each major stage has its own CONTEXT.md, and durable handoff artifacts belong in stage output/ folders. CheckYourself is not affiliated with the RinDig ICM project; it uses the same file-first idea so agents know what to read, do, and produce at each step.
Apps built fast with AI tools tend to look finished long before they are safe to launch. The gaps are usually invisible from the happy path: missing auth checks, unvalidated inputs, leaked secrets, no backups, no rollback, no tests, no rate limits, no error tracking.
CheckYourself gives you reality before production does the grading — a calm, complete, plain-English second pass that any AI assistant can run on your behalf.
Download or clone this repository.
Put the checkyourself folder in or next to your project.
Point your AI coding assistant at the folder as its operating context. Start at CONTEXT.md — it routes the agent through each stage without loading the whole repo. New to the system? Read START_HERE.md first.
Run a read-only diagnostic and review the Production Reality Report.
Approve fixes one at a time or in safe, reversible batches.
Recheck and rescore after each batch.
Continue until every finding is fixed or proven not applicable; keep deferred, accepted-risk, and suppressed items visible as residual risk with owner and trigger context.
Get a custom learning plan based on the actual gaps.
No model lock-in. No required cloud account. No required command line.
Once the folder is in place, tell your AI assistant how to operate within it:
Use the checkyourself folder as your operating context.
Start with a read-only diagnostic.
Do not make code changes until I approve a specific fix.
Generate the dashboard only if I say `dashboard yes` or `dashboard inline`.
After the diagnostic, create a learning plan based on the gaps you found.
Add the folder → run the audit → review the full backlog → approve fixes → verify → repeat → learn what you missedCheckYourself is not a "top three issues" tool. It creates a complete findings register and a complete remediation backlog. The first approval batch is intentionally small so fixes stay safe, understandable, and reversible.
Default outputs (see a real example in samples/sample-production-reality-report.md):
Project Map — what your app appears to do.
Detected Stack — framework, database, auth, hosting, tests, deployment signals, and confidence.
Production Reality Score — a 0–100 score with caps and reasoning (how the score works).
Coverage Sweep — every relevant production surface marked Pass, Finding, Unknown, or Not applicable.
Complete Findings Register — every discovered risk, not just the obvious ones.
Complete Remediation Backlog — every finding and blocking unknown in a deterministic severity, category, and finding-ID order.
Highest-Severity Approval Batch — a small unresolved slice for review, not the whole scope. The local CLI does not infer safety, dependencies, coupling, or blast radius; the diagnostic and human approval gate still do.
Guided Fix Loop — approve, fix, verify, rescore, repeat.
Bespoke Learning Plan — what to learn next based on what your own app was missing.
Optional output:
Human Audit Dashboard — one self-contained HTML/CSS dashboard that visualizes the score, risks, backlog, coverage, status, and learning plan. It is optional because dashboards use extra tokens. Ask for it with dashboard yes, or use dashboard inline for the compact Markdown fallback.
The challenge verb executes the committed .checkyourself/challenges.json definitions against the project under review. The runner accepts argv-only commands, applies bounded timeouts, and treats a failed or timed-out challenge as a fail-closed finding. The verifier owns the execution receipt: a successful EXECUTED receipt is the only class eligible for full credit; caller-issued receipts remain explicitly UNVERIFIED and are capped.
At score time, stored executed receipts survive only a fresh verifier run that agrees on the exit state, success assertions, source and challenge bindings, and a semantic output digest. The digest normalizes volatile durations, timestamps, and paths while the raw capture hash still detects edits. Verifier-owned per-surface minimum contracts reject or cap semantic vacuity such as true, false, echo-only or print-only commands, hollow test-runner output, and trivial regexes.
The local integrity HMAC is project-local tamper evidence. It is not proof of independent issuance, operator identity, or external custody; externally controlled custody is future work. --claim records the accepted completion claim and labels evidence rows as claim-bound or unbound. Report validation labels schema validity separately from semantic verdict consistency and recomputes the verdict rather than trusting the supplied score.
The ASTRA adversarial review found eight findings and the retrofit closed them; the evidence trail is ASTRA-REVIEW.md and ASTRA-FIX-REPORT.md.
The diagnostic sweeps the whole relevant production surface:
product purpose, users, and harm model;
frontend UX, accessibility, and client safety;
API/backend behavior, validation, uploads, and webhooks;
auth, permissions, sessions, roles, and admin paths;
data storage, migrations, backups, and tenant/user isolation;
secrets, environment variables, and runtime configuration;
tests, quality gates, and regression coverage;
CI/CD, supply chain, dependencies, and release safety;
deployment, rollback, hosting, and environments;
observability, logs, errors, alerts, and incident response;
performance, scaling, caching, and rate limits;
privacy, compliance, data retention, and consent;
AI/RAG/agent governance when applicable.
The full technical engine lives in 90_ADVANCED/, but users do not need to read it first.
CheckYourself is model-agnostic and ships as plain Markdown, so it runs in any AI assistant that can read text or files:
Category | Tools |
AI IDEs & editors | Cursor, Windsurf, GitHub Copilot, Codex |
Chat assistants | ChatGPT, Claude, Gemini |
App builders | Replit, Lovable, Bolt |
Local & custom agents | any local model or agent that reads files |
Tool-specific setup guides live in 06_ADAPTERS/.
CheckYourself is for people who build with AI and want reality before production does the grading:
beginners learning by doing;
intermediate builders who can ship but want a safer second pass;
experienced developers who want a reusable audit context;
AI-built app learners and community builders;
Cursor, Windsurf, Replit, Lovable, Bolt, ChatGPT, Claude, Gemini, Codex, and local-agent users;
founders, freelancers, agencies, and teams preparing real launches.
CheckYourself runs as a staged workflow, each stage with its own context file so your AI tool always knows what to read, do, and produce:
Project context — the agent maps what your app does and detects the stack.
Run diagnostic — a read-only sweep produces the Production Reality Report and score.
Guided fix mode — you approve fixes in safe batches; the agent applies and verifies them.
Learning plan — the agent writes a plan from the real gaps it found.
Dashboard (optional) — a self-contained HTML or inline Markdown view of everything.
Each stage is defined by its own context files, scoring rules, schemas, and templates — so the agent always knows what to read, what to do, and what to produce. The advanced engine in 90_ADVANCED/ deepens any stage when a domain warrants it.
For a zero-token head start, CheckYourself ships a small optional scan & scaffold CLI — standard library only, no network, no secret values printed:
python3 tools/checkyourself.py /path/to/your/projectIt detects your stack, flags obvious deterministic risks (possible hardcoded secrets, a committed .env, missing .env.example, absent tests or CI) ranked P0–P3, and writes a pre-filled context file your AI can build on. Add --json for a machine-readable summary, --format json --no-write for JSON stdout, or --ci to use it as a lightweight pipeline gate (non-zero exit on a P0). The challenge verb executes committed challenge definitions; score re-executes stored executed receipts; validate --kind report separates schema validity from semantic verdict consistency. The CLI is a scaffold for discovery, not a production-safety certification. See docs/cli.md.
The CLI is the canonical local engine, and CheckYourself also ships a thin local stdio MCP wrapper for native-agent clients. There is no hosted API for the current open-source product. See docs/cli.md, docs/mcp.md, and docs/agent-access-cli-plan.md.
The Markdown report is the default output because it is cheaper, faster, and easier for most AI tools to produce.
This repository includes a real dogfood dashboard screenshot from CheckYourself auditing itself:
After the report exists, say either:
dashboard yesThe AI creates one self-contained HTML/CSS dashboard from the report — it should not re-run the audit just to make the dashboard. If you do not want HTML, ask for:
dashboard inlineor:
dashboard inlineThe first creates one self-contained HTML/CSS file. The second returns the compact Markdown dashboard shape instead of creating a file.
Dashboard files:
CheckYourself uses progressive context loading so audits stay affordable even on large projects:
Start with the stage context and coverage matrix.
Load advanced files only when a domain is relevant.
Keep the complete findings register compact.
Expand details for P0/P1 items and the next approval batch.
Do not paste long source files, logs, or reference docs back to the user.
Generate the HTML dashboard only when the user asks for it.
Start read-only. CheckYourself inspects, explains, and recommends before any code or config changes happen. Fixes require explicit user approval, are applied in small reversible batches, and are re-verified and re-scored after each batch. This is the single most important rule in the system.
CheckYourself is a free, open-source, model-agnostic review workflow that turns any AI coding assistant into a reviewer of completion evidence for AI-built apps — a staged diagnostic workspace, verifier-owned challenges, a bounded evidence-based score, a complete findings register and remediation backlog, approval-based guided fixes, and a 19-capability hardening engine that surfaces gaps, explains the risks, and teaches you what remains unproven.
No build step, no dependencies, and no required command line. You load CheckYourself as your AI assistant's operating context and it works through the stages with you. It also ships a small optional Python CLI and validator for maintainers and agent workflows, but you never need them to run an audit.
Any model-agnostic assistant that reads text or files, including Cursor, Windsurf, GitHub Copilot, Codex, ChatGPT, Claude, Gemini, Replit, Lovable, Bolt, and local agents.
Yes. CheckYourself starts read-only by default. It will not change code or configuration until you approve a specific, reversible fix, and it re-verifies after every batch.
A linter flags style and a few obvious problems. CheckYourself builds a complete findings register and remediation backlog across the entire production surface — auth, data, secrets, CI/CD, deployment, observability, privacy, and more — then guides fixes and produces a learning plan.
It is a bounded 0–100 evidence score with severity caps and explicit reasoning, explained in docs/checkyourself-score-explained.md. A low score with clear unknowns is more useful than a falsely high one; the score is not a production-safety guarantee.
The challenge verb executes committed argv-only definitions from .checkyourself/challenges.json with timeouts and fail-closed results. Only verifier-executed EXECUTED receipts can receive full credit. The scorer re-executes stored receipts and compares exit state, assertions, and a normalized semantic output digest; caller-issued receipts are UNVERIFIED and capped.
No. It detects tampering with project-local challenge receipts. It does not prove independent issuance, operator identity, or external custody; externally controlled custody is future work.
Yes — it is released under the Apache License, Version 2.0 and is free to use, copy, and adapt under those terms.
Vibe coders, indie hackers, beginners learning by doing, intermediate builders, experienced developers wanting a reusable audit, and founders, freelancers, agencies, and teams preparing real launches.
Issues and pull requests are welcome. See CONTRIBUTING.md and the CHANGELOG.md for project history.
Apache License, Version 2.0 — free and open source. See LICENSE.
CheckYourself is a local-first completion-evidence review system for apps built with AI that helps founders and engineers shipping AI-generated apps test claimed work with verifier-owned challenges, record evidence, and surface unresolved risk.
Product | CheckYourself |
Category | Local-first completion-evidence review for apps built with AI |
Best for | founders and engineers shipping AI-generated apps |
Not | a generic linter or code formatter |
Source | |
Keywords | AI app completion evidence, verifier-owned challenge, pre-launch review |
Primary: founders and engineers shipping AI-generated apps
Use when you need to test claimed work with evidence-backed findings and a fix path
Skip if you need a generic linter or code formatter
CheckYourself is a reviewable completion-evidence workflow for AI-built apps. It helps founders and engineers record observed behavior, unresolved assumptions, evidence-backed findings, and a bounded score with a fix path.
founders and engineers shipping AI-generated apps.
Unlike style linters, CheckYourself records reviewable evidence and unresolved risk, not only style. It does not replace production tests, expert review, or independent external custody of the original completion claim.
Treat the README status and release tags as source of truth for maturity. Validate against your own requirements before production use.
Maintained as of 2026 on the default branch
Prefer release tags when pinning dependencies
Report issues on the canonical remote listed above
Coding agents: read this README first, then repo docs/AGENTS.md if present
Prefer machine-readable briefs (llms.txt) when the repo ships one
MCP or skill entrypoints are documented in-repo when applicable
Issues and PRs welcome on the canonical remote. Keep public docs free of secrets and machine-local paths.
See LICENSE in this repository (or package metadata if license is package-only).
Normalize inline findings and return the complete remediation backlog sorted by severity, category, and finding ID. The highest_severity_batch is a deterministic severity slice; safety and dependency analysis are not performed. Each item includes fix summary, order rationale, verification, rollback idea, learning value, and status. This recommends work only; it does not modify files or mark findings resolved. Requires no authentication. It reads local inputs only, does not make network calls, does not modify local files, and has no external rate limits.
| Name | Required | Description | Default |
|---|---|---|---|
| findings | Yes | Scan result object, CheckYourself report object, object with findings/remediation_backlog, or a plain list of finding objects to convert into a remediation backlog. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, and non-destructive behavior. The description adds meaningful details: no file modifications, no marking resolved, no authentication, no network calls, and no external rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is mostly efficient and front-loaded, though a couple of phrases overlap slightly ('recommends work only' and 'does not modify files'). Overall, every sentence adds useful context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers inputs, output item fields, sorting behavior, determinism, side-effect guarantees, and environmental constraints, making it complete enough even without a detailed output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter has 100% schema coverage, and the description enriches it by enumerating the accepted input forms: scan result object, CheckYourself report object, object with findings/remediation_backlog, or plain list.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description states a specific action (normalize and return) on a specific resource (remediation backlog) with clear sorting criteria, distinguishing it from sibling tools like scan or score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by describing what the tool does and its limitations, but it does not explicitly name sibling alternatives or provide when-to-use versus when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate an inline CheckYourself coverage object for required surfaces, valid statuses, reviewed evidence, missing-evidence notes, and not-applicable reasons. Returns errors and warnings; it does not calculate a score. Requires no authentication. It reads local inputs only, does not make network calls, does not modify local files, and has no external rate limits.
| Name | Required | Description | Default |
|---|---|---|---|
| coverage | Yes | Coverage object produced by coverage_emit and filled with evidence statuses. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare read-only, idempotent, non-destructive behavior. The description adds meaningful behavioral transparency beyond annotations by stating that it requires no authentication, reads local inputs only, makes no network calls, modifies no files, and has no rate limits. It also clarifies output shape as errors and warnings.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded, immediately stating the core action and target. Every sentence adds useful information without redundancy or filler, and the key differentiator ('does not calculate a score') is placed prominently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the single parameter and validation purpose, the description provides enough context for correct invocation: what input is expected, what checks are performed, and what kind of result is returned. It could be slightly more explicit about output format, but the presence of an output schema reduces the need for that detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter is described in the schema, and the tool description enriches it by explaining what aspects of the coverage object are validated. While the nested structure is not fully detailed, the description compensates by specifying the validation categories, making parameter semantics clear beyond a bare object type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Validate') and identifies the exact resource: an inline CheckYourself coverage object. It enumerates the specific aspects checked and explicitly distinguishes from score calculation, making its role distinct from sibling tools like coverage_emit and score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context on what the tool does and explicitly notes what it does not do ('does not calculate a score'). It does not name sibling tools as alternatives, but the behavior is specific enough that an agent can infer when to use this validation tool versus emitting or scoring coverage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the 20-surface CheckYourself coverage skeleton that an agent fills with manual evidence, missing-evidence notes, and not-applicable reasons before coverage-backed scoring. In MCP mode this only returns the skeleton object; it does not create a file. Requires no authentication. It reads local inputs only, does not make network calls, does not modify local files, and has no external rate limits.
| Name | Required | Description | Default |
|---|---|---|---|
| project | No | Optional project label or path to include in the returned coverage skeleton. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond annotations by stating 'Requires no authentication', 'reads local inputs only', 'does not make network calls', 'does not modify local files', and 'has no external rate limits'. These are concrete behavioral details not captured in the annotations, fully disclosing side effects and operational characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with the core purpose front-loaded and the MCP-specific behavior immediately following. Every sentence adds value, and there is no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, usage timing, behavioral side effects, and parameter context. Combined with the annotations and the presence of an output schema (which describes the return format), an agent has everything needed to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'project' has a schema description that already explains it as 'Optional project label or path to include in the returned coverage skeleton.' The tool description does not add extra meaning beyond the schema. With 100% schema coverage, the baseline of 3 is appropriate; the description neither adds nor detracts.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns the '20-surface CheckYourself coverage skeleton' for filling with manual evidence, missing-evidence notes, and not-applicable reasons before coverage-backed scoring. It specifies a specific verb, resource, and purpose, distinguishing it from sibling tools like coverage_check or score without naming them explicitly but contextualizing its role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says 'before coverage-backed scoring', indicating when to use it. It also clarifies that in MCP mode it returns the skeleton only and does not create a file, which helps an agent understand the read-only context. It doesn't explicitly mention alternatives or when not to use it, but the purpose is clear enough for routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return CheckYourself's machine-readable capability manifest: CLI commands, MCP transport, schema names, scoring weights, score caps, coverage surfaces, exit codes, and public-repository scope guardrails. This is a read-only discovery tool and does not scan a project. Requires no authentication. It reads local inputs only, does not make network calls, does not modify local files, and has no external rate limits.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already carry readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the bar is lower. The description adds genuinely new behavioral context beyond those flags: 'Requires no authentication,' 'reads local inputs only, does not make network calls, does not modify local files, and has no external rate limits.' These claims are fully consistent with the annotations — no contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero filler. The core purpose is front-loaded, the manifest contents are packed into a dense but relevant enumeration, and the behavioral constraints form a tight second sentence. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return-value explanation is not required, and the description covers everything else: purpose, scope boundaries (does not scan), and behavioral guarantees (auth, network, file modification, rate limits). Nothing an agent needs to call this safely and correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the schema trivially covers 100% and needs no elaboration. The baseline for a 0-param tool is 4, and the description appropriately compensates by detailing what the tool returns rather than attempting param documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb ('Return') and a clearly scoped resource: CheckYourself's machine-readable capability manifest. It enumerates exactly what the manifest contains (CLI commands, MCP transport, schema names, scoring weights, caps, coverage surfaces, exit codes, guardrails), and explicitly distinguishes itself from scan ('does not scan a project'). This is unambiguous and differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear usage context — a read-only discovery tool that surfaces the tool's own capabilities — and explicitly rules out one sibling ('does not scan a project'). It doesn't name alternatives for when a different tool would be preferred (e.g., schema vs. describe), but the discovery intent is clear enough that an agent would know when to invoke it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compare two inline findings artifacts (scan results, reports, or finding lists) and return added, resolved, unchanged, status and severity transitions, evidence-level changes, severity count deltas, and a regression flag that is true for newly open, reopened, or escalated P0/P1 findings or increased counts. Use this to gate changes against a baseline. Requires no authentication. It reads local inputs only, does not make network calls, does not modify local files, and has no external rate limits.
| Name | Required | Description | Default |
|---|---|---|---|
| new | Yes | Scan result object, CheckYourself report object, object with findings/remediation_backlog, or a plain list of finding objects to treat as the current state. | |
| old | Yes | Scan result object, CheckYourself report object, object with findings/remediation_backlog, or a plain list of finding objects to treat as the baseline. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond the annotations by explicitly stating 'Requires no authentication', 'reads local inputs only', 'does not make network calls', 'does not modify local files', and 'has no external rate limits'. This fully aligns with the readOnlyHint/idempotentHint annotations and provides strong reassurances about side effects and dependencies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but well-organized: it leads with purpose, lists specific outputs, gives a usage directive, and then provides behavioral guarantees. No redundant or filler content is present, and every sentence adds useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description fully covers what the tool returns (including the exact conditions for the regression flag), what each input represents (current state vs baseline), and the behavioral context (local, no side effects). Combined with the provided output schema, an agent has everything needed to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters have schema descriptions, and the tool description further clarifies accepted input forms: 'Scan result object, CheckYourself report object, object with findings/remediation_backlog, or a plain list of finding objects'. This adds meaningful detail beyond the raw schema and resolves ambiguity about input shapes.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific verb 'Compare' and the resource 'two inline findings artifacts', and enumerates the detailed outputs (added, resolved, unchanged, status/severity transitions, etc.). This distinguishes it from sibling tools like scan or backlog, making its function immediately identifiable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this to gate changes against a baseline', giving a concrete scenario for when to select this tool. It does not name alternative tools or explain when not to use it, but the use case is still clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the next highest-severity unresolved approval batch from inline findings by reusing the backlog ranking rules. The batch contains at most the first three unresolved findings at the highest current severity; safety and dependency analysis are not performed. This is a planning tool only and does not perform fixes. Requires no authentication. It reads local inputs only, does not make network calls, does not modify local files, and has no external rate limits.
| Name | Required | Description | Default |
|---|---|---|---|
| findings | Yes | Scan result object, CheckYourself report object, object with findings/remediation_backlog, or a plain list of finding objects to batch into the next approval group. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description is highly transparent: no authentication, reads local inputs only, no network calls, no file modifications, no external rate limits, and idempotent/read-only behavior. This aligns with the annotations and leaves nothing hidden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact yet comprehensive, covering purpose, constraints, and side effects in two sentences. It is well-structured and every sentence adds meaningful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no destructive actions), the description fully covers all relevant aspects: purpose, input, behavior, limitations, and side-effect-free guarantees. Nothing is missing for correct invocation and understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides a detailed description of the 'findings' parameter covering multiple accepted forms. The tool description adds minimal extra context ('to batch into the next approval group'), so with 100% schema coverage, a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns the next highest-severity unresolved approval batch from inline findings using backlog ranking rules. It specifies the verb 'Return' and the resource 'approval batch', and distinguishes itself as a planning-only tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says this is a planning tool only and does not perform fixes, which gives clear usage guidance. It does not name sibling alternatives directly, but the context of planning vs. fixing is communicated effectively.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Issue one verifier-hashed receipt only for an existing, registered surface-specific verification artifact under the configured MCP scan root. The result is returned inline and is not written to disk. Requires no authentication. It reads local inputs only, does not make network calls, does not modify local files, and has no external rate limits.
| Name | Required | Description | Default |
|---|---|---|---|
| claim | Yes | One claim proved by the receipt. | |
| result | Yes | Observed result recorded at issuance. | |
| command | Yes | Command recorded at issuance. | |
| reference | Yes | In-root registered verification artifact path to hash. | |
| surface_id | Yes | Canonical coverage surface ID. | |
| source_state | Yes | Source/environment state examined. | |
| subject_digest | No | Optional content hash assertion for the registered verification artifact. | |
| source_revision | Yes | Source revision examined. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnly, idempotent, non-destructive), the description adds concrete behavioral details: result returned inline and not written to disk, no authentication, no network calls, no local file modifications, no external rate limits. This fully discloses side effects and operational characteristics, exceeding the baseline set by annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is composed of four sentences, each adding distinct information (purpose, output handling, authentication, operational traits). It is front-loaded with the core purpose and efficient, though slightly longer than strictly necessary; no filler exists.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 8 parameters (all schema-described) and an output schema, the description covers operational context, prerequisites (existing registered artifact), and behavioral guarantees. It lacks only a mention of the optional subject_digest parameter, but that is already documented in the schema, so the description is sufficiently complete for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so each parameter already has a clear description. The tool description does not add extra meaning beyond what the schema provides, and the baseline of 3 applies since the schema carries the semantic weight.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action (issue a verifier-hashed receipt) with clear constraints (only for existing, registered artifacts under the MCP scan root). It clearly distinguishes itself from siblings like coverage_emit or coverage_check by focusing on receipt issuance, not coverage calculation or emission.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides a usage constraint ('only for an existing, registered surface-specific verification artifact') but does not explicitly name alternatives or say when not to use this tool versus siblings. The 'only' implies a precondition but offers no comparative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Inspect a local project directory for deterministic production-readiness signals: stack, scripts, CI, tests, environment files, obvious secret/config risks, generated findings, counts, and public-repo claim guardrails. MCP mode returns JSON only; it does not write generated files or apply fixes. Requires no authentication. It reads local inputs only, does not make network calls, does not modify local files, and has no external rate limits.
| Name | Required | Description | Default |
|---|---|---|---|
| deep | No | Run slower validation checks for detected surfaces, such as mutable GitHub Action references. Defaults to false. | |
| project | No | Project root path to inspect, confined to CHECKYOURSELF_SCAN_ROOT (default: the MCP server process current directory). | |
| max_files | No | Maximum files to scan before truncating (default 6000). The result reports skipped inputs and incompleteness in scan_limits. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral details beyond the annotations: it returns JSON only in MCP mode, does not write generated files or apply fixes, requires no authentication, reads local inputs only, makes no network calls, modifies no local files, and has no external rate limits. These disclosures exceed the readOnly/idempotent hints and give a clear operational picture.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact yet information-dense, listing the key signals in a single sentence and then adding important constraints (JSON-only, no writes, no auth, no network) without unnecessary padding. The main purpose is front-loaded, and every sentence contributes to the agent's understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers what the tool inspects, what it returns (findings, counts, guardrails), its mode of operation (JSON only, no writes/fixes), security context (no auth, no network), and limitations (max_files truncation handled in scan_limits). This is sufficient for an agent to decide when and how to invoke it, even without seeing the full output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% parameter coverage with descriptive text for each parameter (deep, project, max_files). The tool description does not add any additional parameter-specific meaning beyond what the schema states, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Inspect a local project directory') and a clear resource (local project) with a defined outcome (production-readiness signals). It lists concrete signals (stack, scripts, CI, tests, environment files, secret/config risks, findings, counts) that distinguish it from sibling tools like describe, score, or validate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains what the tool does and its non-destructive, local-only nature, but it does not explicitly contrast with sibling tools or state when to use this tool over alternatives. An agent can infer its niche from the listed signals, but the guidance is implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return a bundled CheckYourself JSON schema by name so an agent can inspect expected fields before producing or validating artifacts. This reads the repository's schema file and returns it; it does not validate an artifact. Requires no authentication. It reads local inputs only, does not make network calls, does not modify local files, and has no external rate limits.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Schema name to return. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/idempotent/destructive annotations, the description discloses additional behavioral traits: no authentication required, no network calls, no file modification, and no rate limits. It also specifies the data source ('reads the repository's schema file'), which adds context beyond what annotations capture.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the primary purpose in the first sentence, followed by focused behavioral disclosures. Each sentence carries distinct information, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter tool with an output schema, the description is complete: it explains what is returned, the parameter constraint, the read-only behavior, and the intended use case. Error handling is not described, but the enum-restricted input and presence of an output schema make this sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage with a description ('Schema name to return') and a full enum of valid values, so the tool-level description adds no additional parameter semantics. Per the rubric, with high schema coverage the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the primary function with a specific verb ('Return a bundled CheckYourself JSON schema') and a clear purpose ('so an agent can inspect expected fields before producing or validating artifacts'). It also distinguishes itself from validation-focused siblings by explicitly noting 'it does not validate an artifact,' which differentiates it from tools like validate and coverage_check.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance ('before producing or validating artifacts') and a clear when-not-to-use constraint ('does not validate an artifact'). It doesn't name alternative sibling tools explicitly, but the contrast with the validation workflow is clear enough to route an agent correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compute a deterministic Production Reality Score from inline findings and optional coverage evidence. Returns score, raw score, confidence, score mode, severity counts, caps applied, per-category penalties, and manual evidence still needed. MCP mode does not write score history. Requires no authentication. It reads local inputs only, does not make network calls, does not modify local files, and has no external rate limits.
| Name | Required | Description | Default |
|---|---|---|---|
| claim | No | Optional accepted completion claim. This records the claim but does not execute an independent challenge runner. | |
| coverage | No | Optional filled coverage object. Provide this for coverage-backed scoring; omit for scan-derived or finding-only estimates. | |
| findings | Yes | Scan result object, CheckYourself report object, object with findings/remediation_backlog, or a plain list of finding objects to normalize and score. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behavioral traits beyond the annotations, including determinism, no score history writes in MCP mode, no network calls, no file modifications, and no external rate limits. These details align with the readOnly and idempotent hints, providing concrete assurance of side-effect-free operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear purpose statement, a list of return values, and a separate paragraph for behavioral constraints. It is slightly verbose with some redundancy (e.g., 'reads local inputs only' and 'does not make network calls') but remains efficient overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides sufficient context for an agent to understand the tool's inputs, outputs, and side effects. Since an output schema is present, the return value list is supplemental. All relevant information is covered, making it complete for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides descriptions for all three parameters, so the baseline is met. The tool description adds context that coverage is optional and findings are the primary input, but does not significantly enhance the parameter meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: computing a deterministic Production Reality Score from findings and optional coverage. The verb 'compute' and specific resource 'Production Reality Score' make it distinct from sibling tools like scan or coverage_check.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies the input conditions (findings required, coverage optional) but does not explicitly mention any alternative tools or when not to use this tool. It implies usage when a score is needed from provided findings, but lacks direct comparison with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate an inline JSON artifact against one bundled CheckYourself schema subset and return validation errors. Supported kinds include scan, coverage, score, backlog, next, diff, report, dashboard, dashboard-data, learning-plan, and capabilities. Requires no authentication. It reads local inputs only, does not make network calls, does not modify local files, and has no external rate limits.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | Yes | Bundled schema kind to validate against. | |
| artifact | Yes | Inline JSON object to validate. MCP mode does not read a file path for this tool. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint, idempotentHint), the description explicitly states that no authentication is required, it reads local inputs only, makes no network calls, does not modify local files, and has no external rate limits. This provides detailed behavioral transparency that exceeds the annotation hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: it front-loads the core function, lists supported kinds, then covers behavioral constraints. Every sentence contributes meaningful information without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description need not detail return values. It sufficiently covers purpose, acceptable inputs (including the kind enum), and side-effect-free behavior, providing enough context for an agent to decide when and how to invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds useful clarification for the 'artifact' parameter by specifying it is an inline JSON object and that MCP mode does not read a file path, which helps prevent misuse. This pushes it above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool validates an inline JSON artifact against a bundled CheckYourself schema subset and returns validation errors. It names the specific verb, object, and scope, and lists supported kinds, making the purpose unambiguous even without reference to siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains what the tool does but does not explicitly state when to use it versus alternatives. Sibling tools like 'schema' or 'scan' are not referenced or contrasted, so guidance on selection is only implicit from the tool's described purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.2backlog4 fields changedInput schema / additionalPropertiesAdded value: +falseInput schema / properties / findings / descriptionAdded value: +"Scan result object, CheckYourself report object, object with findings/remediation_backlog, or a plain list of finding objects to convert into a remediation backlog."Input schema / properties / findings / typePrevious value: -"object"New value: +[
+ "object",
+ "array"
+]Output schema / (root)Previous value: -nullNew value: +{
+ "description": "Backlog result using schema checkyourself-backlog/1.",
+ "type": "object"
+}coverage_check3 fields changedInput schema / additionalPropertiesAdded value: +falseInput schema / properties / coverage / descriptionAdded value: +"Coverage object produced by coverage_emit and filled with evidence statuses."Output schema / (root)Previous value: -nullNew value: +{
+ "description": "Coverage completeness result using schema checkyourself-coverage-check/1.",
+ "type": "object"
+}coverage_emit3 fields changedInput schema / additionalPropertiesAdded value: +falseInput schema / properties / project / descriptionAdded value: +"Optional project label or path to include in the returned coverage skeleton."Output schema / (root)Previous value: -nullNew value: +{
+ "description": "Coverage skeleton using schema checkyourself-coverage/1.",
+ "type": "object"
+}describe2 fields changedInput schema / additionalPropertiesAdded value: +falseOutput schema / (root)Previous value: -nullNew value: +{
+ "description": "Capability manifest using schema checkyourself-capabilities/1.",
+ "type": "object"
+}diffnext4 fields changedInput schema / additionalPropertiesAdded value: +falseInput schema / properties / findings / descriptionAdded value: +"Scan result object, CheckYourself report object, object with findings/remediation_backlog, or a plain list of finding objects to batch into the next approval group."Input schema / properties / findings / typePrevious value: -"object"New value: +[
+ "object",
+ "array"
+]Output schema / (root)Previous value: -nullNew value: +{
+ "description": "Next-batch result using schema checkyourself-next-batch/1.",
+ "type": "object"
+}receipt_issuescan5 fields changedInput schema / additionalPropertiesAdded value: +falseInput schema / properties / deep / descriptionPrevious value: -"Run slower validation checks for detected surfaces."New value: +"Run slower validation checks for detected surfaces, such as mutable GitHub Action references. Defaults to false."Input schema / properties / max_filesAdded value: +{
+ "description": "Maximum files to scan before truncating (default 6000). The result reports skipped inputs and incompleteness in scan_limits.",
+ "minimum": 1,
+ "type": "integer"
+}Input schema / properties / project / descriptionPrevious value: -"Project root path. Defaults to current directory."New value: +"Project root path to inspect, confined to CHECKYOURSELF_SCAN_ROOT (default: the MCP server process current directory)."Output schema / (root)Previous value: -nullNew value: +{
+ "description": "Scan result using schema checkyourself-scan/1.",
+ "type": "object"
+}schema4 fields changedInput schema / additionalPropertiesAdded value: +falseInput schema / properties / name / descriptionAdded value: +"Schema name to return."Input schema / properties / name / enumAdded value: +[
+ "backlog",
+ "capabilities",
+ "challenge",
+ "challenges",
+ "coverage",
+ "dashboard",
+ "dashboard-data",
+ "diff",
+ "learning-plan",
+ "next",
+ "receipt",
+ "report",
+ "scan",
+ "score"
+]Output schema / (root)Previous value: -nullNew value: +{
+ "description": "The requested bundled JSON schema.",
+ "type": "object"
+}score7 fields changedInput schema / additionalPropertiesAdded value: +falseInput schema / properties / claimAdded value: +{
+ "description": "Optional accepted completion claim. This records the claim but does not execute an independent challenge runner.",
+ "type": "string"
+}Input schema / properties / coverage / descriptionAdded value: +"Optional filled coverage object. Provide this for coverage-backed scoring; omit for scan-derived or finding-only estimates."Input schema / properties / coverage / typePrevious value: -"object"New value: +[
+ "object",
+ "null"
+]Input schema / properties / findings / descriptionAdded value: +"Scan result object, CheckYourself report object, object with findings/remediation_backlog, or a plain list of finding objects to normalize and score."Input schema / properties / findings / typePrevious value: -"object"New value: +[
+ "object",
+ "array"
+]Output schema / (root)Previous value: -nullNew value: +{
+ "description": "Score result using schema checkyourself-score/1.",
+ "type": "object"
+}validate5 fields changedInput schema / additionalPropertiesAdded value: +falseInput schema / properties / artifact / descriptionAdded value: +"Inline JSON object to validate. MCP mode does not read a file path for this tool."Input schema / properties / kind / descriptionAdded value: +"Bundled schema kind to validate against."Input schema / properties / kind / enumAdded value: +[
+ "backlog",
+ "capabilities",
+ "challenge",
+ "challenges",
+ "coverage",
+ "dashboard",
+ "dashboard-data",
+ "diff",
+ "learning-plan",
+ "next",
+ "receipt",
+ "report",
+ "scan",
+ "score"
+]Output schema / (root)Previous value: -nullNew value: +{
+ "description": "Validation result using schema checkyourself-validation/1.",
+ "type": "object"
+}v0.1.0backlogcoverage_checkcoverage_emitdescribenextscanschemascorevalidateScored across 11 tools
Most tools have clearly distinct roles: scanning, coverage emission/checking, scoring, backlog/next selection, diffing, validation, and schema retrieval. Minor potential overlap exists between 'coverage_check' and 'validate' or 'backlog' and 'next', but descriptions clarify their contexts.
Naming conventions are mixed: several tools use snake_case verb_noun forms ('coverage_emit', 'coverage_check', 'receipt_issue') while others are single words ('describe', 'scan', 'score', 'backlog', 'next', 'diff', 'validate', 'schema'). This inconsistency makes the API feel less cohesive.
Eleven tools is slightly on the higher side for the apparent scope, but each serves a distinct purpose in the analysis workflow. A few could potentially be merged (e.g., 'next' is a filtered view of 'backlog'), but the count is still reasonable and not bloated.
The tool set covers the core workflow: scanning, coverage generation/validation, scoring, backlog management, diffing, artifact validation, and schema access. It lacks an explicit reporting or aggregation tool, but the existing functions seem sufficient for the stated read-only analysis domain.
MCP server for AI agents to plan, verify, and deploy Cloudflare-native apps.
Evidence-readiness MCP server: validate, audit, and score briefs, memos, and evidence packs.
MCP server providing access to the Scorecard API to evaluate and optimize LLM systems.
MCP server for secureFlows: token-free URL builders and integration-linting tools for AI agents.
