Kibi

Overview Schema Source Related Servers Discussions Admin

kb_compile_intent

Read-onlyIdempotent

Compile a change intent into a deterministic, read-only plan before coding; it checks propositions, reports contradictions, proposes traceability links, and emits ordered upsert steps; no mutations.

Instructions

Compile complete change intent into a deterministic, snapshot-bound read-only plan. Use it before editing code for a change request that may touch several requirements; use kb_model for one requirement's prose and kb_plan_bootstrap for first-time onboarding. Reuses intent-aware discovery and semantic modeling, accounts for every proposition, reports contradiction witnesses, proposes traceability links, and emits dependency-ordered kb_upsert-style steps only for resolved typed claims. contradictionAnalysis.outcome is no_conflict only when the check could decide: an unmodeled proposition or a related current requirement without logic leaves it unresolved with reasons and reviewCandidates to compare and judge through conflictReviews. No mutation side effects.

Input Schema

Name	Required	Description
`mode`	Yes	Create a new requirement or update an existing one. Update auto-selection is allowed only with a high-confidence, well-separated candidate.
`title`	No	Optional requirement title; existing title is preserved for updates when omitted.
`intent`	Yes	Complete post-change normative intent. Send the desired behavior, not a patch fragment.
`clauses`	No	Optional complete atomic clause decomposition. Each clause must be a verbatim fragment of intent (whitespace may differ); a clause that does not occur in intent fails the call with VALIDATION_FAILED naming it. Each assertive clause receives independent proposition accounting.
`context`	No	Why the requirement exists, who asked and anything that does not fit its checked meaning. Required when mode is create (validation error naming this field otherwise); rendered as a '## Context' section of the requirement document, never as part of the checked meaning. Never invent a reason: write 'Reason not stated' when the requester gave none. An update keeps the existing document body unless context is supplied.
`testDrafts`	No	Optional test drafts. Tests are attached to scenarios with verified_by; direct req -> test proof links are not emitted.
`requirementId`	No	Optional exact requirement ID. Required for an update when automatic selection is below the confidence and margin gates.
`sourceExcerpt`	No	Optional verbatim text the intent came from (a ticket, a message, a document passage). Rendered as a blockquote in the requirement's '## Source' section; requires context.
`workspaceRoot`	No	Optional absolute path of the workspace this call is about when it differs from the one the server started in, for example the git worktree you are working in. The server answers from that workspace's knowledge base when it is a worktree of the same repository or lies under the client's MCP roots; otherwise it answers from its own workspace and adds a workspace_mismatch diagnostic. Host hooks fill this in automatically where available.
`scenarioDrafts`	No	Optional scenario drafts. Each is linked requirement -> scenario with specified_by.
`semanticFacets`	No	Host-agent facets forwarded to deterministic intent-v1 discovery.
`conflictReviews`	No	Your verdict on each contradictionAnalysis.reviewCandidates entry of a previous compile: whether the intent contradicts that current requirement, which Kibi could not compare logically. A conflict verdict blocks the plan; a no_conflict verdict clears that candidate. A verdict may also name a current requirement discovery did not rank.
`interpretations`	No	Optional host-supplied typed kibi.logic.v1 interpretations; Kibi validates them before including rule steps.
`sourceLocations`	No	Workspace-relative source coordinates used for discovery and before-hash binding.
`sourceReference`	No	Optional locator of the source text (ticket id, URL, path). Rendered in the requirement's '## Source' section; requires context.
`proposalDecisions`	No	Explicit decisions for deterministic traceability proposals. Pending proposals never enter steps.

Output Schema

Name	Required	Description	Default
`data`	Yes
`error`	No
`status`	Yes
`effects`	Yes
`operation`	Yes
`diagnostics`	Yes
`nextActions`	Yes
`kibiProtocol`	Yes
`resultVersion`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 17, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already declare read-only, idempotent, non-destructive behavior, but the description goes further: it discloses that steps are emitted only for resolved typed claims, that proposition accounting and traceability proposals occur, and precisely when contradictionAnalysis.outcome stays unresolved (unmodeled propositions or related requirements lacking logic), naming reviewCandidates and conflictReviews as the resolution path. That is behavioral context an agent could not infer from the annotations.

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?

Purpose and routing are front-loaded in the first sentence. The subsequent sentences are dense, comma-chained clauses about contradiction resolution that repay the space but would read better as shorter, separated statements; nothing is outright wasted.

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 16-parameter, nested-schema, annotation-rich tool with an output schema, the description covers the decision-relevant gaps: when to use it, what it emits, and the unresolved-contradiction workflow. Return-value details are correctly left to the output schema.

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 coverage is 100%, so the baseline is 3, but the description adds cross-call semantics the schema alone does not convey: conflictReviews is defined as verdicts on a previous compile's reviewCandidates entries, a conflict verdict blocks the plan, and pending proposals never enter steps. Remaining parameters are covered adequately by the schema text.

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 and resource with scope: 'Compile complete change intent into a deterministic, snapshot-bound read-only plan.' It also names what it is not by contrasting with kb_model and kb_plan_bootstrap, so an agent can separate it from siblings without reading schemas.

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 to use it 'before editing code for a change request that may touch several requirements,' and routes the agent to kb_model for single-requirement prose and kb_plan_bootstrap for first-time onboarding. Conditions and alternatives are both stated.

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

Deploy Server