Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
BIKKY_HOMENoPath to bikky home directory. Overrides default ~/.bikky.
QDRANT_URLNoURL of the Qdrant vector store. Default is http://localhost:6333.
OPENAI_API_KEYNoAPI key for OpenAI (used for embeddings and/or LLM).
QDRANT_API_KEYNoAPI key for Qdrant (optional for local Qdrant).

Capabilities

Features and capabilities supported by this server

CapabilityDetails
tools
{
  "listChanged": true
}

Tools

Functions exposed to the LLM to take actions

NameDescription
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:

  1. Session-start briefing — broad query like 'session briefing: user preferences, active projects, recent decisions'.

  2. Per-prompt contextual recall — focused query derived from what the user just asked.

  3. Conflict/replacement check — recall similar facts when you suspect new information may supersede an older fact. Deduplication during memory_store is automatic. Combine the natural-language query with structured filters (category, domain, entity, date range, metadata) for tighter results. If you have a known entity name and want everything about it, prefer memory_entity. For 'what does X own/use?' style questions, prefer memory_relations. When multiple Qdrant destinations are configured, use search_scope to choose 'routed' (routing/default behavior), 'all', a destination name, a configured scope name, a comma-separated destination list, or an array of destination names. Call memory_search_scopes to inspect available scopes and descriptions. By default output is human-readable text. Use output_format=json for machine-parseable results with separate results and related arrays. Default limit is 10; maximum effective limit is 50.

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

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

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/bikky-dev/bikky'

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