Kibi

Overview Schema Source Related Servers Discussions Admin

kb_plan_bootstrap

Read-onlyIdempotent

Generates a deterministic, snapshot-bound bootstrap plan for onboarding repositories with empty or incomplete knowledge bases, returning evidence, scoped questions, ordered actions, and a plan hash.

Instructions

Generate a deterministic, snapshot-bound kibi.bootstrap-plan.v1 for repository onboarding. Use it only to onboard a repository whose KB is empty or incomplete (the kibi-bootstrap skill drives it); for a change in an onboarded project use kb_compile_intent. Read-only analysis of the repository plus any declared knowledge sources and cited intent claims returns evidence, bounded context questions, exact dependency-ordered actions, a canonical plan hash, and no mutation side effects.

Input Schema

Name	Required	Description
`entityTypes`	No	Optional filter to limit candidate generation to specific entity types.
`maxCandidates`	No	Budget for candidates Kibi discovers itself (symbols, tests, repository documents). Declared intentClaims sit outside it: they are never capped and never use its slots. Clamped to [1, 200]. Default: 50.
`minConfidence`	No	Minimum confidence threshold for candidates. Clamped to [0.60, 0.95]. Default: 0.80.
`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.
`bootstrapContext`	No	Optional declared bootstrap context supplied by the agent to ground the read-only synthesis output.
`includeGenericMarkdown`	No	Whether to include generic markdown file content as candidate facts. Default: true, or false when bootstrapContext declares intentClaims (the declared sources already carry the intent); set it explicitly to override.

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.3/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the description needn't restate safety. It adds real value beyond that: the output contents (evidence, bounded context questions, dependency-ordered actions, canonical plan hash), the snapshot-bound determinism, and the explicit 'no mutation side effects' reassurance.

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 sentences, front-loaded with the core purpose before the usage constraint and the return description. Dense but each clause earns its place; the middle sentences are somewhat long but remain readable and non-redundant.

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

Completeness4/5

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

An output schema exists, so returns needn't be fully explained, and the description still summarizes them. Combined with 100% schema coverage and annotations, an agent has enough to call correctly, though it doesn't detail bootstrapContext sub-structure (left to schema).

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 already documents all six parameters thoroughly, including the nested bootstrapContext. The description adds only high-level mentions of 'declared knowledge sources and cited intent claims' and doesn't clarify individual parameter behavior beyond what the schema provides. Baseline 3 applies.

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: 'Generate a deterministic, snapshot-bound kibi.bootstrap-plan.v1 for repository onboarding.' It explicitly names the sibling kb_compile_intent and the condition that selects it, so an agent can distinguish scope without opening either schema.

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?

Gives an explicit when-to-use ('only to onboard a repository whose KB is empty or incomplete') and a when-not/alternative ('for a change in an onboarded project use kb_compile_intent'). It also points to the driving skill (kibi-bootstrap).

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

Deploy Server