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.
TL;DR: CheckYourself — AI production-readiness diagnostic for apps built with AI. Best for founders and engineers shipping AI-generated apps.
Check yourself before you wreck yourself — for the apps you ship. Before you launch it, CheckYourself.
CheckYourself is a free, open-source, model-agnostic production-readiness system 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 auditor that inspects your app, infers the stack, finds production gaps, explains every risk in plain English, proposes fixes for your approval, verifies them, and then writes a learning plan built from the exact gaps your own project had.
Under the hood it is a complete, 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, 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.
Related MCP server: Architect-to-Product (A2P)
CheckYourself is an open-source production-readiness audit system — a structured, staged engineering framework of context files, scoring logic, output schemas, templates, and a deep production-hardening capability stack that you load as an AI coding assistant's operating context, so it can grade an AI-built app the way real production would: honestly, completely, and before launch.
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, scores production readiness from 0–100, 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.
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, deferred with a reason, accepted as risk, blocked by missing context, or proven not applicable.
Get a custom learning plan based on the actual gaps.
No model lock-in. No required cloud account. No 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.
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 ranked by severity, safety, and dependency order.
Safest First Approval Batch — the first reversible batch to approve, not the whole scope.
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. If you do not want HTML, use the compact inline Markdown dashboard instead.
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 CLI is a scaffold, not a substitute — the AI still runs the full diagnostic. See docs/cli.md.
The agent-access roadmap is CLI-first: no hosted API for the current open-source product, with MCP planned later as a thin native-agent wrapper. See 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:
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 inlineand the AI 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 production-readiness system that turns any AI coding assistant into a pre-launch auditor for apps built with AI — a staged diagnostic workspace, an evidence-based score, a complete findings register and remediation backlog, approval-based guided fixes, and a 19-capability hardening engine that finds every gap, explains the risks, fixes them with your approval, and teaches you what you missed.
No build step, no dependencies, no CLI, and no cloud account. You load CheckYourself as your AI assistant's operating context and it works through the stages with you. (It does ship a small optional Python validator for maintainers, but you never need it 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 0–100 production-readiness score with severity caps and explicit reasoning, explained in docs/checkyourself-score-explained.md. A low score with clear findings is more useful than a falsely high one.
Yes — it is released under the MIT License and is free to use, copy, and adapt.
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.
MIT License — free and open source. See LICENSE.
CheckYourself is a AI production-readiness diagnostic for apps built with AI that helps founders and engineers shipping AI-generated apps score production readiness with evidence-backed findings and a fix path.
Product | CheckYourself |
Category | AI production-readiness diagnostic 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 production readiness, pre-launch audit, vibe-code diagnostic |
Primary: founders and engineers shipping AI-generated apps
Use when you need to score production readiness with evidence-backed findings and a fix path
Skip if you need a generic linter or code formatter
CheckYourself is a AI production-readiness diagnostic for apps built with AI. It helps founders and engineers shipping AI-generated apps score production readiness with evidence-backed findings and a fix path.
founders and engineers shipping AI-generated apps.
Unlike style linters, CheckYourself judges ship-readiness with evidence, not only style.
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).
Rank findings into a complete remediation backlog and first approval batch.
| Name | Required | Description | Default |
|---|---|---|---|
| findings | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states that findings are ranked into a backlog and approval batch, but does not describe side effects (e.g., does it create or update records?), required permissions, or what constitutes a 'complete' backlog. This is insufficient for an agent to predict the tool's behavior.
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 a single sentence, which is concise but lacks critical details. It does not follow a structured format and omits important information about input and output.
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 absence of annotations, output schema, and schema descriptions for parameters, the description is severely incomplete. The agent has no way to understand how to invoke this tool correctly or what to expect in return.
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 sole parameter 'findings' is an object with no description in the schema (0% coverage). The tool's description does not add any meaning to this parameter, leaving the agent with no clue about its structure or expected content.
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 ranks findings into a remediation backlog and first approval batch, using a specific verb and resource. However, it does not specify what 'rank' means (e.g., by priority or severity), and it does not differentiate from sibling tools like 'coverage_check' or 'scan'.
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 no guidance on when to use this tool versus alternatives, nor does it mention prerequisites or contexts where the tool should not be used. Given the lack of usage instructions, an agent may misuse the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check a coverage object for completeness and evidence requirements.
| Name | Required | Description | Default |
|---|---|---|---|
| coverage | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only says 'check' but does not clarify whether this is a read-only operation, if it has side effects, or if there are authentication or rate limit requirements.
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 a single sentence, which is concise, but it sacrifices informativeness. It could include more detail without being verbose.
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 no annotations, no output schema, and a nested object parameter, the description is severely incomplete. It does not explain 'completeness' or 'evidence requirements', leaving an AI agent without sufficient context.
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 has one parameter 'coverage' with 0% description coverage. The description adds no meaning beyond 'coverage object', failing to explain its structure or expected properties.
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 uses 'Check' verb and 'coverage object' resource, specifying completeness and evidence requirements. It clearly states the tool's function, though it does not distinguish from sibling tools like 'coverage_emit' 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?
No guidance on when to use this tool versus alternatives. The description implies usage for checking coverage but lacks when-not-to-use instructions or comparisons to siblings.
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 coverage skeleton for an agent to fill with evidence.
| Name | Required | Description | Default |
|---|---|---|---|
| project | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It states the tool 'returns' data, hinting at a read-only operation, but does not disclose side effects, authorization requirements, or rate limits. The brevity leaves uncertainty about whether the skeleton is blank or includes placeholder data.
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 a single sentence, making it concise. However, critical information is omitted, so efficiency comes at the cost of completeness. It is not overly verbose, but lacks necessary detail for effective use.
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 (1 parameter, no output schema, no annotations), the description is incomplete. It does not explain what a '20-surface coverage skeleton' is, how to use the returned data, or how it relates to sibling tools like 'coverage_check'. An agent would lack the context 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?
The sole parameter 'project' is undocumented in both the schema and the description. With 0% schema description coverage, the agent has no clue what values are valid or how 'project' influences the output. The description adds no semantic context for the parameter.
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 verb 'Return' and the resource '20-surface coverage skeleton', indicating a generation/delivery tool. However, it does not differentiate from sibling tools like 'coverage_check' or 'score', and the term '20-surface coverage skeleton' is domain-specific without explanation, potentially confusing an agent.
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?
No guidance on when to use this tool versus alternatives. The phrase 'for an agent to fill with evidence' implies a subsequent action but does not clarify prerequisites, typical use cases, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the CheckYourself command, schema, scoring, and MCP capability manifest.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states what is returned, but does not mention safety (e.g., read-only), side effects, or required permissions. This is insufficient for a tool with zero annotation coverage.
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 a single sentence that directly states the output. It is concise, though the list format could be slightly clearer with structure.
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 lists the returned items but lacks detail on format, size, or whether the manifest includes all MCP capabilities. For a tool with no output schema, more context would be helpful.
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 no parameters, so the description does not need to explain them. Schema coverage is 100%, meeting the baseline for no-parameter tools.
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 uses a specific verb 'Return' and specifies the resource as 'CheckYourself command, schema, scoring, and MCP capability manifest'. It clearly distinguishes from sibling tools like 'schema' and 'score' by being a composite retrieval.
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 the tool is used to get an overview of CheckYourself, but does not explicitly state when to use it versus alternatives like 'schema' or 'score'. No when-not-to-use or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the next safest unresolved approval batch from findings.
| Name | Required | Description | Default |
|---|---|---|---|
| findings | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description only states what is returned without any behavioral traits like side effects, idempotency, or the meaning of 'safest'.
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?
Single sentence, front-loaded, no fluff. Could include more detail without being verbose, but achieves conciseness.
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 one undocumented parameter and no output schema, the description is incomplete. It fails to explain input structure, output format, or the selection logic for 'safest'.
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 sole parameter 'findings' is an object with no description in schema or tool description. The description adds no meaning beyond the parameter name.
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?
Clearly states it returns the next safest unresolved approval batch from findings, with specific verb and resource. However, it does not differentiate from sibling tools like 'backlog' which might list batches.
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?
No guidance on when to use this tool vs alternatives, no prerequisites or when-not-to-use scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run deterministic local discovery and obvious-risk checks against a project path.
| Name | Required | Description | Default |
|---|---|---|---|
| project | No | Project root path. Defaults to current directory. | |
| deep | No | Run slower validation checks for detected surfaces. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description is the sole source. It mentions 'deterministic' and 'local', but fails to disclose side effects, permissions, or output format. Adequate but incomplete.
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?
Single sentence, front-loaded with verb and resource. No redundant words; every element 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?
Simple tool with 2 optional params and no output schema. Description covers high-level purpose but omits details on risk checks and return value. Adequate but with gaps.
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 covers both parameters fully (100%). Description adds marginal value by tying 'project path' to the parameter but no additional insight beyond 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?
Description clearly states it runs discovery and risk checks, distinguishing it from siblings like validate or coverage_check. The verb 'Run' and resource 'project path' are specific, but the exact nature of checks is vague.
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?
No guidance on when to use this tool vs alternatives like validate or coverage_emit. The description only states what it does, leaving the agent to infer appropriateness.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return a bundled JSON schema by name.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description fails to disclose behavioral traits such as read-only nature, authentication needs, or response characteristics. It only says 'returns' without further detail.
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 extremely concise with one sentence, no redundancy, and front-loaded with the core action.
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 tool with one parameter and no output schema, the description still needs to clarify what 'bundled' means and what the output format is. It is incomplete.
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 'name' lacks any description in the schema, and the tool description only adds 'by name', which adds minimal context. No format, constraints, or examples are given.
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 it returns a bundled JSON schema by name, using a specific verb and resource. However, it does not differentiate from siblings like 'describe' or 'scan' which might also operate on schemas.
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?
No guidance on when to use this tool versus alternatives. The description does not mention any preconditions, limitations, or exclude inappropriate uses.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compute the deterministic Production Reality Score from findings and optional coverage.
| Name | Required | Description | Default |
|---|---|---|---|
| findings | Yes | ||
| coverage | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It mentions 'deterministic' but does not explain side effects, permissions required, or what the score represents. The description is too brief to ensure transparency.
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 a single sentence, making it concise. However, it uses the jargon 'Production Reality Score' without definition, which may hinder an agent's understanding. It is appropriately short but could be more accessible.
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 complexity of two object parameters and no output schema, the description is incomplete. It lacks explanation of what the score is, how findings and coverage are structured, and what the return value contains.
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 0%, and the description adds minimal value beyond field names. It indicates findings is required and coverage is optional, but does not explain the structure or expected format of these objects, which are nested.
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 verb 'Compute' and the specific resource 'deterministic Production Reality Score', with inputs 'findings and optional coverage'. However, it does not explicitly differentiate from sibling tools like 'coverage_check' or 'coverage_emit', which could be related.
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 no guidance on when to use this tool versus alternatives. It merely states what it does, without any context on appropriate usage scenarios or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate a JSON artifact against a bundled CheckYourself schema subset.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | Yes | ||
| artifact | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description assumes a read-only validation action but does not specify side effects, authentication needs, or rate limits. The term 'validate' implies no mutation, but this is implicit.
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 a single, efficient sentence of 12 words, front-loading the purpose. It could be slightly expanded with parameter hints without losing conciseness.
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 zero annotations, no output schema, and two unelaborated parameters, the description lacks key context. The agent cannot infer expected output or constraints.
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 0% with 2 required params (kind, artifact) that have only type fields. The description adds no meaning about what 'kind' or 'artifact' represent, leaving the agent uninformed.
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 action (validate) and resource (JSON artifact against a bundled schema subset). It distinguishes from siblings like 'schema' 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?
No guidance on when to use this tool versus alternatives like 'schema' or 'score'. No exclusions or prerequisites mentioned.
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. Dates show when Glama detected each change.
v0.1.0backlogcoverage_checkcoverage_emitdescribenextscanschemascorevalidateEach tool targets a distinct aspect of the workflow: scanning, coverage, scoring, backlog, and validation. There is no overlap or ambiguity in their purposes.
The naming is mostly imperative verbs (scan, score, validate) with some compound names (coverage_check, coverage_emit). The use of 'backlog' as a verb is slightly unconventional but acceptable.
Nine tools is a well-scoped number for a project assessment server, covering discovery, coverage, scoring, and backlog management without being overwhelming.
The tool set provides a complete workflow from scanning to scoring to backlog prioritization, with necessary utilities for schema retrieval and validation. No obvious gaps.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
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.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/KyaniteLabs/checkyourself'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
