Open Kioku

Overview Schema Source Related Servers Discussions Admin

Open Kioku Verify Change

verify_change

Compare actual code changes against a saved PlanReport to verify boundary limits, API surface, and dependency policies, then 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

Name	Required	Description
`diff`	No	The unified diff (git diff format) showing the actual changes to verify.
`plan`	No	A JSON object containing the saved PlanReport to verify against.
`plan_json`	No	A JSON-encoded string representation of the PlanReport to verify against.
`since_plan`	No	Git revision or range (e.g., 'HEAD~1', 'abc123..def456') used with git diff --unified=0 to derive changed files and diff input automatically.
`run_commands`	No	Set 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_files`	No	List of repository-relative paths of changed files. Used when diff is not provided.
`evidence_refs`	No	List of evidence reference identifiers supporting the change.
`check_api_surface`	No	Set true to detect public API surface changes (additions, removals, signature modifications) and flag them as warnings. Defaults to false.
`write_attestation`	No	Set 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_strict`	No	Set 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_delta`	No	Set true to detect dependency graph changes and flag forbidden dependency additions based on architecture policy. Defaults to false.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`value`	No	Wrapped non-object output, used for Markdown, TOON, or scalar responses.

Schema Changelog

Changes observed during successful MCP inspections.

Changed12 schema fields changedv2.2.3Jul 4, 2026

changedInput schema / properties / changed_files / description

Previous value: -"List of repository-relative paths of changed files."New value: +"List of repository-relative paths of changed files. Used when diff is not provided."

addedInput schema / properties / check_api_surface

Added value: +{
+  "description": "Set true to detect public API surface changes (additions, removals, signature modifications) and flag them as warnings. Defaults to false.",
+  "type": "boolean"
+}

addedInput schema / properties / check_dependency_delta

Added value: +{
+  "description": "Set true to detect dependency graph changes and flag forbidden dependency additions based on architecture policy. Defaults to false.",
+  "type": "boolean"
+}

changedInput schema / properties / diff / description

Previous value: -"The unified diff showing the actual changes."New value: +"The unified diff (git diff format) showing the actual changes to verify."

changedInput schema / properties / evidence_refs / description

Previous value: -"List of evidence reference identifiers."New value: +"List of evidence reference identifiers supporting the change."

changedInput schema / properties / plan / description

Previous value: -"A JSON object containing the saved PlanReport."New value: +"A JSON object containing the saved PlanReport to verify against."

changedInput schema / properties / plan_json / description

Previous value: -"A JSON-encoded string representation of the PlanReport."New value: +"A JSON-encoded string representation of the PlanReport to verify against."

changedInput schema / properties / run_commands / description

Previous value: -"Set true to execute the validation commands defined in the plan."New value: +"Set 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."

changedInput schema / properties / since_plan / description

Previous value: -"Optional git revision/range used with git diff --unified=0 to derive changed files and diff input."New value: +"Git revision or range (e.g., 'HEAD~1', 'abc123..def456') used with git diff --unified=0 to derive changed files and diff input automatically."

addedInput schema / properties / traceability_strict

Added value: +{
+  "description": "Set true to reject any evidence references not present in the saved plan, enforcing full traceability. Defaults to false (lenient mode allows extra evidence).",
+  "type": "boolean"
+}

addedInput schema / properties / write_attestation

Added value: +{
+  "description": "Set 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.",
+  "type": "boolean"
+}

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "description": "The MCP structuredContent object returned by this Open Kioku tool. Most tools expose their JSON fields directly; string or scalar tool outputs are wrapped as {\"value\": ...}.",
+  "properties": {
+    "value": {
+      "description": "Wrapped non-object output, used for Markdown, TOON, or scalar responses."
+    }
+  },
+  "type": "object"
+}

Changed1 schema field changedv2.1.0Jun 21, 2026

addedInput schema / properties / since_plan

Added value: +{
+  "description": "Optional git revision/range used with git diff --unified=0 to derive changed files and diff input.",
+  "type": "string"
+}

Changed6 schema fields changedv2.0.3Jun 10, 2026

addedInput schema / properties / changed_files / description

Added value: +"List of repository-relative paths of changed files."

changedInput schema / properties / diff / description

Previous value: -"Unified diff to verify"New value: +"The unified diff showing the actual changes."

addedInput schema / properties / evidence_refs / description
```
Added value: +"List of evidence reference identifiers."
```

changedInput schema / properties / plan / description

Previous value: -"Saved PlanReport JSON object"New value: +"A JSON object containing the saved PlanReport."

changedInput schema / properties / plan_json / description

Previous value: -"Saved PlanReport JSON string"New value: +"A JSON-encoded string representation of the PlanReport."

changedInput schema / properties / run_commands / description

Previous value: -"Run validation commands from the saved plan"New value: +"Set true to execute the validation commands defined in the plan."

First observedv2.0.1Jun 10, 2026

TDQS

A4.9/5.0

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.