KSJ MCP Server

Overview Schema Source Related Servers Discussions Admin

audit_knowledge_status

Verify Solid or Mastered claims on a Review page against journal evidence, flag mismatches, and prepare follow-up dialogue; run only after a REV page exists.

Instructions

Independently check a Review page's claimed Knowledge Status against
evidence in the journal, then prepare a dialogue over anything that
doesn't line up — e.g. a topic marked Mastered that still has open
questions attached to it.

This runs AFTER a REV page exists — never before; there's nothing to
audit until a status has actually been claimed. If no REV page is
found, the tool declines. This tool does NOT write to the database —
it prepares the audit and dialogue instructions for Claude to run in
this conversation. Call `commit_assessment()` after the user reviews
the outcome, to persist it. Never changes the REV page's own claimed
status — that stays physical-authority, exactly like
surface_connections never rewrites a SYN page.

A "Needs Work" claim isn't checked against evidence — it doesn't claim
completeness, so there's nothing to hold it to. Only Solid and
Mastered claims get audited.

Trigger phrases: "Audit REV-008", "Check my knowledge status claims
against the evidence".

Args:
    rev_template_id: The REV page's template ID (e.g. "REV-008").
                     Required — the tool declines if no REV page with
                     this ID exists.
    depth:           "brief" | "standard" (default) | "deep" — how many
                     follow-up questions per flagged topic to plan for.
                     The user can also say "more on this one" for any
                     single topic regardless of depth.

Returns the claimed statuses, evidence findings per topic, and audit +
dialogue instructions for Claude to execute.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`depth`	No		standard
`rev_template_id`	Yes

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Addedv3.9.0Oct 2, 2026

TDQS

A4.9/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden and delivers: it discloses that the tool does NOT write to the database, instead preparing instructions for Claude, that it declines without a REV page, and that it never mutates the claimed status. These are exactly the behavioral traits an agent needs and cannot infer from schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with purpose, then sequencing, then args, then returns — a clean structure. It is somewhat long and the surface_connections analogy is illustrative rather than load-bearing, but almost every sentence carries usable information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with an output schema (so return values needn't be re-explained, though they are summarized), the description covers preconditions, decline behavior, audit scope, and persistence handoff. Nothing an agent needs to invoke it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0% (no descriptions, no enums), so the description must compensate fully. It does: rev_template_id is documented with format ('REV-008') and requirement semantics ('declines if no REV page with this ID exists'), and depth is spelled out with its enum values, default ('standard'), and the 'more on this one' override.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource: 'Independently check a Review page's claimed Knowledge Status against evidence in the journal.' It even defines the scope of what gets audited (Solid/Mastered, not Needs Work), so an agent can distinguish it from siblings like commit_assessment or knowledge_progress.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit sequencing ('runs AFTER a REV page exists — never before'), a stated failure mode ('If no REV page is found, the tool declines'), an inclusion/exclusion rule ('Only Solid and Mastered claims get audited'), and the follow-up path ('Call commit_assessment() after the user reviews the outcome'). This is textbook when/when-not/alternatives guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.