Skip to main content
Glama

Open Kioku Verify Change

verify_change

Verify code changes against a saved PlanReport to ensure boundary constraints, API surface stability, and dependency policy compliance. Optionally run validation commands and persist attestation records.

Instructions

Verify an actual unified diff or set of changed files against a saved PlanReport, checking boundary constraints, expected file coverage, API surface stability, and dependency policy. Optionally executes configured validation commands and persists timestamped attestation records. Use after code edits to compare an actual unified diff or changed file list against a PlanReport produced by plan_change. When run_commands=true, executes shell commands listed in the plan's validation section (test runners, linters) on the local machine. When write_attestation=true, persists timestamped pass/fail records under .ok/contracts/validation/. Do NOT use for pre-edit planning (use plan_change), contract-based verification (use verify_change_contract), or boundary-only checks (use validate_patch). Side effects are conditional on boolean flags; with all flags false the tool is read-only.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
diffNoThe unified diff (git diff format) showing the actual changes to verify.
planNoA JSON object containing the saved PlanReport to verify against.
plan_jsonNoA JSON-encoded string representation of the PlanReport to verify against.
since_planNoGit revision or range (e.g., 'HEAD~1', 'abc123..def456') used with git diff --unified=0 to derive changed files and diff input automatically.
run_commandsNoSet true to execute shell validation commands (test runners, linters) defined in the plan on the local machine. Commands run synchronously and their exit codes are recorded. Defaults to false.
changed_filesNoList of repository-relative paths of changed files. Used when diff is not provided.
evidence_refsNoList of evidence reference identifiers supporting the change.
check_api_surfaceNoSet true to detect public API surface changes (additions, removals, signature modifications) and flag them as warnings. Defaults to false.
write_attestationNoSet true together with run_commands to persist timestamped pass/fail attestation records under .ok/contracts/validation/. Has no effect when run_commands is false. Defaults to false.
traceability_strictNoSet true to reject any evidence references not present in the saved plan, enforcing full traceability. Defaults to false (lenient mode allows extra evidence).
check_dependency_deltaNoSet true to detect dependency graph changes and flag forbidden dependency additions based on architecture policy. Defaults to false.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
valueNoWrapped non-object output, used for Markdown, TOON, or scalar responses.
Behavior5/5

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

Discloses conditional side effects: 'Side effects are conditional on boolean flags; with all flags false the tool is read-only.' Explains that run_commands executes shell commands locally and write_attestation persists records. Annotations provide base but description adds critical context.

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

Conciseness5/5

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

Two paragraphs: first states core purpose and checks, second explains optional behaviors and exclusions. No wasted words, front-loaded with key action. Every sentence adds value.

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?

Given 11 parameters, nested objects, and boolean flags, the description comprehensively covers purpose, usage context, side effects, and exclusions. Output schema exists so return details are not needed.

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

Parameters4/5

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

Schema description coverage is 100% so parameters are well-documented. Description adds behavioral context beyond schema, e.g., explaining conditional effects of run_commands and write_attestation, and local execution. Does not repeat schema verbatim.

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?

Clearly states it verifies a unified diff/changed files against a PlanReport, checking boundary/file coverage/API/dependency constraints. Explicitly distinguishes from sibling tools plan_change, verify_change_contract, validate_patch by specifying what not to use it for.

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?

Explicitly says 'Use after code edits' and provides three specific alternatives for when not to use, naming the appropriate sibling tool for each case (plan_change, verify_change_contract, validate_patch).

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/shivyadavus/open-kioku'

If you have feedback or need assistance with the MCP directory API, please join our Discord server