data-olympus MCP server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Capabilities
Features and capabilities supported by this server
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| logging | {} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| extensions | {
"io.modelcontextprotocol/ui": {}
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| kb_healthA | Return service health: kb_commit, index_built_at, staleness, degraded flag, and write-side state (pending_count, push_queue_size, last_index_*). verbose: False (default) returns a token-compact shape that keeps the core snapshot and OMITS diagnostic fields that are null/empty (e.g. last_index_error, remote_head_sha when unset). verbose=True returns every field including the nulls. pending_actions, when present, lists open maintenance items (missing
|
| kb_searchA | 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 A doc past its 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 verbose: False (default) returns a token-compact shape. Each hit is
{id, title, snippet} plus |
| kb_getA | Retrieve a document by id (STD-U-001, ADR-002, T-NNN, etc.).
Returns the full content markdown plus metadata. Use this when you have a
specific id (from Always resolves regardless of expiry (ids never dangle): an expired
document is still returned, with its full verbose: False (default) returns the full |
| kb_session_recapA | Read-only per-session write summary (issue #112 feedback loop):
N committed, M demoted-to-pending, K rejected for source_session.
Call this (or |
| kb_consultA | Record a consultation for (source_session, workspace) and return the governing rules for the intent. Call before code/architectural work. trigger is 'explicit' (default: a deliberate consult, clears the gate) or 'prompt_hook' (an installer auto-consult: audited, never clears). Retrieval is hard-filtered to the in-force class (active/accepted/ approved, within its validity window, and never a memory-inbox doc): an unreviewed proposed memory, a retired/superseded decision, an expired doc, or a legacy/forged inbox file is never returned as a governing rule. pending_actions, when present, lists open maintenance items (missing
|
| kb_gate_checkA | Return a verdict (allow | consult_required) for a pending code action.
Governed actions require a fresh consultation on record. Records each
check to the audit log (non-destructive; |
| kb_record_eventA | Append a durable, non-destructive audit entry for a client-reported enforcement event. Requires write capability (not a read-only tool). event_type is gate_bypass (agent proceeded despite a gate block) or gate_degraded (kb_gate_check was unavailable; last-known state used). workspace, agent_identity, source_session are required; reason is optional but recommended for gate_bypass entries. Use this when an enforce hook bypassed or degraded the gate and the fallback must be recorded. To check gate status use kb_gate_check; to consult use kb_consult; to read back events use kb_audit or kb_compliance. |
| tool_searchA | Search for tools using natural language. Returns matching tool definitions ranked by relevance, in the same format as list_tools. |
| call_toolB | Call a tool by name with the given arguments. Use this to execute tools discovered via search_tools. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| onboard | Guided entry point: detect the workspace, then route to project or component onboarding. |
| onboard_project | Guided full-project (T3) onboarding: import, interview, bootstrap, clean up. |
| onboard_component | Guided component (T4) onboarding under a known project. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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