Skip to main content
Glama
knaisoma

data-olympus MCP server

KB Search

kb_search
Read-onlyIdempotent

Search a governance knowledge base using natural-language queries, optional filters, and an in-force mode to return only currently applicable documents with ranked snippets.

Instructions

Full-text search across the KB.

Optional tier/category/status/type filters (status e.g. 'active', doc_type e.g. 'decision'). Returns ranked hits with snippets.

in_force: when true, HARD-filter to the in-force status class (active/accepted/approved) AND the validity window (not expired, not upcoming) before ranking, EXCLUDING superseded/deprecated/expired/ upcoming docs rather than only soft-downranking them. Composes with an explicit status (both must hold). Use this when you want only guidance that currently applies.

A doc past its valid_until date is EXCLUDED from every default search result (not just in_force=True): an expired doc has no named successor to outrank it, so left visible it could be the top hit and would govern. Set include_expired=true to see it anyway; it then carries freshness: "expired". A doc with a future valid_from ("upcoming") stays visible in default search, flagged freshness: "upcoming"; only in_force=true excludes it. validity_state is an audit-query facet: one of "expired", "stale", or "expiring_within:N" (N days) to list docs by validity condition; filtering for "expired" implies including them regardless of include_expired. "stale" here matches only recheck_by in the past -- narrower than the per-hit freshness: "stale" a hit can otherwise carry from verification age (see KB_REVIEW_DUE_AFTER_DAYS); use kb_curate to list every document currently showing freshness: "stale" for either reason.

abstain: when true, apply the signal gate. If the query matches no discriminating column (title/tags/applies_when) it is treated as out-of-scope and the search returns NO hits with abstained: true and an abstain_reason, instead of surfacing a weak keyword match. A query with a real signal retrieves normally. Distinguish abstained: true (no governing rule) from an ordinary empty result (abstained: false).

verbose: False (default) returns a token-compact shape. Each hit is {id, title, snippet} plus status only when a hit is NOT in-force (superseded/deprecated), type when set, and freshness only when a hit deviates (stale/expired/upcoming); the query echo, per-hit path, and score are dropped (fetch a hit's full metadata with kb_get(id); array order conveys rank). A compact hit additionally carries in_force: false when the computed in-force predicate (the single-sourced status + validity-window + not-inbox rule; never stored in frontmatter) says the doc does NOT currently govern -- emitted deviation-only, so an in-force hit's compact shape is unchanged. verbose=True restores the full legacy shape with query, path, score, status, type, freshness, and the computed in_force: bool on every hit, so a hit retrieved WITHOUT in_force=true can still be checked for whether it may govern now.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
tierNoOptional tier filter such as T1, T2, T3, or T4.
limitNoMaximum number of results, clamped to 1..100.
queryYesNatural-language search query.
statusNoOptional frontmatter status filter.
abstainNoTrue returns an explicit abstention when the query has no KB signal.
verboseNoFalse returns the compact response; true includes all fields.
categoryNoOptional category filter within a tier.
doc_typeNoOptional document type filter.
in_forceNoTrue returns only currently governing documents.
validity_stateNoOptional validity facet: expired, stale, or expiring_within:N.
include_expiredNoTrue allows expired documents in search results.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.5.0

TDQS

A4.9/5.0
Behavior5/5

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

Annotations mark this as read-only, idempotent, and non-destructive, and the description adds substantial runtime behavior: expired docs are excluded by default, in_force acts as a hard pre-ranking filter, validity_state 'stale' is narrower than per-hit freshness 'stale', abstention is distinguished from an empty result, and verbose mode changes field emission. No annotation contradiction exists.

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 the core purpose and is dense rather than padded. The verbose-shape paragraph is long and partly overlaps with what an output schema could carry, but each sentence still conveys a meaningful behavioral distinction, so only slight over-explanation keeps it from a perfect score.

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 11-parameter search tool with no enums, the description covers filters, default exclusions, parameter interactions, edge cases, response-shape consequences, and sibling-tool routing. The output schema exists for exact return details, so nothing critical is missing.

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

Parameters5/5

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

Schema coverage is already 100%, but the description goes far beyond the schema: it explains the exact semantics of in_force, how include_expired interacts with validity_state, what abstain's signal gate does, and exactly how verbose changes the returned shape. This materially improves parameter selection.

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 description opens with a specific verb and resource: 'Full-text search across the KB.' It immediately states the outcome ('ranked hits with snippets'), enumerates filter dimensions, and clearly positions this as a search/retrieval tool distinct from siblings like kb_get and kb_curate.

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?

The description gives explicit selection criteria: use in_force when only currently applying guidance is wanted, use include_expired to surface expired docs, use validity_state for audit-style validity queries, and use abstain for out-of-scope signal gating. It also routes the agent to kb_get for full metadata and to kb_curate for listing stale documents.

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