Skip to main content
Glama
knaisoma

data-olympus MCP server

KB Search

kb_search
Read-onlyIdempotent

Search a governance knowledge base with full-text queries and filters for tier, category, status, type, and validity state. Retrieve ranked results with snippets, optionally limiting to currently governing documents.

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.

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

Behavior5/5

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

The description goes far beyond annotations (readOnlyHint, idempotentHint) to explain complex behaviors: hard-filtering vs downranking for in_force, default exclusion of expired docs, abstention logic, and compact vs verbose response shapes. No contradictions with annotations.

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 well-structured, starting with a clear purpose and then explaining each parameter. Though lengthy, each sentence adds necessary detail for a complex tool with 11 parameters.

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 complexity (11 parameters, output schema exists), the description covers all parameter semantics, interactions, and return variations, leaving no gaps for effective use.

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?

With 100% schema description coverage, the baseline is 3, but the description adds significant value by explaining parameter interactions (e.g., in_force composing with status), the effect of include_expired on validity_state, and detailed output shape changes with verbose.

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 clearly states 'Full-text search across the KB' and distinguishes the tool from siblings like kb_get and kb_list by detailing unique filtering capabilities and behavioral nuances such as in_force, abstain, and verbose modes.

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?

Extensive guidance is provided for each parameter (e.g., when to use in_force vs include_expired, abstain behavior), but there is no explicit mention of when to use this tool versus alternatives like kb_audit or kb_list for non-full-text queries.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/knaisoma/data-olympus'

If you have feedback or need assistance with the MCP directory API, please join our Discord server