Kibi

Overview Schema Source Related Servers Discussions Admin

kb_find_gaps

Read-onlyIdempotent

Find knowledge base entities missing expected relationships, such as requirements without scenarios or tests, by filtering on absent or present links in either direction.

Instructions

List KB entities by the relationships they lack or have. Use for questions like which requirements lack scenarios or tests; all filters must match, and a relationship counts in either direction. Use kb_coverage instead for proof status and repair plans, and kb_check for rule violations. No mutation side effects.

Input Schema

Name	Required	Description
`tags`	No	Keep entities carrying any of these metadata tags. Bootstrap provenance stubs appear in rows only when this names bootstrap:provenance-stub.
`type`	No	Only report entities of this type. Omit for all types.
`limit`	No	Maximum rows to return; count reports the full total.
`offset`	No	Zero-based row offset for pagination.
`sourceFile`	No	Keep entities whose source path contains this substring.
`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.
`missingRelationships`	No	Relationship types the entity must have none of, in either direction, for example specified_by or verified_by. verified_by and validates satisfy each other.
`presentRelationships`	No	Relationship types the entity must have at least one of each, in either direction.

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.

Changed7 schema fields changedv0.1.3Oct 24, 2026

addedInput schema / properties / limit / description

Added value: +"Maximum rows to return; count reports the full total."

addedInput schema / properties / missingRelationships / description

Added value: +"Relationship types the entity must have none of, in either direction, for example specified_by or verified_by. verified_by and validates satisfy each other."

addedInput schema / properties / offset / description

Added value: +"Zero-based row offset for pagination."

addedInput schema / properties / presentRelationships / description

Added value: +"Relationship types the entity must have at least one of each, in either direction."

addedInput schema / properties / sourceFile / description

Added value: +"Keep entities whose source path contains this substring."

addedInput schema / properties / tags / description

Added value: +"Keep entities carrying any of these metadata tags. Bootstrap provenance stubs appear in rows only when this names bootstrap:provenance-stub."

addedInput schema / properties / type / description

Added value: +"Only report entities of this type. Omit for all types."

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 readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the closing "No mutation side effects" adds little. What does add value is the matching semantics: filters are ANDed, and a relationship counts in either direction — behavior that determines result shape and is not inferable from annotations alone.

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?

Two tight sentences, front-loaded with the core purpose and followed by routing. The only wasted clause is the trailing "No mutation side effects," which repeats what the annotations already declare.

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?

Purpose, filter conjunction semantics, directionality, and sibling routing are all covered for an 8-parameter tool, and an output schema plus rich annotations carry the return shape and safety profile. Pagination behavior (limit/offset interaction) and workspaceRoot fallback are left entirely to the schema, which is acceptable but is the remaining gap.

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 all eight parameters are already documented in the schema, including the bidirectional rule for missingRelationships/presentRelationships. The description reinforces the either-direction rule but adds no syntax, defaults, or interaction details beyond that; 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 — list KB entities filtered by missing/present relationships — and immediately names the sibling alternatives (kb_coverage, kb_check) with the condition that selects each. An agent can distinguish this from the graph, coverage, and check tools without opening any 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 a concrete question pattern ("which requirements lack scenarios or tests") that anchors the use case, plus explicit exclusion routing: kb_coverage for proof status and repair plans, kb_check for rule violations. Both when-to-use and when-not-to-use are stated.

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

Deploy Server