Skip to main content
Glama

kb_model

Read-onlyIdempotent

Convert requirement prose into structured claims, analyze ambiguity and grounding, and generate strict-lane write sets or predicate plans for KB application.

Instructions

Turn requirement prose into checkable structure without writing the KB. Use it for one requirement's prose; to plan a whole change request use kb_compile_intent. mode:analyze returns the semantic advisor receipt: the clause ledger, what is grounded, what is ambiguous and suggested modeling (pass clauses for compound prose and optional typed kibi.logic.v1 interpretations). mode:requirement converts one claim (subjectKey, propertyKey, operator, value, or typed logic) into a strict-lane write set and applyPlan. mode:predicates ranks ontology predicate schemas and returns an applicable predicate-fact plan only for reviewed bindings, otherwise an ontology-gap observation. With requirementId, mode:predicates also returns a hash-bound plan (fact write plus requires_predicate link) for kb_apply_plan, whose contradictionAnalysis is the what-if over the current KB; other returned plans apply with kb_upsert, and kb_upsert dryRun with plannedFacts previews a requirement before its facts exist.

Input Schema

NameRequiredDescriptionDefault
idNoOptional requirement ID used for deterministic draft relationship guidance.
modeYesanalyze (advisor receipt), requirement (strict claim write set) or predicates (ontology predicate plan).
textYesRequired prose requirement text to model. Example: 'Customer data must be retained for 7 years.'
typeNoEntity type context for analysis. Requirement, domain-fact, and supporting prose all receive a proposition ledger; only requirements receive deterministic modeling suggestions.
logicNoOptional typed kibi.logic.v1 IR. Kibi validates and canonicalizes it into a rule fact; raw Prolog is rejected.
titleNoOptional requirement title for draft apply plans.
valueNoOptional extracted semantic claim value: a string, number or boolean, or a list of strings for a set claim. Example: ['requireAuth'] with operator includes.
sourceNoOptional primary source path or provenance root used for stable IDs and text refs. Example: '.kb/requirements/customer-retention.md'.
statusNoOptional requirement status for draft suggestions.
clausesNoOptional complete list of atomic requirement clauses supplied by the caller. Each clause must be a verbatim fragment of text (whitespace may differ); a clause that does not occur in text fails the call with VALIDATION_FAILED naming it. Use this for compound prose so every normative clause receives a stable claim key and independent grounding review.
claimKeyNoOptional advisor-issued claim key for the exact proposition represented by logic.
minScoreNoMinimum candidate score. Higher values make ontology-gap fallback more likely. Default: 0.35.
operatorNoOptional extracted semantic claim operator. Use gt/lt for strict bounds ('greater than zero' is gt 0, not gte 0). A set claim takes a list value with eq (exactly these), includes (at least these), subset_of (only these) or excludes (none of these); matches takes a regular expression string. Example: 'eq'.
schemaIdNoOptional exact reviewed predicate schema ID. When supplied, Kibi selects that schema instead of lexical rank order and fails closed if it is unavailable.
claimTextNoOptional exact proposition text represented by logic; defaults to text.
confidenceNoConfidence score for the extracted claim. >= 0.70 yields strict-lane output; lower confidence yields observation-only review output.
provenanceNoOptional extracted text reference. Falls back to source when omitted. Example: '.kb/requirements/customer-retention.md#L1'.
subjectKeyNoOptional extracted semantic claim subjectKey. Example: 'Customer.Data'.
propertyKeyNoOptional extracted semantic claim propertyKey. Example: 'Retention Years'.
sourceFilesNoOptional related source files. The first value is used as the source fallback when source is omitted.
subjectHintNoOptional canonical subject key to use as the first predicate argument. Example: 'editor.annotation'.
polarityHintNoOptional reviewed polarity override for claims whose surface negation does not express predicate denial. Use only after reviewing the selected schema and full claim scope.
maxCandidatesNoMaximum ranked predicate candidates to return. Default: 5.
requirementIdNoOptional requirement ID. The strict write set updates this requirement instead of minting a REQ-AUTO id, and a typed logic rule attaches its requires_rule relationship to it.
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.
interpretationsNoOptional host-LLM typed kibi.logic.v1 interpretations. Kibi validates and canonicalizes them; raw Prolog is not accepted.
argumentBindingsNoOptional exact predicate argument values keyed by a candidate schema's argument_names. Required before applying a candidate whose binding_status is incomplete; Kibi never substitutes guessed values for unbound arguments.
existingLogicClaimsNoExisting requirement logic_claims values. The returned requirement update merges the new atomic claim key into this manifest instead of replacing prior claims.
includeExistingSchemasNoWhether to include existing KB fact_kind=predicate_schema facts alongside Kibi's built-in predicate catalog. Default: true.

Output Schema

NameRequiredDescriptionDefault
dataYes
errorNo
statusYes
effectsYes
operationYes
diagnosticsYes
nextActionsYes
kibiProtocolYes
resultVersionYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv0.1.5
    • changedInput schema / properties / operator / anyOf
      Previous value: -[
      -  {
      -    "const": "eq",
      -    "type": "string"
      -  },
      -  {
      -    "const": "gt",
      -    "type": "string"
      -  },
      -  {
      -    "const": "gte",
      -    "type": "string"
      -  },
      -  {
      -    "const": "lt",
      -    "type": "string"
      -  },
      -  {
      -    "const": "lte",
      -    "type": "string"
      -  },
      -  {
      -    "const": "neq",
      -    "type": "string"
      -  },
      -  {
      -    "const": "bool",
      -    "type": "string"
      -  },
      -  {
      -    "const": "polarity",
      -    "type": "string"
      -  }
      -]New value: +[
      +  {
      +    "const": "eq",
      +    "type": "string"
      +  },
      +  {
      +    "const": "gt",
      +    "type": "string"
      +  },
      +  {
      +    "const": "gte",
      +    "type": "string"
      +  },
      +  {
      +    "const": "lt",
      +    "type": "string"
      +  },
      +  {
      +    "const": "lte",
      +    "type": "string"
      +  },
      +  {
      +    "const": "neq",
      +    "type": "string"
      +  },
      +  {
      +    "const": "bool",
      +    "type": "string"
      +  },
      +  {
      +    "const": "polarity",
      +    "type": "string"
      +  },
      +  {
      +    "const": "matches",
      +    "type": "string"
      +  },
      +  {
      +    "const": "includes",
      +    "type": "string"
      +  },
      +  {
      +    "const": "subset_of",
      +    "type": "string"
      +  },
      +  {
      +    "const": "excludes",
      +    "type": "string"
      +  }
      +]
    • changedInput schema / properties / operator / description
      Previous value: -"Optional extracted semantic claim operator. Use gt/lt for strict bounds ('greater than zero' is gt 0, not gte 0). Example: 'eq'."New value: +"Optional extracted semantic claim operator. Use gt/lt for strict bounds ('greater than zero' is gt 0, not gte 0). A set claim takes a list value with eq (exactly these), includes (at least these), subset_of (only these) or excludes (none of these); matches takes a regular expression string. Example: 'eq'."
    • addedInput schema / properties / value / anyOf
      Added value: +[
      +  {
      +    "type": "string"
      +  },
      +  {
      +    "type": "number"
      +  },
      +  {
      +    "type": "boolean"
      +  },
      +  {
      +    "items": {
      +      "type": "string"
      +    },
      +    "minItems": 1,
      +    "type": "array"
      +  }
      +]
    • changedInput schema / properties / value / description
      Previous value: -"Optional extracted semantic claim value. Accepts string, number, or boolean."New value: +"Optional extracted semantic claim value: a string, number or boolean, or a list of strings for a set claim. Example: ['requireAuth'] with operator includes."
  2. First observedv0.1.0

TDQS

A4.6/5.0
Behavior5/5

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

Beyond the readOnly/idempotent/non-destructive annotations, the description explains what each mode returns: an advisor receipt with clause ledger, a strict-lane write set and applyPlan, or an ontology predicate plan only for reviewed bindings. It also clarifies that requirementId produces a hash-bound plan for kb_apply_plan while other plans apply with kb_upsert, and that dryRun plannedFacts previews a requirement before facts exist.

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?

The description is front-loaded with purpose and the sibling alternative, then walks through each mode. It is dense and long, but for a 29-parameter, multi-mode tool most sentences carry substantive routing or behavioral information rather than filler.

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?

Given the tool's complexity, the description covers the mode behaviors, write-plan semantics, external application paths, and the requirementId special case. An output schema exists, so it does not need to enumerate every return field, and the safety profile is already covered by annotations.

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 already 100%, so the schema documents all 29 parameters. The description still adds meaningful cross-parameter behavior: clauses are for compound prose, interpretations are optional typed logic, confidence thresholds determine strict-lane vs observation-only output, and requirementId changes plan generation and routing to kb_apply_plan.

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?

The opening states a specific verb and resource: turn requirement prose into checkable structure without writing the KB. It also distinguishes the tool from kb_compile_intent for whole change requests, so an agent can route between them 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?

It gives explicit usage for one requirement's prose and names kb_compile_intent as the alternative for planning a whole change request. The three modes are each tied to a distinct output context, though the choice between analyze and requirement is left somewhat implicit.

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