Kibi

Overview Schema Source Related Servers Discussions Admin

kb_prepare_impact_review

Read-onlyIdempotent

Prepare impact-review authoring inputs from a staged snapshot or selected Git commits when changed files require review, returning strict reviewer schemas and an unauthored template.

Instructions

Prepare complete content-bound impact-review authoring inputs from the current staged snapshot or explicitly selected immutable Git commits. Use it when kb_check reports that changed files need an impact review; it does not plan KB changes. Returns strict reviewer schemas and an unauthored template; it does not decide, approve, sign, stage, or prove the review.

Input Schema

Name	Required	Description	Default
`scope`	Yes	What to review: {"kind":"staged"} for the staged snapshot, or {"kind":"diff","baseCommit":"<sha>","headCommit":"<sha>"} with full commit hashes.
`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.

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.

Changed1 schema field changedv0.1.3Oct 24, 2026

addedInput schema / properties / scope / description

Added value: +"What to review: {\"kind\":\"staged\"} for the staged snapshot, or {\"kind\":\"diff\",\"baseCommit\":\"<sha>\",\"headCommit\":\"<sha>\"} with full commit hashes."

First observedv0.1.0Oct 17, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety bar is met; the description adds real value beyond them by listing what it will NOT do (decide, approve, sign, stage, prove) and confirming output is an unauthored template. That negative-space disclosure is exactly what an agent needs before chaining this into a review workflow.

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?

Three tight sentences: what it does, when to use it, and what it does not do. Front-loaded and free of filler, though the negative list in the final sentence is slightly clipped in phrasing.

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?

With an output schema present and full schema coverage on both parameters, the description only needs to cover purpose, trigger, and boundaries — all of which it does. Nothing an agent needs to invoke this correctly is missing.

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 baseline is 3. The description's mention of "current staged snapshot or explicitly selected immutable Git commits" loosely maps to the scope kinds but adds no format or constraint detail beyond the schema's own explanation.

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 ("prepare complete content-bound impact-review authoring inputs") and immediately names the two input sources. It is clearly distinguishable from siblings like kb_plan_bootstrap or kb_check, which it references as an upstream trigger rather than a peer.

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?

Explicitly says when to use it ("when kb_check reports that changed files need an impact review") and carves out a negative case ("it does not plan KB changes"). It stops short of naming the alternative tool an agent should reach for when planning is needed.

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

Deploy Server