Skip to main content
Glama

Open Kioku Verify Change Contract

verify_change_contract

Verify changed files or a diff against a stored or inline change contract to ensure edits meet specified constraints, with optional API and dependency checks.

Instructions

Verify changed files or a diff against a stored or inline change contract. Stored contract ids append verification records to .ok/contracts. Use after edits to verify a diff against a stored or inline change contract. Stored contract ids append verification records under .ok/contracts, and command execution is opt-in via run_commands.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
diffNoThe unified diff showing the actual changes.
formatNoReturn format. Defaults to json.
contractNoInline ChangeContractV1 or StoredContractRecord object.
since_planNoOptional git revision/range used with git diff --unified=0 to derive changed files and diff input.
contract_idNoStored contract id.
run_commandsNoSet true to execute validation commands defined in the contract.
changed_filesNoList of repository-relative paths of changed files.
contract_jsonNoJSON-encoded ChangeContractV1 or StoredContractRecord.
evidence_refsNoList of evidence reference identifiers.
check_api_surfaceNoSet true to detect public API additions, removals, and signature changes during verification.
write_attestationNoSet true with run_commands and a stored contract id to persist validation attestations.
traceability_strictNoSet true to reject supplied evidence references that are not present in the contract.
check_dependency_deltaNoSet true to detect dependency graph deltas and flag forbidden dependency additions.
validation_attestationsNoPreviously recorded validation attestations to replay during verification.

Output Schema

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

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

Annotations indicate readOnlyHint=false and destructiveHint=false, but the description adds behavioral context: stored contract ids append verification records to .ok/contracts, and command execution is opt-in. This goes beyond the annotations without contradicting them.

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?

The description is two sentences long, front-loaded with the core purpose. It is concise without being under-specified, though a slightly more structured format (e.g., bullet points) could improve scanability.

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

Completeness3/5

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

Given 14 parameters, high complexity, and an output schema, the description covers the core functionality and key behaviors. However, it does not explain many optional boolean flags (e.g., check_api_surface, check_dependency_delta) or the interaction between parameters, which could leave the agent guessing.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema itself documents all 14 parameters. The description adds minimal extra context (e.g., storing records, opt-in commands), but does not elaborate on the boolean flags or nested objects. Baseline 3 is appropriate.

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?

The description clearly states the tool's purpose: 'Verify changed files or a diff against a stored or inline change contract.' It uses a specific verb ('verify') and resource ('change contract'), and distinguishes from sibling tools like 'verify_change' by specifying the contract mechanism.

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

Usage Guidelines4/5

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

The description provides explicit use context: 'Use after edits to verify a diff against a stored or inline change contract.' It also mentions opt-in command execution. However, it does not explicitly state when not to use or compare to alternatives like '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