bikky

Official

by bikky-dev

Overview Schema Related Servers Score Discussions

TypeScript

Hybrid

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.4.6
Disambiguation5/5
Each tool has a clearly distinct purpose, ranging from setup and verification to memory storage, recall, maintenance, and pause/resume. Descriptions are detailed and explicitly clarify when to use each tool, preventing confusion.
Naming Consistency4/5
Core memory tools follow a consistent 'memory_' prefix pattern, but setup tools like 'get_setup_status' and 'configure_credentials' break this pattern. The mix is minor and still readable, but not perfectly uniform.
Tool Count4/5
18 tools is substantial but warranted given the comprehensive coverage of memory lifecycle and maintenance operations. It's slightly on the heavy side but each tool earns its place.
Completeness5/5
The tool set covers the entire memory lifecycle: setup, storage, retrieval, relation queries, forgetting, verification, feedback, session summaries, distillation, and pause/resume. No obvious gaps.
Average 4.6/5 across 18 of 18 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- 17 of 19 community issues answered or closed in the last 6 months
- 6 commits in the last 12 weeks
- Last stable release on May 20, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under AGPL 3.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries the burden. It declares 'Read-only — safe to call any time' and describes what it reports (missing credentials, onboarding instructions). No side effects or auth details needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each adding value. First sentence states purpose, second gives usage guidance, third details output and safety. No waste.
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 a zero-parameter, no-output-schema check tool, the description covers purpose, usage, output, and safety fully. Nothing else needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so schema_description_coverage is 100%. Baseline 3 is appropriate; no additional param info needed.
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 the verb 'Check' and resource 'memory system configured and reachable'. It distinguishes itself from siblings like memory_verify and memory_heartbeat by focusing on setup status and credential reporting.
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?
Explicit usage conditions are given: when memory tools return a 'setup_required' error or at session start. No exclusions or alternatives are mentioned, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that it persists credentials to a specific file, brings the memory system online, creates a collection if missing, and tests embeddings. However, it does not specify idempotency, error behavior, or what happens on invalid credentials. This is a useful but not exhaustive disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tightly focused sentences: first states the core action, second provides when-to-use, third gives alternative. No wasted words, efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description covers the main behavior, side effects, and usage context. It lacks details on failure modes or verification of success, but it is reasonably complete for a setup tool. It compensates for the missing annotations by providing key behavioral context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and each parameter already has a clear description. The description adds no additional meaning beyond what is in the schema, so the baseline of 3 applies.
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 the verb 'Persist' and the resource 'Qdrant and embedding credentials', and specifies the side effects of bringing memory system online, creating collection, and testing embeddings. It also distinguishes from the sibling tool get_setup_status by noting it is only for onboarding or credential rotation, while day-to-day use should prefer get_setup_status.
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?
Explicitly states when to call: 'only during onboarding (or when rotating credentials)'. Provides an alternative for regular use: 'For day-to-day use, prefer get_setup_status'. This gives clear guidance on usage context and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses ranking above raw facts, supersedes mechanism (old stays but excluded), and destination override. Could mention idempotency or return values.
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?
Mostly concise and front-loaded with purpose. Each sentence adds value. Slightly lengthy but structured well.
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 7 params and no output schema, description explains subtype, recall behavior, supersedes, destination, and even notes workspace_id is no-op. Comprehensive for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% but description adds value beyond: explains supersedes effect and destination override purpose. Provides context for entities and content formatting.
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 the verb 'Persist' and resource 'distilled convention' with specific attributes (kind='distilled', memory_subtype='convention'). It distinguishes from raw facts by emphasizing higher-signal recall.
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?
Explicitly tells when to use: pattern across facts/sessions. Contrasts with raw facts. Could add explicit 'when not to use' but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses key behaviors: resets staleness clock, bumps verification counter, lighter than memory_store(supersedes:). No annotations provided, so description carries full burden. Adequate coverage for a simple verification tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise: 4 sentences, each adding value. Front-loaded with main purpose, then effects, usage context, and alternatives. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (verify a fact), the description covers the main aspects: purpose, behavior, and when to use. No output schema, but the effects are described. Minor gap: no explicit mention of return value, but acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline 3 applies. The description does not add new information beyond what the schema already provides for the parameters. It repeats the schema's explanation of fact_id and workspace_id.
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 the tool's verb ('confirm') and resource ('existing fact'), and distinguishes it from siblings like memory_store(supersedes:) and memory_forget. It specifies that it does not re-store the fact, only verifies accuracy.
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?
Provides explicit when-to-use guidance: when memory_heartbeat surfaces a stale fact ID and you can confirm it's still true. Also gives alternatives: if fact is no longer true, use memory_forget or memory_store(supersedes:).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses key behaviors: writes function normally again after resume, and no-op if not paused. No annotations provided, so description carries full burden and does well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, no fluff. Front-loaded with the main action. Every word adds value.
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 a simple tool with one parameter and no output schema, description is complete: it covers state dependency, parameter requirement, and behavior when not applicable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. Description adds value by explaining session_id is the UUID from memory_pause and required for daemon extraction, beyond schema's basic description.
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?
Clearly states it resumes memory writes after a pause, with specific verb 'Resume' and resource 'memory writes'. Distinguishes from sibling tool memory_pause.
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?
Explicitly states it is used after memory_pause and notes no-op if not paused, guiding when to use and when not. Does not mention alternatives but context is clear given sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the burden. It discloses that relations are always returned, capped at 50 each direction, and that name matching is case-insensitive. This adds useful context beyond the schema, though it does not explicitly state read-only nature or performance characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with primary purpose, then usage guidelines. Every sentence adds value with no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and 6 parameters, the description adequately covers what the tool returns (facts and typed relations), usage guidelines, and parameter behavior. It could mention the return structure but is sufficient for entity lookup.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline is 3. The description adds value by explaining the name parameter is case-insensitive with an example, and clarifies that destination is a legacy override not to combine with search_scope. These additions justify a 4.
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 the tool retrieves all known facts and relations about an entity, and explicitly distinguishes it from memory_recall by specifying entity-centric queries. It names the alternative and gives preference rules.
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?
Provides explicit when-to-use: '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.' Also provides when not to use: 'If you only have a fuzzy description, use memory_recall first.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description takes full responsibility for behavioral disclosure. It explains relevance ranking (vector similarity blended with recency, importance, reinforcement), deduplication, output format options, limit clamping, graph_depth behavior, and search_scope mechanics. Slightly missing an explicit read-only declaration, but the nature of 'recall' and the operation parameters imply no mutation.
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-organized with a clear purpose statement, bulleted use cases, and distinct sections for scope and output. It is lengthy but every sentence serves a purpose. Some redundancy exists (e.g., repeated 'optional' notes), but overall efficient for the tool's complexity.
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?
Despite 25 parameters and no output schema, the description covers all essential aspects: usage scenarios, behavioral details, sibling differentiation, parameter hints, output format options, and scope configuration. It provides sufficient information for an AI agent to understand the tool's full capabilities and limitations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, setting baseline at 3. The description adds value by elaborating on key parameters: advises using full sentences for query, explains graph_depth's 1-hop behavior, details search_scope flexibility, and clarifies output_format defaults. While some parameters merely restate 'optional', the added context for complex fields boosts the score.
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 identifies the tool as performing semantic + filtered search over memory, with specific verb (recall) and resource (memory). It distinguishes from siblings memory_entity and memory_relations by describing their different use cases (full entity context vs. ownership/use queries), making selection unambiguous.
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?
Explicitly lists three main use cases (session-start briefing, per-prompt recall, conflict/replacement check) and provides clear when-not-to-use guidance by referencing sibling tools. Also directs user to memory_search_scopes for scope configuration, ensuring proper tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the behavior: returns triples, optional filters by direction and relation type. It also notes that there's no separate creation tool. However, it does not mention rate limits, authentication needs, or any side effects, but for a read query this is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with bold for key terms. Every sentence adds value: first states the core function, second gives usage examples and creation alternative. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 7 parameters and no output schema, the description provides enough context to use it correctly. It covers the main use case, filters, and how to create relations. Missing details like return format beyond 'triples' or pagination, but it's still complete enough for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds value by explaining the 'destination' parameter as an optional legacy override that should not be combined with search_scope, and by summarizing the filter options. This goes beyond repeating schema definitions.
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 'Query typed edges between entities' and distinguishes itself from semantic search and from the creation tool memory_store. It provides concrete use cases like 'what does X own / use / depend on?', making its purpose unambiguous.
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 explicitly tells when to use this tool ('for 'what does X own / use / depend on?' and 'who owns Y?' style questions') and when not to ('To create relations, use memory_store...'). This leaves no ambiguity about alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that it writes a telemetry outcome_event row for aggregation. With no annotations provided, this covers the core behavioral trait (write side effect) but omits details like authentication or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences that are dense with information: purpose, telemetry side effect, differentiation from sibling, and usage guidelines. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 params, no output schema, and no annotations, the description adequately covers what the tool does and when to use it. Could mention return value or error conditions, but not critical for a telemetry reporting tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%. Description adds value by explaining the meaning of each outcome enum and the purpose of notes. It also clarifies workspace_id is a no-op.
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?
Clear verb 'report' and resource 'outcome of a recalled fact'. Distinguishes from sibling 'memory_mark_useful' by noting it handles negative signals and richer data.
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?
Explicitly states when to use this tool vs 'memory_mark_useful', and defines when each outcome value is appropriate (useful, misleading, irrelevant, wrong).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes actions and their effects (approve bumps verification, reject marks superseded, correct stores new fact). No annotations provided, so description carries burden; lacks detail on data persistence or undo, but covers core behavior.
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?
Compact single paragraph covering purpose, prerequisite, actions, and key constraints. No wasted words, but could benefit from bullet points for easier scanning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequately covers tool purpose, actions, required params, and special cases (daemon dependency, deprecated fields). Missing output description (no output schema), but actions are well-defined.
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 100% and description enhances each parameter with clear context: default limit, action enum values explained, deprecated params noted as no-op, and required fields for actions spelled out.
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?
Clearly states it triages auto-captured facts from daemon/system, lists four specific actions, and distinguishes from sibling tools by targeting daemon/system-captured facts rather than general memories.
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?
Explicitly states when the tool is useful ('only when daemon is running'), warns of empty list otherwise, and describes each action's purpose and prerequisites (e.g., reason for reject, corrected_content for correct).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes storage specifics (kind, memory_subtype, canonical metadata) and future retrieval benefit. However, does not explicitly state write semantics (e.g., does it overwrite?), but 'persist' implies create. No annotations to contradict.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Five concise, front-loaded sentences. No redundancy, every sentence adds value. Structure is clear: action, storage details, usage guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 params (1 required), no output schema, no annotations, the description covers purpose, storage details, usage, and future retrieval. Lacks error states or idempotency, but adequate for selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%. The description adds value by explaining content purpose (goal, actions, remaining) and length target (30-80 words). For other params, it mainly echoes schema descriptions but clarifies overall intent.
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 the tool persists a compact session summary with specific content guidance. It distinguishes from siblings like memory_recall (retrieve) and memory_store (generic store) by specifying the kind and subtype.
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?
Explicitly advises to call near session close or milestones, and to skip trivial sessions. Also notes future sessions retrieve via memory_recall, providing clear when-to-use and when-not.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that fact stays in storage for audit but excluded from recall results, providing full behavioral context beyond annotations (none provided).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with purpose, no redundant information.
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?
No output schema, but description fully explains what happens (audit retention, exclusion from recall) and parameters are well-documented in schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description does not add extra detail beyond schema's parameter descriptions.
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?
Clearly states the tool marks a fact as superseded/wrong, distinguishes it from memory_store by explaining the difference when a corrected version exists.
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?
Explicitly tells when to use (fact incorrect/no replacement) and when not to (if corrected version exists, use memory_store with supersedes), with clear alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description fully explains behavior: write actions return session_paused status, read operations remain functional. Lists affected tools.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Efficient front-loading with main effect first, then structured list of affected tools, usage examples, and resume instruction. No redundant sentences.
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?
Covers all necessary aspects: what happens to writes, reads unaffected, how to resume, and optional parameters. No output schema needed for this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. Description adds context on session_id's dual purpose (skip extraction) and reason being included in response.
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?
Clearly states 'Pause all memory writes for the current session.' Lists exactly which write tools are affected, distinguishing it from memory_resume and other siblings.
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?
Explicit usage examples: 'Use when the user says something like do not remember anything from this session or pause memory.' Also directs to call memory_resume to re-enable writes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses 'does not write to disk' and 'Read-only,' which are key behavioral traits. Could add detail on response behavior, but sufficient for a simple check.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences, front-loaded with purpose. Every sentence adds value with no verbosity.
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?
Tool has no parameters, no output schema, and no annotations. The description covers purpose, usage guidance, and behavioral transparency (read-only, no disk write). Fully adequate for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist; schema coverage is 100% (trivially). Description adds no parameter info, but baseline 4 applies for zero-parameter tools. No improvement needed.
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?
Description starts with a clear verb+resource: 'Confirm Qdrant is reachable, embeddings work, and the collection exists.' It distinguishes from sibling configure_credentials by noting it is lighter and read-only.
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?
Explicitly states when to use: 'debug a sudden setup_required or empty-recall after a network blip or credential change.' Also contrasts with configure_credentials, providing clear usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Declares 'Read-only' behavior and details the contents returned (built-in scopes, destination-name scopes, configured named scopes, default_search_scope). No annotations present, so description carries full burden; it adds sufficient behavioral context beyond just the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficient sentences: first states purpose, second provides usage guidance and output details. No unnecessary words.
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 a simple listing tool with no parameters and no output schema, the description fully explains what it does, when to use it, and what it returns. Complete.
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?
No parameters exist, so schema coverage is 100%. Description adds value by explaining what the output contains (list of scopes and descriptions), which aids in understanding results.
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?
Description clearly states 'List the configured memory search scopes and destination descriptions' with specific verb 'List' and resource. It distinguishes from siblings by mentioning usage context for memory_recall, memory_entity, etc.
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?
Explicitly instructs to use before memory_recall, memory_entity, or memory_relations when multiple destinations exist, providing clear when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description fully covers behavioral traits. It explains return values (inserted, reinforced, potential conflicts), dedup mechanism, and the supersedes workflow. It also clarifies that relation edges can be created in the same call.
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 and front-loaded with the purpose. It contains several sentences, but every sentence adds value. Slightly verbose but still clear and organized.
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?
The tool has 19 parameters (3 required) and no output schema, yet the description covers return types, dedup, relation creation, and exclusions. It provides a comprehensive guide for this complex write tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all parameters. The description adds usage context beyond the schema, such as the dedup behavior, one-fact-per-call rule, and how to use the relation field. This adds significant value beyond baseline.
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 'Persist one atomic fact to long-term memory' and distinguishes this tool from siblings like memory_recall and memory_forget. It specifies the verb (persist), resource (memory), and scope (one atomic fact).
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 provides explicit when-to-use guidance (learning something future sessions need) and when-not-to-use (ephemeral state). It explains dedup behavior and directs users to recall first when broader context is needed. Alternatives like harness task folder are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description fully discloses behavioral traits: it explains the conditions for each return type (e.g., memory nudge if no storage in 10+ minutes, stale-fact alerts every 3rd call, reflection prompt always). It also states 'Cheap and read-only' and 'No arguments.' No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences with no wasted words. The first sentence states the purpose, the second details the returns, and the third gives usage frequency. Well-structured and front-loaded.
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 a tool with no parameters and no output schema, the description is remarkably complete. It explains all three return types, their triggering conditions, and usage frequency. Fully addresses the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters, the baseline is 4. The description adds context about what the tool returns and under what conditions, which is meaningful beyond the empty schema.
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 identifies 'memory_heartbeat' as a 'Reflection check-in' that returns up to three distinct items: memory nudge, stale-fact alerts, and a reflection prompt. It uses specific verbs and resources, differentiating it from sibling tools like memory_verify and memory_forget.
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?
Provides explicit guidance: 'Call periodically during interactive sessions — roughly every 10 minutes or every 3rd user prompt.' Also notes 'No arguments. Cheap and read-only,' which helps the agent decide when to invoke it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description fully discloses side effects: bumps 'useful_count' counter, writes telemetry feedback event, and notes workspace_id is a no-op. This meets the burden for transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single concise paragraph, front-loaded with purpose, no wasted words. Every sentence adds essential context.
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 no output schema, description sufficiently covers purpose, timing, alternatives, and side effects. An agent can correctly decide when and how to invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. Description adds value by clarifying fact_id source (memory_recall/memory_entity), note purpose (telemetry), and workspace_id deprecation. Extra context justifies a 4.
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 the tool reports a helpful recalled fact, with specific verb 'Report' and resource 'fact'. It explicitly distinguishes from sibling 'memory_report_outcome' by stating alternative for wrong/misleading facts.
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?
Usage guidelines are explicit: call only after confirming fact was helpful, not for every recalled fact. It provides a clear alternative: use memory_report_outcome for wrong/misleading facts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![bikky MCP server](https://glama.ai/mcp/servers/bikky-dev/bikky/badges/card.svg)](https://glama.ai/mcp/servers/bikky-dev/bikky)

Score Badge

Copy to your README.md:

[![bikky MCP server](https://glama.ai/mcp/servers/bikky-dev/bikky/badges/score.svg)](https://glama.ai/mcp/servers/bikky-dev/bikky)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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