Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault

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

CapabilityDetails
tools
{
  "listChanged": false
}

Tools

Functions exposed to the LLM to take actions

NameDescription
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

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A4.1/5.0

Scored across 11 tools

Disambiguation4/5

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 Consistency2/5

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.

Tool Count4/5

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.

Completeness4/5

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.

Maintenance

ActivityMaintained
ResponsivenessWithin a week