LogicMem MCP Server

Official

by LogicMem

Overview Schema Related Servers Score Discussions

Python

Remote

Server Quality Checklist

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

Latest release: v0.1.1
Disambiguation5/5
All 12 tools have clearly distinct purposes, split into two coherent groups: memory operations (log, recall, stats, session, health, outcome, reflect) and A2A operations (register, heartbeat, list_agents, write_shared, sync). No overlapping functionality.
Naming Consistency5/5
Tool names follow a consistent pattern: `logicmem_<group>_<action>`. Memory tools use `memory_` and A2A tools use `a2a_`. Verbs are descriptive (log, recall, stats, etc.), making the pattern predictable.
Tool Count5/5
With 12 tools covering memory management and agent-to-agent communication, the count is well-scoped. Each tool serves a distinct function without redundancy, fitting the server's purpose.
Completeness4/5
The set covers core memory operations (store, recall, stats, session, outcome, reflect, health) and A2A operations (register, heartbeat, list, write shared, sync). Minor gaps exist, such as no explicit delete/update for memories, but the design suggests permanence.
Average 2.9/5 across 12 of 12 tools scored. Lowest: 2.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 19 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under MIT License.
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

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must convey behavioral traits. It merely states 'write' which implies mutation, but gives no details on idempotency, overwrite behavior, permissions, or side effects. This is a critical omission.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is efficient in word count, but it lacks necessary detail. It does not earn its place because it fails to inform the agent adequately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters, no schema descriptions, no annotations, and no output schema, the description is far from complete. It does not explain return values, side effects, or parameter constraints, leaving the agent underserved.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 7 parameters with 0% description coverage, and the tool description adds no semantic meaning to any parameter. The agent must guess the roles of agent_id, client_id, tags, category, importance, is_private, etc.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (write) and the target (memory to shared A2A pool). It is specific enough to distinguish from many sibling tools, though it doesn't explicitly differentiate from any potential write-like siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. No prerequisites, constraints, or exclusions are mentioned. The description provides no context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only states the action without mentioning idempotency, side effects, prerequisites, or error behavior. For a mutation-like 'send' action, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words, but it is too concise for a tool with 3 parameters. A slightly longer description could add necessary detail without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters, no output schema, and no annotations, the description is insufficient. It fails to explain return values, parameter semantics, or behavioral context, leaving significant gaps for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any parameter (agent_id, client_id, status). The optional 'status' parameter has no hints about valid values or purpose. This leaves the agent completely uninformed about parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Send a heartbeat to the A2A registry' clearly identifies the action (send) and resource (A2A registry heartbeat). It is distinct from sibling tools like register or list agents, but could specify the purpose of a heartbeat (e.g., keep-alive) for added clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool vs siblings like logicmem_a2a_register. An agent would not know if a heartbeat is required after registration, for periodic keep-alives, or for health checks. Usage context is absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description only says 'Register', which implies a state change but lacks details on side effects, idempotency, or authentication requirements. Very limited transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is a single short sentence, which is concise but may be too brief. It could include more structured information without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, no annotations, and 4 parameters with no descriptions, the tool description lacks completeness. It does not explain the registration process or what happens after registration.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not explain any of the 4 parameters (name, agent_id, client_id, agent_type). Agents must infer meaning from parameter names alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Register this agent in the A2A registry', using a specific verb and resource. It distinguishes from sibling tools like heartbeat or list agents, but could elaborate on what registration entails.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, prerequisites, or conditions under which registration is needed. The description provides no usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Behavioral transparency is very low. The description does not disclose whether the tool has side effects, is read-only, or what exactly 'evaluate' entails (e.g., returns score, critique text). Since no annotations are present, the description must bear the full burden, and it fails to provide sufficient behavioral insight.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, consisting of a single sentence. However, it could be more informative without significant added length. It is not overly long, but the lack of detail reduces its effectiveness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This tool has 3 parameters, no output schema, and no annotations. The description is insufficient to fully understand the tool's behavior and expected inputs. It lacks context about the evaluation process, return format, and potential side effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description gives a hint that draft_answer is the answer to evaluate and that memories are involved, but it does not explicitly map parameters to their roles. The memory_query parameter is not explained at all. With 0% schema coverage, the description should compensate but does not.
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 function: evaluating a draft answer against retrieved memories. It specifies the verb 'evaluate' and the resources 'draft answer' and 'retrieved memories'. This helps distinguish from sibling tools like logicmem_memory_log or logicmem_memory_recall, which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidelines are provided. The description does not indicate when to use this tool versus alternatives, nor does it give any context about prerequisites or typical workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavioral traits. It states 'Check for new shared memories' but does not clarify if the operation is read-only, whether it modifies internal state (like updating a last-sync timestamp), or what happens if there are no new memories. It also omits details about authentication requirements or error conditions. This leaves significant behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise and front-loaded with the verb and resource. However, its brevity sacrifices necessary detail for a tool with 4 parameters and no other documentation. It earns its place but could be slightly expanded without becoming overly long.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (4 parameters, 0% schema coverage, no output schema, no annotations), the description is incomplete. It does not explain the purpose of each parameter, the return format, or the operational context relative to sibling tools. An AI agent would have significant gaps in understanding how to invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must explain each parameter. However, it only mentions the concept of 'since last sync' without explicitly linking to the since_timestamp parameter. It does not clarify the roles of agent_id and client_id, or the purpose of limit. This provides minimal added meaning beyond the parameter names themselves.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's function: checking for new shared memories from other agents since the last sync. It uses a specific verb ('Check for') and resource ('new shared memories'), and it differentiates from siblings like logicmem_a2a_write_shared (writing) and logicmem_a2a_list_agents (listing agents). However, it could be more precise about the action (e.g., retrieve vs. check).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. It does not mention when not to use it, or reference related tools like logicmem_a2a_write_shared or logicmem_memory_recall. The purpose implies use for synchronization, but without explicit direction, an AI agent must infer usage from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavioral traits. It only states the high-level action, omitting side effects (e.g., model updates), required permissions, idempotency, rate limits, or what happens on failure. The feedback pipeline implication is hinted but not detailed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no fluff, and front-loaded. However, extreme brevity sacrifices essential details, making it more underspecified than concise. A balanced tool description would add parameter context while remaining succinct.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, 0% parameter coverage, and no annotations, the description fails to provide adequate context for correct invocation. Agent lacks understanding of input semantics, expected outputs, and error states, making tool usage unreliable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the description adds no parameter explanation beyond the schema. The parameters memory_ids, success, and magnitude lack semantic context: what constitutes a 'useful' memory, how magnitude affects training, or how to source valid memory_ids. Agent cannot infer correct usage.
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 verb 'record' and resource 'whether a stored memory was useful'. It also specifies the downstream purpose 'Feeds the DPO training pipeline', distinguishing it from sibling tools like logicmem_memory_log or logicmem_memory_recall.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus its siblings, nor any prerequisites or conditions for invocation. The description does not specify that this should be called only after a memory is retrieved and evaluated, leaving the agent without decision criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only states 'List all registered agents,' which implies a read-only operation, but it does not explain pagination, rate limits, or whether any shared state is modified. This lack of detail is insufficient for a trustworthy tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise, but it sacrifices necessary details. It can be expanded without becoming overly long, so the score reflects average efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low schema coverage, no output schema, and simple parameter set, the description should provide more context about return values, error cases, and registration semantics. It falls short of being complete for agent decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one required parameter (client_id) with 0% documentation coverage. The description does not explain what client_id represents, expected format, or constraints, leaving a critical gap for the agent to know how to use it correctly.
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 a specific verb-resource pair: 'List all registered agents for a client_id.' This distinguishes it from sibling tools like logicmem_memory_recall, which handle different resources or operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. There is no mention of prerequisites, limitations, or comparison with similar tools, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only says 'search,' implying read-only, but does not disclose whether it modifies state, requires authentication, or has rate limits. The meaning of 'relevant' is also unspecified.
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?
Single sentence, no wasted words. However, it is too brief to provide helpful context; a slightly longer description could improve utility without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/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 should explain return format or ranking behavior. It does not, leaving the agent uncertain about what results look like.
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?
All 3 parameters have descriptions in the schema (100% coverage), so baseline is 3. The tool description adds no extra meaning about parameter interaction, valid query formats, or typical limits.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Search memory for relevant entries,' clearly indicating a search/retrieval action against the memory resource. However, it does not explicitly differentiate from sibling search-like tools (e.g., logicmem_memory_reflect might also retrieve info).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives like logicmem_memory_log (store) or logicmem_memory_reflect (process). No exclusion criteria or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry the burden. It states the tool returns a composite of recall, sentiment, constraints, intelligence, and gaps, but does not disclose side effects, safety, or permission requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single line, no waste, but it reads like a label rather than a complete sentence. Could be more structured with explicit verbs or bullet points.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple input schema and no output schema, the description provides the core intention but lacks details on output format, whether the tool creates or retrieves a session, and how it fits with sibling tools.
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 description coverage is 100% for the single parameter 'client_id', but the description adds no extra meaning beyond the basic 'Client ID'. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Full memory session briefing' and lists components (recall, sentiment, constraints, intelligence, gaps), distinguishing it from siblings like logicmem_memory_recall which likely focuses on recall only.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool compared to alternatives like logicmem_memory_recall or logicmem_memory_stats. The description does not provide context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description does not disclose behavioral traits such as whether it is read-only or what happens if the server is unhealthy. The name implies a simple check, but details are absent.
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?
The description is a single, concise sentence that front-loads the purpose. It efficiently earns its place with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the tool's simplicity, the description lacks details about what 'healthy' means or the return value, leaving the agent guessing. With no output schema, more context is needed.
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?
There are no parameters, so schema coverage is trivially 100%. The description does not need to add parameter semantics, and a baseline of 4 is appropriate.
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 checks the health of the LogicMem memory server using a specific verb and resource, and it is distinguishable from siblings like logicmem_memory_log or logicmem_memory_stats.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives or any prerequisites. The description is purely functional without contextual usage advice.
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?
The description clearly states 'the agent's memory is permanent and searchable across sessions,' which discloses key behavioral traits beyond what annotations (none provided) convey. It does not discuss potential side effects, but for a non-destructive store operation this is sufficient. No contradiction with missing annotations.
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?
The description consists of two short sentences that are front-loaded with the primary action. Every word serves a purpose: stating the verb, noting permanence, and providing a concrete usage hint. There is no redundant or superfluous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has six parameters and no output schema or annotations, the description covers the core behavioral trait (permanence) but omits details about return values, error conditions, or rate limits. While the schema is well-described, the description does not fully compensate for the lack of structured output documentation. It is adequate but not comprehensive.
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 for parameters is 100%, so the baseline is 3. The description adds value by instructing agents to be specific about who, what, when, why, but this only applies to the 'text' field. Other parameters (tags, source, category, client_id, importance) are not elaborated beyond their schema descriptions. No significant additional meaning is provided.
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 begins with 'Store a new memory,' clearly stating the verb and resource. This distinguishes it from sibling tools like logicmem_memory_recall (retrieve) and logicmem_memory_stats (query statistics). There is no ambiguity about what action the tool performs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises agents to 'include who, what, when, why,' which guides how to populate the text field. However, it does not compare this tool to alternatives or explicitly state when to use it versus other storage tools like logicmem_a2a_write_shared. The guidance is present but lacks exclusions or context differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/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 returns stat categories, but lacks details on real-time nature, side effects, or authentication requirements.
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?
The description is a single sentence that is front-loaded and contains no redundant information.
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 simple stats endpoint with no parameters and no output schema, the description covers the core information. It is nearly complete, though it could hint at whether stats are aggregated or per-session.
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?
The input schema is empty (0 parameters), so baseline is 4. The description adds meaning by specifying what information is returned (total entries, categories, storage), going beyond the 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 states a specific verb ('Get') and resource ('memory system stats'), and lists the categories ('total entries, categories, storage'), clearly distinguishing it from sibling tools like logicmem_memory_log or logicmem_memory_recall.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the description (use to get stats), but there is no explicit guidance on when to use this tool vs. alternatives or any exclusion criteria.
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:

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

Score Badge

Copy to your README.md:

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

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/LogicMem/LogicMem-mcp-'

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