Kibi

Overview Schema Source Related Servers Discussions Admin

kb_graph

Read-onlyIdempotent

Traverse requirements, scenarios, tests, and code symbols from seed IDs to see how entities connect. Follows curated link types up to depth, node, or edge limits and flags truncated results.

Instructions

Run bounded graph traversal from one or more seed IDs across curated relationship types and return the nodes and edges reached. Use it to follow links from IDs you already have, such as a requirement to its scenarios and tests or a symbol to the requirements it implements; use kb_query to find entities by filter and kb_search to ask a question. Traversal stops at depth, maxNodes or maxEdges and then sets truncated. No mutation side effects.

Input Schema

Name	Required	Description
`depth`	No	Number of hops from the seeds.
`seedIds`	Yes	Entity IDs to start from, for example REQ-... or SCEN-.... Seeds are always returned as nodes.
`maxEdges`	No	Stop and set truncated once this many edges are reached.
`maxNodes`	No	Stop and set truncated once this many nodes are reached.
`direction`	No	outgoing follows links from each node, incoming follows links pointing at it, both does either.
`entityTypes`	No	Keep only nodes of these types (req, scenario, test, adr, flag, event, symbol, fact) in the result, and the edges between them. Traversal still passes through other types.
`relationships`	No	Relationship types to follow, for example specified_by, verified_by or implements. Omit to follow every relationship type.
`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.

Changed7 schema fields changedv0.1.3Oct 24, 2026

addedInput schema / properties / depth / description
```
Added value: +"Number of hops from the seeds."
```

addedInput schema / properties / direction / description

Added value: +"outgoing follows links from each node, incoming follows links pointing at it, both does either."

addedInput schema / properties / entityTypes / description

Added value: +"Keep only nodes of these types (req, scenario, test, adr, flag, event, symbol, fact) in the result, and the edges between them. Traversal still passes through other types."

addedInput schema / properties / maxEdges / description

Added value: +"Stop and set truncated once this many edges are reached."

addedInput schema / properties / maxNodes / description

Added value: +"Stop and set truncated once this many nodes are reached."

addedInput schema / properties / relationships / description

Added value: +"Relationship types to follow, for example specified_by, verified_by or implements. Omit to follow every relationship type."

addedInput schema / properties / seedIds / description

Added value: +"Entity IDs to start from, for example REQ-... or SCEN-.... Seeds are always returned as nodes."

First observedv0.1.0Oct 17, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Adds real behavior beyond the annotations: traversal terminates at depth/maxNodes/maxEdges and flags the result with 'truncated', which tells the agent how to interpret partial results. The final sentence restates the read-only profile already covered by readOnlyHint/destructiveHint, and it says nothing about invalid seed IDs or ordering, so it stops just short of the top mark.

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-loaded with the core action, and the sibling routing is compressed into one efficient clause. The closing 'No mutation side effects' sentence duplicates what the annotations already declare, so not every sentence earns its place.

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?

An output schema exists, so return shape need not be explained, and the description still covers the one semantic gap a schema cannot: what 'truncated' means in practice. For an 8-parameter read-only traversal with full schema coverage, nothing an agent needs to call it 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 coverage is 100%, so depth, seedIds, maxNodes, maxEdges, direction, entityTypes, relationships and workspaceRoot are all self-documented. The description only echoes the truncation semantics already in the maxNodes/maxEdges descriptions and adds no new meaning for the seed or relationship parameters, so the 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 ('Run bounded graph traversal from one or more seed IDs') plus the scope of what it follows and returns ('nodes and edges reached'). It also names the two siblings it is not, so an agent can separate it from kb_query and kb_search 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 the exact condition for use ('follow links from IDs you already have') with concrete examples (requirement → scenarios/tests, symbol → requirements). It explicitly routes the alternative cases: 'use kb_query to find entities by filter and kb_search to ask a question'.

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

Deploy Server