checkyourself
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| describeA | 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. |
| scanA | 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. |
| coverage_emitA | 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. |
| coverage_checkA | 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. |
| receipt_issueA | 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. |
| scoreA | 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. |
| backlogA | 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. |
| nextA | 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. |
| diffA | 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. |
| validateA | 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. |
| schemaA | 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. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored 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.