Skip to main content
Glama

kb_query

Read-onlyIdempotent

Look up knowledge base entities by id, type, tags or source file, or ask typed fact questions to get matching fact rows and schema details.

Instructions

Read entities from the KB with exact filters, or ask typed fact questions. Use for lookup by id, type, tags or sourceFile, and for precise questions about modeled facts: predicate facts by name with named arguments (predicate + where), property facts of a subject (subjectKey + propertyKey), or the catalog of facts of one kind (factKind; 'predicate_schema' lists the predicates you can ask about with their argument names and constants). Typed answers return matching fact rows plus factQuery: the schema used, distinct counts, values that do exist when nothing matched, warnings about the question and the next call to make. Read-only. Tags filter by metadata tags only, not entity IDs.

Input Schema

NameRequiredDescriptionDefault
idNoOptional exact entity ID. Example: 'REQ-cli-gc'. If omitted, returns matching entities by other filters.
argsNoPositional argument values for predicate when it has no schema; null matches any value. Example: ['admin', null, null, 'allow']. Prefer where.
tagsNoOptional tag filter. Matches entities that contain any provided tag. Example: ['security','billing'].
typeNoOptional entity type filter. Allowed: req, scenario, test, adr, flag, event, symbol, fact. Example: 'req'.
limitNoOptional max rows to return after filtering. Default: 100 when omitted. Example: 25.
scopeNoOptional: 'current_requirements' keeps only facts a current (not superseded or retired) requirement requires.
whereNoNamed argument values for predicate, order-free, using the argument names from the predicate's schema. Example: {actor: 'admin', decision: 'allow'}. An unknown name returns a warning with the declared names; no match returns the values that do exist.
offsetNoOptional zero-based pagination offset. Default: 0. Example: 50 to skip first 50 rows.
distinctNoOptional argument name to count distinct values of across the matching predicate facts, e.g. distinct: 'role' with predicate 'has_role' and where {user: 'alice'} answers how many roles alice has.
factKindNoTyped fact filter: list facts of one kind with their typed fields. 'predicate_schema' returns the catalog of askable predicates (argument names, constants, fact counts). Example: 'predicate_schema'.
polarityNoOptional polarity filter for predicate facts. Default: both.
namespaceNoOptional predicate namespace when the same name exists in several. Default: any namespace.
predicateNoTyped fact filter: predicate name to ask about, e.g. 'has_role' or 'permission_rule'. Combine with where for named arguments. Returns every stored fact of that predicate with its arguments, polarity and allow/deny effect.
sourceFileNoOptional source-file substring filter. Example: 'src/auth/login.ts'. Uses KB source linkage, not file-system scanning.
subjectKeyNoTyped fact filter: dotted subject key whose property facts to list, e.g. 'user.role_assignment'. Combine with propertyKey for one property.
includeBodyNoWith id only: also return the entity's authored Markdown body (the prose after its front matter) as body {id, path, text}, so a stale statement in it can be corrected; kb_upsert document.body replaces it. Default: false.
propertyKeyNoOptional property key under subjectKey, e.g. 'max_roles'. Returns operator, value and unit of each fact.
workspaceRootNoOptional 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

NameRequiredDescriptionDefault
dataYes
errorNo
statusYes
effectsYes
operationYes
diagnosticsYes
nextActionsYes
kibiProtocolYes
resultVersionYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already cover read-only/idempotent/non-destructive, but the description adds substantial context beyond them: the typed-answer payload (factQuery with schema used, distinct counts, existing values when nothing matched, warnings and next call), the tag caveat ('metadata tags only, not entity IDs'), and the factKind semantics. This is rich behavioral disclosure for a read tool.

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 core purpose before the mode breakdown and the tag caveat at the end. It is dense but nearly every clause carries information; the single long paragraph is slightly run-on but not padded.

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?

For an 18-parameter, multi-mode tool with a nested object and an output schema, the description covers modes, combination semantics, output behavior, and the notable tag limitation. Nothing an agent needs to call it correctly appears to be missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds integration-level meaning by showing how parameters combine (predicate + where for named arguments, subjectKey + propertyKey for one property, factKind 'predicate_schema' for the catalog). It clarifies relationships the per-field descriptions do not.

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 ('Read entities from the KB') and enumerates distinct modes: exact-filter lookups and typed fact questions (predicate/where, subjectKey/propertyKey, factKind). An agent can distinguish it from kb_search (exact vs. search) 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 Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives concrete when-to-use conditions ('lookup by id, type, tags or sourceFile', 'precise questions about modeled facts', catalog listing via factKind). It implies the alternative is fuzzy search but never explicitly names kb_search or states exclusions, so it stops short of full routing guidance.

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