bikky
OfficialServer Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| BIKKY_HOME | No | Path to bikky home directory. Overrides default ~/.bikky. | |
| QDRANT_URL | No | URL of the Qdrant vector store. Default is http://localhost:6333. | |
| OPENAI_API_KEY | No | API key for OpenAI (used for embeddings and/or LLM). | |
| QDRANT_API_KEY | No | API key for Qdrant (optional for local Qdrant). |
Capabilities
Features and capabilities supported by this server
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_setup_statusA | Check whether the memory system is configured and reachable. Use this when memory tools return a 'setup_required' error, or once at session start if you're not sure bikky is wired up. Reports which credentials are missing and includes onboarding instructions if anything is incomplete. Read-only — safe to call any time. |
| memory_search_scopesA | List the configured memory search scopes and destination descriptions. Use this before memory_recall, memory_entity, or memory_relations when multiple destinations exist so you can choose the right search_scope. Read-only — returns built-in scopes ('routed', 'all'), destination-name scopes, configured named scopes, and the default_search_scope. |
| configure_credentialsA | Persist Qdrant and embedding credentials to ~/.bikky/config.json and bring the memory system online. Call this only during onboarding (or when rotating credentials). After it succeeds, the collection is created if missing and embeddings are tested. For day-to-day use, prefer get_setup_status. |
| verify_connectionA | Confirm Qdrant is reachable, embeddings work, and the collection exists. Use this to debug a sudden 'setup_required' or empty-recall after a network blip or credential change. Lighter than configure_credentials — does not write to disk. Read-only. |
| memory_storeA | Persist one atomic fact to long-term memory. Call this whenever you learn something a future session would need: a service detail, a decision rationale, a workaround, a user preference, an ownership fact, a task-resume pointer. One fact per call — split compound observations into separate calls. Dedup is automatic (content hash + vector similarity), so you do NOT need to recall first for deduplication. Recall first only when you intentionally need broader context to decide whether a new fact supersedes an older one. The tool returns one of: inserted (new fact), reinforced (exact or near-duplicate found — counters bumped), or — if there are similar-but-different facts — a list of potential conflicts so you can decide whether to use 'supersedes'. To create a typed edge between two entities at the same time, set the optional 'relation' field — no separate tool call needed. Do NOT use for ephemeral state (current cursor, in-flight todo). Use the harness task folder instead. |
| memory_recallA | Semantic + filtered search over memory. Returns facts ranked by relevance (vector similarity blended with recency, importance, and reinforcement). Three main uses:
|
| memory_entityA | Get everything bikky knows about a specific entity — facts mentioning it plus typed relations into and out of it. Prefer this over memory_recall when the user asks 'tell me about X' or 'what do we know about X' and X is a known entity name (service, person, repo, concept). Faster and more complete than semantic search for entity-centric queries. If you only have a fuzzy description, use memory_recall first to find the entity name. |
| memory_relationsA | Query typed edges between entities. Returns 'A --[type]--> B' triples that semantic search alone wouldn't surface. Use for 'what does X own / use / depend on?' and 'who owns Y?' style questions. Optionally filter by direction (from / to / both) and relation type. To create relations, use memory_store with the 'relation' field — there is no separate create-relation tool. |
| memory_forgetA | Mark a fact as superseded/wrong. The fact stays in storage (for audit) but is excluded from all recall results. Use this when a fact was simply incorrect or no longer applies and there is no replacement. If you have a corrected version, use memory_store with 'supersedes: ' instead — that way the new fact stays linked to the old one. |
| memory_verifyA | Confirm an existing fact is still accurate, without re-storing it. Resets the staleness clock and bumps a verification counter. Use this when memory_heartbeat surfaces a stale fact ID and you can confirm it's still true (e.g. you just observed the system in that state). Lighter than memory_store(supersedes:) — same content, fresh timestamp. If the fact is no longer true, use memory_forget or memory_store(supersedes:) instead. |
| memory_mark_usefulA | Report that a previously recalled fact actually helped you answer the user's question or complete a task. Bumps a 'useful_count' counter on the fact and writes a telemetry feedback_event row that future ranking work can aggregate. Call this AFTER you used a fact from memory_recall / memory_entity and confirmed it was helpful — not for every recalled fact. If the fact was wrong or misleading, use memory_report_outcome with outcome='wrong' or 'misleading' instead. |
| memory_report_outcomeA | Report the downstream outcome of using a recalled fact — useful, misleading, irrelevant, or wrong. Writes a telemetry outcome_event row that future ranking and review work can aggregate. Unlike memory_mark_useful (positive-only, bumps a counter), this records a richer signal including negative outcomes and optional notes. Use this when you can confidently judge whether a fact actually helped: 'useful' = helped you complete the task; 'misleading' = pointed in a wrong direction; 'irrelevant' = matched semantically but didn't help; 'wrong' = factually incorrect (also consider memory_forget for clearly wrong facts). |
| memory_session_summaryA | Persist a compact summary of the current session — what got done, what decisions were made, what's still open. Stored as kind='summary', memory_subtype='session_index' with canonical origin metadata. Keep it short (target 30-80 words). Future sessions retrieve these via memory_recall to bootstrap context faster than re-reading the original transcript. Call this near session close (or at major milestone boundaries) when the work is meaningful enough to want a future agent to inherit. Skip for trivial single-question sessions. |
| memory_distillA | Persist a distilled convention — a reusable learning, pattern, or runbook synthesized from multiple prior memories. Stored as kind='distilled', memory_subtype='convention' with canonical origin metadata. Use this when you've noticed a pattern across several prior facts/sessions that's worth surfacing as its own atomic learning. The new memory will rank above raw facts in semantic recall because distilled patterns are higher-signal. Provide 'supersedes' if this distillation replaces an earlier convention. The original stays in storage but is excluded from recall. |
| memory_reviewA | Triage facts that were captured automatically by Bikky (origin.interface='daemon' or legacy source='system'). Only useful when the daemon is running and capturing memories from logs/transcripts; otherwise this returns an empty list. Supports four actions: list (default — show recent daemon/system-captured facts), approve (mark verified), reject (mark superseded with reason), correct (replace with edited content as a new fact). |
| memory_pauseA | Pause all memory writes for the current session. While paused, memory_store, memory_session_summary, memory_distill, memory_verify, memory_forget, memory_mark_useful, memory_report_outcome, and memory_review (write actions) will return a session_paused status instead of executing. Read operations (memory_recall, memory_entity, memory_relations, memory_heartbeat) remain fully functional. Use when the user says something like 'do not remember anything from this session' or 'pause memory'. Call memory_resume to re-enable writes. |
| memory_resumeA | Resume memory writes after a previous memory_pause. All write operations will function normally again. No-op if memory is not currently paused. |
| memory_heartbeatA | Reflection check-in. Returns up to three things: a memory nudge if you haven't stored anything in 10+ minutes, stale-fact alerts every 3rd call (with IDs you can pass to memory_verify or memory_forget), and a reflection prompt asking whether the last few minutes of work produced anything worth storing. Call periodically during interactive sessions — roughly every 10 minutes or every 3rd user prompt. No arguments. Cheap and read-only. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
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/bikky-dev/bikky'
If you have feedback or need assistance with the MCP directory API, please join our Discord server