Kibi

Overview Schema Source Related Servers Discussions Admin

kb_coverage

Read-onlyIdempotent

Report end-to-end requirement proof status and symbol ownership coverage, showing evidence levels and repair plans for what still blocks full verification.

Instructions

Generate curated structural coverage and conservative end-to-end requirement proof reports for requirements, symbols, or grouped types. Use it to ask which requirements are tested end to end, how strong each requirement's evidence is (evidenceLevel: proved, tested, asserted or unverified), and what blocks the rest; use kb_find_gaps for a plain list of missing links and kb_check for rule violations. Reports include the compatible repair plan plus typed kibi.migration-plan.v2 actions; semantic and E2E actions remain review/execution work. Paginated plans identify incomplete scope and no mutation occurs.

Input Schema

Name	Required	Description
`by`	No	Report shape: req gives per-requirement proof status and a repair plan, symbol gives per-symbol ownership coverage, type gives counts per entity type.
`tags`	No	Keep rows for entities carrying any of these metadata tags.
`limit`	No	Maximum rows to return. When the repair plan reports scope.complete false, rerun with offset 0 and a larger limit.
`offset`	No	Zero-based row offset for pagination.
`statuses`	No	Requirement proof-status filter (req mode): include only rows whose proofStatus is listed. Selecting statuses implies include-passing; not_applicable rows carry their typed applicability reason in proofStages.applicability.reason. The summary always reflects the whole KB.
`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.
`includePassing`	No	Also return rows that are already tested or not applicable. By default only rows that still need repair are returned.
`migrationLimit`	No	Maximum requirement migration batches to preview. Defaults to one review batch.
`migrationOffset`	No	Zero-based offset into ready semantic-inventory batches.
`includeTransitive`	No	Count symbol coverage reached transitively through linked entities, not only direct links.
`includeMigrationPreview`	No	Opt in to a deterministic, read-only kibi.legacy-migration-plan.v1 preview for ready semantic-inventory repair batches.
`migrationPredicateLimit`	No	Maximum exact predicate-schema candidates retained per assertive proposition.
`migrationPredicateMinScore`	No	Minimum deterministic predicate-schema rank score retained in migration previews.

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 / by / description

Added value: +"Report shape: req gives per-requirement proof status and a repair plan, symbol gives per-symbol ownership coverage, type gives counts per entity type."

addedInput schema / properties / includePassing / description

Added value: +"Also return rows that are already tested or not applicable. By default only rows that still need repair are returned."

addedInput schema / properties / includeTransitive / description

Added value: +"Count symbol coverage reached transitively through linked entities, not only direct links."

addedInput schema / properties / limit / description

Added value: +"Maximum rows to return. When the repair plan reports scope.complete false, rerun with offset 0 and a larger limit."

addedInput schema / properties / offset / description

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

changedInput schema / properties / statuses / items / anyOf

Previous value: -[
-  {
-    "const": "proven",
-    "type": "string"
-  },
-  {
-    "const": "missing",
-    "type": "string"
-  },
-  {
-    "const": "unresolved",
-    "type": "string"
-  },
-  {
-    "const": "not_applicable",
-    "type": "string"
-  }
-]New value: +[
+  {
+    "const": "tested",
+    "type": "string"
+  },
+  {
+    "const": "missing",
+    "type": "string"
+  },
+  {
+    "const": "unresolved",
+    "type": "string"
+  },
+  {
+    "const": "not_applicable",
+    "type": "string"
+  }
+]

addedInput schema / properties / tags / description

Added value: +"Keep rows for entities carrying any of these metadata tags."

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 the description reinforces this with 'no mutation occurs' plus useful extra context on pagination incomplete scope and that semantic/E2E actions remain review/execution work. It adds value beyond the annotations, though it doesn't detail rate limits or exact return shape (output schema covers that).

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?

Front-loads the action and scope, then alternatives, then behavioral caveats. Dense but each sentence carries information; minor cost is the long compound third sentence.

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?

Given 13 optional params and an output schema (so return values needn't be explained), the description covers purpose, alternatives, and behavioral caveats adequately. It could more explicitly tie the migration/preview params to usage, but nothing critical for correct invocation 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 all 13 parameters are already documented in the schema; baseline 3 applies. The description adds meaning around the evidenceLevel return values but does not enrich parameter semantics beyond what the schema provides.

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 (Generate) and resource (structural coverage and end-to-end requirement proof reports) and names the three report modes (requirements, symbols, grouped types). An agent can distinguish it from kb_find_gaps and kb_check without opening the 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?

Explicitly frames the use case ('ask which requirements are tested end to end, how strong each requirement's evidence is') and routes alternatives by name: kb_find_gaps for missing-link lists and kb_check for rule violations. Clear when-to-use vs when-not.

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

Deploy Server