DocGuard
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 | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| docguard_guardA | Run every enabled DocGuard validator against the project's canonical docs. Returns status (PASS/WARN/FAIL), every finding once with its stable code and suggestion, each code's evidence once, nextStep, doc coverage, semantic-claim count, and per-validator status and counts. Pass detail "full" for the complete guard JSON contract (per-validator finding copies, the reportable subset, raw benchmark statistics per code). |
| docguard_scoreA | Compute the project's CDD maturity score (0-100) with letter grade and per-category breakdown. |
| docguard_explainA | Explain a stable DocGuard finding code (e.g. STR001, ENV003): what it means, which validator emits it, and the inline suppression to use if it's a confirmed false positive. |
| docguard_verify_evidenceA | Evaluate |
| docguard_verify_claimsA | Extract the semantic claims in the project's canonical docs — documented numbers, limits, and enums — as a verification task list. Deterministic discovery, LLM judgment — the caller verifies each claim against the code. |
| docguard_reportA | Generate the commit-stamped compliance-evidence bundle: guard verdict per validator, findings grouped by stable code, CDD score, ALCOA+ data-integrity attributes, fix history, and a tamper-evident sha256 integrity hash. Evidence, not a gate — it reports state without failing. |
| docguard_docs_for_pathA | Exact answer to "which documentation describes this file?": canonical doc lines that name it (with heading, anchor and section), AGENTS.md/CLAUDE.md/GEMINI.md lines, the @implements/@req IDs it declares, its @doc annotations, and doc sections whose covers= includes it with their review state. Deterministic, bounded, no model. |
| docguard_doc_structureA | A document's headings (level, text, anchor, line range, bytes), docguard:section markers (id, source, pinned, covers), fact markers, marker issues, last-reviewed date and size — so an agent can read one section instead of the whole file. |
| docguard_read_sectionA | Return one section's text, resolved by docguard:section id, then heading anchor, then exact heading text — or, with |
| docguard_task_contextA | The same deterministic packet as |
| docguard_anchorsA | The same listing as |
| docguard_diagnoseA | Run guard and return only what needs fixing: failing/warning validators with their messages, structured findings, and suggested next actions — shaped for an agent to act on. |
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 12 tools
Most tools target clearly distinct operations (score, guard, explain, report, read_section). However, docguard_guard, docguard_diagnose, and docguard_report all revolve around running validators and reporting results, and docguard_anchors overlaps with docguard_docs_for_path on doc-to-code link discovery, creating mild confusion. Descriptions do clarify the boundaries reasonably well.
All tools share a consistent docguard_ prefix, which aids grouping. The suffixes mix bare nouns (score, anchors, guard, report, diagnose) with verb_noun forms (verify_evidence, docs_for_path, read_section), a minor inconsistency that is still readable and predictable.
12 tools is well within the appropriate range for a documentation-governance server and each covers a recognizable facet. There is slight redundancy among guard/diagnose/report, which keeps it just short of ideal scoping.
The surface covers the full analysis lifecycle: scoring, validation, finding explanation, evidence and claim verification, compliance reporting, doc structure, section reading, and task context. Gaps are minor, e.g. no explicit suppression or configuration management tools, but the core domain is well covered.