Shared Memory MCP Server

by evalops

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
Most tools have distinct purposes, such as 'create_agentic_session' for session creation and 'claim_work_unit' for task assignment, but some overlap exists between 'get_session_info' and 'get_session_stats', which could cause minor confusion as both relate to session data retrieval.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern with snake_case, such as 'add_discovery', 'await_dependency', and 'publish_output', making them predictable and easy to parse for agents.
Tool Count5/5
With 15 tools, this server is well-scoped for managing shared memory, agentic sessions, and work coordination, covering essential operations without being overly complex or sparse.
Completeness4/5
The tool set provides comprehensive coverage for session management, work unit handling, and context sharing, with minor gaps such as the lack of a tool to delete or terminate sessions, which agents might need to work around.
Average 2.8/5 across 15 of 15 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 3 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 passing
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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions that discoveries benefit 'other workers' but doesn't explain how this happens, whether notifications are sent, what permissions are required, whether this is a write operation, or what happens after adding a discovery. For a tool with 5 parameters and no annotation coverage, this is insufficient behavioral context.
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 a single, efficient sentence that gets straight to the point. There's no wasted language or unnecessary elaboration, making it appropriately concise for a tool description.
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?
For a tool with 5 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain what happens after adding a discovery, what format the 'data' parameter should contain, how discoveries are stored or accessed, or what the tool returns. Given the complexity and lack of structured documentation, the description should provide more context about the tool's role in the worker system.
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%, so the schema already documents all 5 parameters with their types, descriptions, and enum values. The description adds no additional parameter semantics beyond what's in the schema. The baseline score of 3 is appropriate when the schema does the heavy lifting for parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool 'adds a discovery that other workers can benefit from', which provides a basic purpose (adding discoveries) but lacks specificity about what constitutes a 'discovery' in this system. It doesn't clearly distinguish this tool from potential sibling tools like 'publish_output' or 'declare_outputs' that might also share information between workers.
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 guidance on when to use this tool versus alternatives. With sibling tools like 'publish_output', 'declare_outputs', and 'get_discoveries_since', there's no indication of when this specific discovery-adding tool is appropriate versus other information-sharing mechanisms in the system.
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 provided, the description carries the full burden of behavioral disclosure. It mentions 'compressed context' but fails to explain what that means operationally—such as data format, size limits, or whether it's read-only or has side effects. This leaves significant gaps in understanding the tool's 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?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded and to the point, though it could benefit from slightly more detail to improve clarity without sacrificing brevity.
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 lack of annotations and output schema, the description is incomplete. It doesn't explain what 'compressed context' returns, how it's structured, or any behavioral traits like error handling. For a tool with three parameters and no structured output information, more context is needed to ensure proper usage.
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?
The input schema has 100% description coverage, clearly documenting all three parameters. The description adds no additional meaning beyond the schema, such as explaining the relationship between 'session_id' and 'worker_id' or the significance of 'since_version'. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the action ('Get') and target ('compressed context for a specific worker'), which clarifies the purpose. However, it's vague about what 'compressed context' entails and doesn't differentiate from sibling tools like 'get_context_delta' or 'expand_context_section', leaving ambiguity about scope and distinctions.
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 like 'get_context_delta' or 'expand_context_section'. The description lacks context about prerequisites, such as needing a session and worker ID, or exclusions, which could lead to misuse without clear direction.
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 the full burden. It mentions publishing for consumption by other workers, which hints at a write operation with potential side effects, but it doesn't disclose behavioral traits like permissions needed, idempotency, rate limits, or what happens if the output key already exists. The description is too minimal to adequately inform the agent about the tool's 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?
The description is a single, efficient sentence that gets straight to the point without unnecessary words. It's front-loaded with the core action and purpose, though it could be more informative. There's no wasted text, earning a high score for 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 complexity implied by a write operation ('publish') with no annotations and no output schema, the description is incomplete. It doesn't explain the return values, error conditions, or how this tool fits into the broader workflow with siblings. For a tool that likely involves state changes and coordination, more context is needed to guide the agent effectively.
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%, so the schema already documents all three parameters (session_id, output_key, data) with basic descriptions. The description adds no additional meaning beyond what the schema provides, such as explaining the relationship between parameters or expected data formats. Baseline 3 is appropriate since the schema handles the parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the action ('publish') and the resource ('an output'), but it's vague about what 'publish' entails in this context and doesn't distinguish from siblings like 'declare_outputs' or 'publish_work_units'. It provides a basic purpose but lacks specificity about the mechanism or scope.
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 such as 'declare_outputs' or 'publish_work_units'. The description mentions 'for other workers to consume', which implies a collaborative context, but it doesn't specify prerequisites, exclusions, or clear usage scenarios relative to sibling tools.
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 the full burden of behavioral disclosure. It states the tool 'declares' outputs but doesn't explain what this means: whether it's a registration step, if it's idempotent, what permissions are required, or what happens after declaration. For a tool with three required parameters and no annotation coverage, this leaves critical behavioral traits unspecified.
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, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded with the core action and resource, making it easy to parse. Every word earns its place, achieving maximum clarity in minimal space.
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's complexity (three required parameters, no annotations, no output schema), the description is incomplete. It doesn't explain the operational context (e.g., how this fits into a worker lifecycle), what happens after declaration, or potential errors. For a tool that seems critical in a session/worker workflow, more contextual information is needed to guide proper use.
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%, so the schema fully documents the three parameters (session_id, worker_id, output_keys). The description adds no additional meaning beyond what's in the schema—it doesn't explain the relationship between these parameters or provide examples of output_keys. With high schema coverage, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool's purpose as declaring what outputs a worker will produce, which is clear but vague. It specifies the action ('declare') and resource ('outputs this worker will produce'), but doesn't distinguish it from sibling tools like 'publish_output' or explain what 'declare' means operationally. The purpose is understandable but lacks specificity about how this differs from related output-handling tools.
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 guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an active session or worker), exclusions, or relationships to sibling tools like 'publish_output' or 'create_agentic_session'. Without any usage context, an agent must infer when this declaration step is appropriate in a 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the action ('Get detailed information') without explaining what 'detailed information' entails, whether it's read-only, if it requires specific permissions, or how it behaves (e.g., error handling, rate limits). This is inadequate for a tool with no annotation coverage.
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, efficient sentence that front-loads the core purpose without unnecessary words. It is appropriately sized for the tool's complexity, with no wasted information, making it easy for an agent to parse quickly.
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 lack of annotations and output schema, the description is incomplete. It does not explain what 'detailed information' includes, the format of the response, or error conditions. For a tool with no structured behavioral or output data, this leaves significant gaps for an agent to understand its full 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?
The input schema has 100% description coverage, clearly documenting both parameters ('session_id' and 'section') with examples for 'section'. The description adds no additional meaning beyond the schema, such as parameter interactions or constraints, so it meets the baseline score of 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool's purpose ('Get detailed information for a specific context section'), which is clear but vague. It specifies a verb ('Get') and resource ('context section'), but does not distinguish it from sibling tools like 'get_context_delta' or 'get_worker_context', leaving ambiguity about what makes this tool unique.
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 guidance on when to use this tool versus alternatives. It does not mention prerequisites, context (e.g., when a session is active), or exclusions, and fails to differentiate from sibling tools such as 'get_context_delta', leaving the agent without usage direction.
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 provided, the description carries the full burden of behavioral disclosure. It states the tool updates status, implying a mutation, but doesn't cover critical aspects like required permissions, whether updates are reversible, rate limits, or what happens to related data (e.g., if 'result' is required for 'completed' status). This is inadequate for a mutation tool with zero annotation coverage.
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, efficient sentence with zero wasted words, front-loading the core action ('Update the status'). It's appropriately sized for the tool's complexity, making it easy for an agent to parse quickly.
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 a mutation tool with 4 parameters, no annotations, and no output schema, the description is incomplete. It lacks details on behavioral traits (e.g., side effects, error conditions), doesn't fully explain parameter interactions (e.g., 'result' dependency on 'status'), and omits return values or success indicators, leaving significant gaps for agent invocation.
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 75%, with three parameters documented ('session_id', 'unit_id', 'result') and one ('status') having an enum but no description. The description adds no parameter-specific semantics beyond implying 'status' updates and hinting at 'result' for completed units, offering minimal value over the schema. Baseline 3 is appropriate given the high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update the status of a work unit' clearly states the verb ('update') and resource ('work unit status'), providing a basic purpose. However, it lacks specificity about what a 'work unit' entails in this context and doesn't differentiate from sibling tools like 'update_session_status' or 'claim_work_unit', leaving room for ambiguity.
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 guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a valid session or claimed unit), exclusions, or comparisons to siblings such as 'update_session_status' for session-level updates or 'claim_work_unit' for initial assignment, leaving the agent without contextual usage cues.
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 mentions waiting behavior but doesn't disclose critical traits like whether it blocks execution, requires specific permissions, handles errors, or what happens on timeout. For a tool with potential blocking effects, this is a significant gap in behavioral context.
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, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded and appropriately sized, making it easy to parse quickly.
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 annotations, no output schema, and a tool that likely involves asynchronous waiting with potential side effects, the description is incomplete. It lacks details on return values, error handling, or operational constraints, which are crucial for an agent to use it correctly in a workflow 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 description coverage is 100%, so the schema already documents all parameters (session_id, dependency_key, timeout_minutes). The description doesn't add meaning beyond the schema, such as explaining what a 'dependency' entails or how the waiting mechanism works, resulting in a baseline score.
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 ('wait for') and resource ('a dependency'), specifying it waits for availability. However, it doesn't differentiate from sibling tools like 'get_session_info' or 'update_session_status' that might involve session states, making it clear but not sibling-distinctive.
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. With siblings like 'get_session_info' or 'update_work_status' that might relate to session or dependency states, the description lacks context on prerequisites, timing, or exclusions, offering minimal usage direction.
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 provided, the description carries full burden but only states the action without behavioral details. It doesn't disclose if claiming is exclusive, reversible, requires specific permissions, affects other workers, or has side effects like locking the unit. For a mutation tool with zero annotation coverage, this is a significant gap in 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?
The description is a single, efficient sentence with zero waste. It is appropriately sized and front-loaded, directly stating the tool's purpose without unnecessary elaboration, making it easy to parse quickly.
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 of a mutation tool with no annotations and no output schema, the description is incomplete. It lacks details on behavioral traits, return values, error conditions, and how it interacts with sibling tools. This leaves significant gaps for an AI agent to understand the tool's full 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 description coverage is 100%, so the schema fully documents all four parameters. The description adds no additional meaning beyond implying that parameters are used to claim a work unit, which is already inferred from the tool name. This meets the baseline for high schema coverage.
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 ('claim') and resource ('work unit for execution'), making the purpose understandable. It doesn't distinguish from sibling tools like 'publish_work_units' or 'update_work_status', which prevents a perfect score, but the verb+resource combination is specific enough for basic understanding.
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 guidance on when to use this tool versus alternatives like 'publish_work_units' or 'update_work_status'. It lacks context about prerequisites, such as whether a work unit must be unclaimed or available, and offers no explicit when-not or alternative scenarios.
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 provided, the description carries the full burden of behavioral disclosure. While 'Create' implies a write/mutation operation, the description doesn't address critical behavioral aspects like authentication requirements, rate limits, whether the session is immediately active, what happens if worker IDs are invalid, or what the expected response format might be. This is a significant gap for a creation tool with complex parameters.
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, efficient sentence that gets straight to the point with zero wasted words. It's appropriately sized for a tool description and front-loads the essential information about what the tool does.
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?
For a complex session creation tool with 7 parameters (3 required), no annotations, and no output schema, the description is inadequate. It doesn't explain what constitutes a successful creation, what gets returned, error conditions, or how this tool fits into the broader agentic workflow with its many sibling tools. The description leaves too many open questions for proper agent usage.
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?
The description mentions 'shared context' which relates to the session's purpose but doesn't explain any of the 7 parameters beyond what the schema provides. With 57% schema description coverage (4 of 7 parameters have descriptions), the baseline is 3 since the schema does moderate work, but the description adds no additional parameter context to compensate for the coverage gap.
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 ('Create a new agentic session') and the resource ('with shared context for coordinator and workers'), which is specific and actionable. However, it doesn't explicitly differentiate this tool from its many siblings (like 'get_session_info' or 'update_session_status'), which would be needed for a perfect score.
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 guidance on when to use this tool versus alternatives. With 14 sibling tools including session-related ones like 'get_session_info' and 'update_session_status', there's no indication of prerequisites, typical workflow context, or when other tools might be more appropriate.
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 provided, the description carries full burden for behavioral disclosure. While 'Get incremental updates' implies a read operation, it doesn't specify what constitutes 'updates' (e.g., context changes, discoveries, work units), whether there are rate limits, authentication requirements, or what format the updates are returned in. This leaves significant behavioral gaps for a tool with 3 required parameters.
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, efficient sentence that gets straight to the point with zero wasted words. It's appropriately sized for the tool's apparent complexity and front-loads the core functionality.
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?
For a tool with 3 required parameters, no annotations, and no output schema, the description is insufficiently complete. It doesn't explain what 'incremental updates' consist of, how they're structured, what happens if 'since_version' is invalid, or what the return format is. Given the sibling tools suggest this is part of a session/worker system, more context about the update content is 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?
Schema description coverage is 100%, so all parameters are documented in the schema. The description adds minimal value beyond the schema - it mentions 'since a specific version' which aligns with the 'since_version' parameter, but doesn't provide additional context about parameter relationships or usage patterns. Baseline 3 is appropriate when the schema does the heavy lifting.
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 ('Get incremental updates') and the scope ('since a specific version'), providing a specific verb+resource combination. However, it doesn't distinguish this tool from sibling tools like 'get_discoveries_since' or 'get_worker_context', which appear to have similar incremental retrieval patterns.
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 guidance on when to use this tool versus alternatives like 'get_discoveries_since' or 'get_worker_context'. It doesn't specify prerequisites, appropriate contexts, or exclusions, leaving the agent with no usage differentiation from sibling tools.
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 states the action but lacks behavioral details: it doesn't specify if this is a read-only operation, what permissions are needed, how results are returned (e.g., pagination, format), or error handling. This is a significant gap for a tool with no annotation coverage.
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, efficient sentence with zero waste. It is appropriately sized and front-loaded, directly stating the tool's purpose without unnecessary elaboration.
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 annotations and no output schema, the description is incomplete. It doesn't explain return values, error cases, or behavioral traits, leaving gaps for a tool that likely returns data. More context is needed to fully understand how to use it effectively.
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%, so the schema already documents both parameters ('session_id' and 'since_timestamp'). The description adds no additional meaning beyond implying temporal filtering, which is already clear from the schema. Baseline 3 is appropriate when schema does the heavy lifting.
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 verb ('Get') and resource ('discoveries'), specifying the temporal scope ('since a specific timestamp'). It distinguishes from siblings like 'get_session_info' or 'get_session_stats' by focusing on discoveries, but doesn't explicitly differentiate from potential similar tools (none listed).
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 is provided. The description implies usage when needing discoveries after a timestamp, but doesn't mention prerequisites, exclusions, or compare to siblings like 'get_context_delta' or 'expand_context_section' that might relate to context changes.
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 the full burden of behavioral disclosure. While 'Get information' implies a read-only operation, it doesn't specify what type of information is returned, whether authentication is required, if there are rate limits, or what happens with invalid session IDs. For a tool with no annotation coverage, this leaves significant behavioral gaps.
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, efficient sentence that states the core purpose without unnecessary words. It's appropriately sized for a simple retrieval tool and front-loads the essential information. Every word earns its place in this concise formulation.
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?
For a tool with no annotations and no output schema, the description is insufficiently complete. It doesn't explain what information is returned, how results are structured, or what distinguishes this from similar sibling tools. The agent would need to guess about the return format and when to use this versus alternatives, making this description inadequate for the 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?
The input schema has 100% description coverage, with the single parameter 'session_id' clearly documented. The description doesn't add any additional parameter context beyond what the schema provides, such as format examples or constraints. With complete schema coverage, the baseline score of 3 is appropriate as the description doesn't enhance parameter understanding.
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 verb 'Get' and resource 'information about an agentic session', making the purpose understandable. However, it doesn't differentiate from sibling tools like 'get_session_stats' or 'get_context_delta', which also retrieve session-related information, leaving some ambiguity about what specific information this tool provides compared to alternatives.
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 guidance on when to use this tool versus alternatives. With siblings like 'get_session_stats' and 'get_context_delta' that likely retrieve different aspects of session data, there's no indication of what makes this tool distinct or when it should be preferred over other information-retrieval tools.
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 provided, the description carries full burden for behavioral disclosure. It mentions that work units become 'available for workers to claim,' which implies a state change, but doesn't address critical aspects like whether this is idempotent, what permissions are required, error conditions, or how publishing affects existing work units. The description is insufficient for a mutation tool with zero annotation coverage.
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, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, making it easy to understand at a glance.
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 of a mutation tool with 2 parameters (one being a complex array), no annotations, and no output schema, the description is incomplete. It lacks details on behavior, error handling, return values, and usage context, leaving significant gaps for an AI agent to understand how to invoke it correctly.
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 50% (only 'session_id' has a description). The description mentions 'work units' but doesn't explain the structure or semantics of the 'work_units' array parameter beyond what's in the schema. It adds minimal value over the schema, which already defines the properties like 'unit_id', 'type', and 'priority' without descriptions.
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 ('publish') and resource ('available work units'), specifying the purpose as making work units available for workers to claim. It's specific about the outcome but doesn't explicitly differentiate from sibling tools like 'claim_work_unit' or 'update_work_status'.
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 guidance on when to use this tool versus alternatives like 'claim_work_unit' or 'update_work_status', nor does it mention prerequisites such as needing a valid session. It simply states what the tool does without contextual usage information.
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 provided, the description carries the full burden of behavioral disclosure. It states 'Update' implies mutation but doesn't cover critical aspects like required permissions, whether changes are reversible, error handling, or side effects. This is inadequate for a mutation tool with zero annotation coverage.
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, efficient sentence with zero waste—it directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, making it easy to parse quickly.
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's complexity (mutation with 2 required parameters), lack of annotations, and no output schema, the description is incomplete. It doesn't address behavioral traits, parameter meanings, or usage context, leaving significant gaps for an AI agent to understand how to invoke it correctly.
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 50% (only 'session_id' has a description, 'status' lacks one). The description adds no parameter semantics beyond what the schema provides—it doesn't explain what a session ID is, the meaning of status values, or constraints. Baseline 3 is appropriate as the schema does some work, but the description doesn't compensate for the coverage gap.
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 ('Update') and resource ('status of an agentic session'), providing a specific verb+resource combination. However, it doesn't differentiate from sibling tools like 'update_work_status' or 'create_agentic_session', which would require mentioning what makes this tool unique for session status updates.
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 guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing session), exclusions, or how it relates to siblings like 'update_work_status' or 'get_session_info', leaving the agent to infer usage 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?
No annotations are provided, so the description carries full burden. It states the action is to 'Get statistics', implying a read-only operation, but doesn't disclose behavioral traits such as whether it requires authentication, has rate limits, what format the statistics are in, or if it's real-time vs. cached. This leaves significant gaps for an agent to understand how to invoke it effectively.
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, efficient sentence that directly states the tool's purpose without any waste. It's appropriately sized and front-loaded, making it easy to parse quickly.
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 of a statistics tool with no annotations and no output schema, the description is incomplete. It doesn't explain what statistics are returned, their format, or any behavioral context, leaving the agent with insufficient information to use the tool correctly in a real scenario.
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?
The tool has 0 parameters, and schema description coverage is 100%, so there's no need for parameter details in the description. The baseline for 0 parameters is 4, as the description doesn't need to compensate for any missing param info, but it doesn't add extra semantic value beyond the schema.
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 verb 'Get' and the resource 'statistics about the shared memory system', making the purpose understandable. However, it doesn't differentiate from sibling tools like 'get_session_info' or 'get_context_delta', which might also retrieve session-related information, so it doesn't reach the highest score.
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 guidance on when to use this tool versus alternatives. With siblings like 'get_session_info' and 'get_context_delta', there's no indication of what specific statistics this tool provides or in what context it should be selected, leaving usage unclear.
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:

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

Score Badge

Copy to your README.md:

[![shared-memory-mcp MCP server](https://glama.ai/mcp/servers/evalops/shared-memory-mcp/badges/score.svg)](https://glama.ai/mcp/servers/evalops/shared-memory-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/evalops/shared-memory-mcp'

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