continuityos

by bitmaster162

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.9.0
Disambiguation2/5
Several tools overlap: remember/upsert/memory_write_checked all write memories; recall/context/find all retrieve; preflight_action/alignment/devils_advocate all check actions. The descriptions don't sufficiently clarify when to use one over another, leading to potential misselection.
Naming Consistency2/5
Tool names mix single verbs (remember, find), nouns (context, alignment), compound verbs (set_frontier, preflight_action), and technical jargon (upsert, srd_status). There is no consistent verb_noun or other uniform pattern, making the set feel chaotic.
Tool Count3/5
At 19 tools, the count sits in the heavier range. Many tools serve overlapping purposes and could be consolidated (e.g., recall/context, alignment/devils_advocate), suggesting slight over-scoping for the domain.
Completeness4/5
The core memory lifecycle is well covered: create (remember/upsert), read (recall/find/context), update (upsert), delete (forget). Session continuity tools (checkpoint/handoff) and safety checks add depth. Minor gaps like no direct ID lookup and no batch operations exist but are workable.
Average 3.6/5 across 19 of 19 tools scored. Lowest: 2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 441 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 Apache 2.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It provides no information about side effects, required permissions, data access, or output behavior, leaving the agent uninformed.
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 (one sentence) but lacks structure and substance. It is not rambling, but the brevity works against clarity rather than serving 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 simple schema and no annotations, the description still leaves major gaps: no explanation of what constitutes a 'situation', what a 'stance' looks like, or what the tool returns. It is minimally viable at best.
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?
The schema has one parameter 'situation' with no description, and the tool description does not mention or explain it. With 0% schema coverage, the description fails to add any meaning to the parameter.
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 indicates the tool predicts a stance based on recorded rules and precedent, which is somewhat clear. However, the phrase 'Digital-twin' is jargon and the description does not explicitly differentiate from sibling tools like recall or find.
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 usage guidance is provided. The description does not state when to use this tool over alternatives, nor does it give context or exclusions.
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 available, the description must fully disclose behavior. It reveals that the tool performs a check of certain conditions, but it does not specify the outcome—whether it returns a boolean, a report, or throws an error. Side effects and required context are also omitted.
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 extremely brief, but brevity here results in under-specification rather than conciseness. The information is dense and cryptic, presenting a list of conditions without clear structure or explanatory framing.
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?
With no output schema, no annotations, and cryptic descriptions of what is checked, the description is insufficient for an agent to understand the tool's purpose, expected input, or return value. It needs to explain the check's outcomes or operational context.
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 zero parameters, so the baseline score of 4 applies. The description does not need to explain parameter details, and no parameter ambiguity exists.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description mentions an 'anti-drift check' and lists specific conditions, but it uses highly domain-specific jargon ('cash/trunk frontier', 'open loops') without defining them. It lacks a clear verb+resource structure and does not differentiate from sibling tools like 'system_audit' or 'preflight_action'.
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. The description only states what the check includes, leaving the agent to guess the appropriate context. There is no mention of exclusions or when not to use it.
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 disclosing side effects and return behavior. It hints at output fields (reinject_due, canon_reminder) and mentions 'Security-Recall Divergence', but does not explicitly state whether the tool is read-only, what it returns, or the meaning of 'Safe Turn Depth'. The jargon is not fully explained, and the agent is left unsure about the tool's operational impact.
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 concise (two sentences) and front-loads the core concept, but it is cryptic and dense with jargon ('Safe Turn Depth', 'Security-Recall Divergence'). The structure is acceptable but not as clear as it could be; every sentence adds information, but the wording is indirect and might require external knowledge to understand.
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 and lack of an output schema or annotations, the description is insufficiently complete. It does not clearly enumerate the return values or their types, nor does it provide a concrete explanation of how the agent should interpret the results. The instruction to 're-inject the returned canon_reminder' assumes the agent knows what that is and how to handle it. A more complete description would state the exact output fields and the meaning of the safety measurements.
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 zero parameters, so the schema provides no information. Per the rubric, a baseline of 4 is appropriate. The description does not need to explain parameters, and it does not introduce any confusion about inputs.
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 communicates that this tool relates to long-session safety and tracks interaction count vs Safe Turn Depth, but it lacks a direct verb like 'check' or 'retrieve'. The phrase 'Long-session safety' describes a concept rather than a clear action, making the purpose somewhat vague. It does distinguish itself from siblings by its unique focus, but the intended operation is only implied.
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. The mention of 'Long-session safety' hints at a niche context (long sessions), but there is no 'use this when' or 'instead of' statement. The conditional instruction about reinject_due=true explains how to handle output, not when to invoke the tool. Sibling tools like remember and recall are not referenced.
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?
The description discloses the hybrid retrieval method, which adds behavioral context. However, with no annotations, it does not mention side effects, permissions, rate limits, or return format. For a presumably read-only recall, this is acceptable but not rich.
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, well-structured sentence that efficiently conveys the core functionality without any waste. It earns a top 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?
The description is incomplete for a tool with 3 parameters and no output schema. It omits critical details like the meaning of 'k' (likely number of results), namespace behavior, and expected output format, making it insufficient for confident invocation.
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 description coverage is only 33% (only namespace is described), and the tool description does not explain 'k' or 'namespace' semantics. It mentions 'query' but leaves key parameters ambiguous, failing to compensate for the low 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 identifies the tool as a retrieval operation for memories, using a hybrid approach (keyword + semantic vector). This distinguishes it from siblings like 'find' in method, though it does not explicitly name 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?
No guidance is given on when to use this tool versus siblings such as find, context, or forget. The description only states what the tool does, 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?
With no annotations provided, the description must disclose behavioral traits. It only says it 'flags conflicts,' which hints at output but does not clarify whether the tool blocks the action, returns a detailed report, or has side effects. It also doesn't state if it is read-only or requires special permissions, leaving 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, front-loaded sentence that immediately states the tool's purpose. It is concise with no filler or repetition, earning its place by communicating the core functionality efficiently.
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?
For a simple one-parameter tool, the description covers the core purpose but omits important context like the return format, error behavior, and any prerequisites. Given no output schema and no annotations, the description is only partially complete, leaving the agent to infer how to use and interpret the tool.
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 input schema has only one parameter (proposed_action) with no description, and the tool description does not explain the parameter's format, allowed values, or examples. The description's phrase 'proposed action' maps to the parameter name, adding minimal meaning, but it fails to compensate for the 0% 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 tool checks a proposed action against canon/rules and flags conflicts with non-negotiable rules, which is a specific verb+resource. However, it does not distinguish itself from sibling tools like preflight_action or devils_advocate, so it misses the sibling differentiation component.
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 implies usage: use this tool to validate a proposed action against rules before proceeding. But it gives no explicit guidance on when to use it over alternatives, nor does it mention any exclusions or prerequisites. The usage context is inferred rather than stated.
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?
With no annotations provided, the description carries the full burden. The verb 'Return' implies a non-destructive read operation, and 'ready-to-inject' hints at formatting, but the description does not disclose side effects, whether memories are modified, or the exact output format. This is partially transparent but lacks explicit safety or behavioral details.
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, front-loaded with the action and resource, with no unnecessary words. It is appropriately sized for a simple tool.
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?
The tool is simple (2 params, no output schema), but the description omits details about the return structure (what a 'context block' looks like), the role of 'k', and any edge cases like empty results. Without an output schema or annotations, these omissions leave the description incomplete for understanding the tool's full behavior.
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 input schema lists 'query' and 'k' with no descriptions (0% coverage). The tool description clarifies that 'query' is the basis for selecting relevant memories, but it does not explain 'k', which likely controls the number of memories returned. Without any parameter documentation in the schema, the description only partially compensates.
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 uses a specific verb ('Return') and identifies the resource ('context block of the most relevant memories'), clearly distinguishing it from sibling tools like 'recall' which likely returns raw memories. The addition of 'ready-to-inject' clarifies its purpose further.
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 about when to choose this tool over siblings such as recall or find. The description does not mention any exclusions, alternatives, or prerequisites, leaving the agent to infer when to use it.
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 only states 'Delete', which implies destructiveness but does not disclose potential irreversibility, cascading effects, or permission requirements. The lack of any additional context leaves the agent uninformed about side effects.
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, front-loaded sentence with zero unnecessary words. It earns its place by conveying the action, target, and required parameter efficiently.
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?
For a simple one-parameter delete tool, the description is minimally viable but lacks behavioral details such as what happens to associated data, error behavior, or return value. Without annotations or output schema, more context would be beneficial, but the tool's simplicity keeps this from being severely incomplete.
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 0%, so the description must compensate. The phrase 'by id' clarifies that the single integer parameter is the identifier of the memory to delete, which adds minimal but non-redundant meaning. However, it does not explain the provenance or validation of the id.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Delete') and resource ('memory') with a clear modifier ('by id'). This unambiguously distinguishes it from sibling tools like 'remember' and 'recall', which are creation/retrieval 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?
The description provides no guidance on when to use this tool versus alternatives. It does not mention any exclusions, prerequisites, or context for when deletion should be performed. This is a simple operation, but there is no explicit when/when-not guidance.
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?
The description discloses the one-per-category constraint, but with no annotations, it fails to disclose other behavioral aspects like whether it overwrites existing focus, whether the operation is reversible, or what happens if the constraint is violated.
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 with no unnecessary words. It efficiently includes the key constraint without padding.
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?
With no annotations and no output schema, the description is incomplete for effective use. It fails to explain what 'item' should be, what format it expects, or what the outcome of the operation is beyond setting focus.
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%, and the description does not explain the 'item' parameter at all. It only indirectly clarifies 'kind' via the focus categories, leaving the required 'item' parameter ambiguous.
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 action ('Set') and the resource ('trunk/cash/lab/parked focus') with a specific constraint. This distinguishes it from sibling tools, which deal with memory, context, or other functions.
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 implies usage by stating what the tool does and includes a constraint (1 trunk + 1 cash + 1 lab discipline), but it does not explicitly mention when to use it versus alternatives or any exclusions.
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 must disclose behavior. It indicates the action (recording a delta, next action, proof path) but does not explain side effects, persistence, irreversibility, or any required permissions. The mention of 'irreversible' is a hint but not a full disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the primary action ('Close a session') and provides key details. No filler or redundant information.
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 three parameters, no output schema, and no annotations, the description is sparse. It tells what to record but omits return values, side effects, error conditions, or prerequisites. Given that this tool likely has state-changing behavior (closing a session), more behavioral context 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?
With 0% schema description coverage, the description must add meaning. It maps the three recorded items (delta, next irreversible action, proof artifact path) to the schema's summary, next_action, and proof parameters, but this mapping is implicit and 'delta' is somewhat ambiguous.
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 uses a specific verb 'Close a session' and specifies exactly what the tool records: a delta, the next irreversible action, and a proof artifact path. This clearly differentiates it from sibling tools like 'remember' or 'handoff', 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly states the context for use: when closing a session. It does not explicitly discuss alternatives or exclusions, but the context is unambiguous given the 'Close a session' opening.
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?
With no annotations, the description carries the burden and does disclose the audit scope, optional devil's advocate behavior, and EU-AI-Act-style record output. However, it does not state whether the audit is read-only, what side effects it may have, or what the record format looks like.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences pack the core purpose, parameter behavior, and record style without redundancy. Information is front-loaded and every clause contributes.
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 no output schema and no annotations, the description provides a solid overview but lacks return format details and any usage context relative to doctor/devils_advocate. The EU-AI-Act Article-12 reference is cryptic and may not fully inform an agent of the expected output.
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 schema only provides a boolean with default, and schema coverage is 0%. The description compensates by explaining devil=true behavior ('runs the devil's advocate over every failing finding'), though it leaves the false case implicit.
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 as a full-system audit covering memory inventory and specific invariants (append-only integrity, bi-temporal ordering, canon presence, dangling supersede pointers). It is distinct from memory retrieval/mutation siblings, though it does not explicitly contrast itself with doctor or devils_advocate.
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 implies use for system-level audit and invariant checking but does not state when to prefer it over alternatives or provide exclusions. No explicit when/when-not guidance is given.
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 disclosing behavioral traits. It only lists the return contents and purpose, but does not state whether the operation is read-only, modifies state, requires permissions, or produces side effects. This lack of behavioral context is a notable gap for a tool without annotation support.
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, well-structured sentence that front-loads the action and includes a parenthetical list of contents. Every word contributes value, and there is no redundancy or irrelevant detail.
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?
The tool is simple with no parameters and no output schema, so the description does a good job covering what it returns and why. However, it could be slightly more complete by explaining how these components map to the handoff process or any prerequisites, but it is largely sufficient for the tool's simplicity.
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 zero parameters and the schema is an empty object, giving 100% schema coverage. Per the guidelines, a baseline of 4 applies when there are 0 params. The description does not need to add parameter information since none exist.
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 action ('Return a handoff pack'), defines the resource contents (canon + frontiers + open loops + last checkpoint), and explains the purpose (resume context in a new session/agent). This distinguishes it from sibling tools like 'recall' or 'context' by focusing on a structured pack for handoff.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear use case: 'to resume context in a new session/agent.' It does not explicitly mention alternatives or scenarios where other tools should be used, but the context is sufficient for initial selection. Since no exclusions are given, this fits a 4 rather than 5.
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 full responsibility. It explains the pass-by-reference behavior and pointer structure, but doesn't disclose side effects, permissions, or whether the pointer becomes invalid if the underlying value changes. This is a significant gap for a 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise—one sentence with two clauses—and front-loads the core purpose. However, the cryptic 'A2A courier-tax fix' is extraneous jargon that doesn't help an agent understand the tool's functionality or context.
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?
For a simple tool with two parameters and no output schema, the description covers the basic purpose and return type. But it omits details like error conditions (e.g., nonexistent key), whether the pointer is always valid, and what 'version' refers to, leaving gaps for an agent to safely invoke it.
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 0%, so the description must compensate. It explains that the pointer includes namespace, key, and version, but version is not a parameter in the schema, which may confuse. It doesn't elaborate on the meaning of 'key' or 'namespace' beyond what the schema already shows, adding limited semantic value.
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 it returns a lightweight {namespace,key,version} pointer to a memory value instead of its content. The verb 'get' and resource 'pointer' are specific, and the phrase 'instead of its content' distinguishes it from sibling tools like recall/find that retrieve actual values.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly names alternatives: 'Dereference with recall/find' and notes this tool gets a pointer 'instead of its content.' This provides clear when-to-use guidance and points to the appropriate tool for retrieving content.
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 discloses that it returns a decision with reasons and a rollback plan, enumerating possible decision values. Since there are no annotations, this provides core behavioral transparency, though it doesn't disclose any side effects or authorization requirements. It goes beyond the schema by specifying the output format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with a clear label, immediately conveying the purpose and when to call. No wasted words.
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?
The description covers the decision output and when to call, but lacks parameter details, especially the meaning of 'paths'. It also doesn't clarify what to do with decisions like HOLD or DRY_RUN_ONLY, leaving some scenarios under-specified.
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 no parameter descriptions (0% coverage), and the description only alludes to 'tool/shell command' without explaining the 'tool', 'paths', or 'command' parameters. The 'paths' parameter is entirely unexplained, leaving a significant gap for 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?
The description clearly states this is a governance gate that returns a safety decision before running a tool/shell command, listing specific decision values and including a rollback plan. It distinguishes itself from siblings like 'devils_advocate' by being a preflight safety check rather than a critique or memory tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly tells the agent to call this before any dangerous action, providing clear when-to-use guidance. It doesn't mention alternatives or when not to use, but the context is sufficient for the stated purpose.
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?
With no annotations provided, the description carries the full burden for behavioral disclosure. It states the memory is 'durable' (persistent), which is a useful trait. However, it does not disclose potential side effects (e.g., overwriting existing memories, size limits, or namespace behavior), leaving some uncertainty for a write operation.
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 two short sentences, front-loaded with the core action, and every word earns its place. No fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (3 parameters, no output schema), the description combined with the rich schema provides sufficient context. It explains when to use it and what type of content to store, making it nearly complete for its purpose.
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 schema already provides full coverage of parameter descriptions, including text, tags, and namespace with default and examples. The description adds marginal context by suggesting types of facts to store, but it does not elaborate on parameter usage 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 clearly states the tool's function: 'Store a durable memory.' It specifies the resource (memory) and the verb (store). It also provides examples of content types ('facts about the user, projects, rules, decisions') and implies a distinction from retrieval tools like recall.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use for facts about the user, projects, rules, decisions you should recall later,' giving clear context on when to use the tool. It does not explicitly contrast with alternatives like upsert or forget, but the intended use case is evident.
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?
With no annotations provided, the description carries the full burden for behavioral disclosure. 'List' strongly implies a safe, read-only operation, and the mention of memory counts gives some insight into output. However, it does not openly state that it has no side effects or require any auth, which is a minor gap given the lack of annotation support.
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, information-dense sentence that clearly states the action, target, and output. Every word adds value, with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with no parameters and no output schema. The description sufficiently explains what it does (list namespaces) and what it returns (counts of memories per namespace), making it complete for the agent to use correctly in most contexts.
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 zero parameters, so schema coverage is trivially 100% and the baseline is 4. The description adds no parameter details, but none are needed. The description's mention of 'how many memories each holds' hints at the return value, which indirectly clarifies that no filtering parameters are available.
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 uses a specific verb ('list') and resource ('folder-like namespaces') and adds the additional detail of memory counts, clearly distinguishing it from sibling tools like recall or context that retrieve memories rather than summarize namespaces.
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 clearly implies usage for enumerating namespaces, but does not explicitly state when to prefer it over alternatives or provide exclusion criteria. Given the simple nature of the tool, the intended usage is reasonably inferable but not explicitly documented.
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 discloses the core behavior around optimistic concurrency: success only if version matches, else a conflict is returned. While it doesn't cover edge cases like missing keys or success return format, it provides meaningful behavioral context beyond the schema. With no annotations, this is a solid disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core concept, no wasted words. Every phrase contributes to understanding the tool's purpose and behavior.
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?
The description covers the concurrency mechanism, conflict behavior, and the problem it solves. It does not describe successful return values or edge cases, but given the schema provides parameter defaults and the description is concise, it is reasonably complete for agent 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?
The description explains the meaning of 'key' (the write target) and 'expected_version' (the version that must match current), which is critical. However, 'text' and 'namespace' are left unexplained. With 0% schema description coverage, the description should compensate more fully for all parameters.
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 performs an optimistic-concurrency write by key, with a specific mechanism (succeeds only if current version equals expected_version) and purpose (prevents lost updates). This distinguishes it from sibling tools like 'remember' or 'upsert' by highlighting the concurrency check.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: when multiple agents write the same key and lost updates must be prevented. It does not explicitly mention alternatives or when not to use, but the context is strong enough to guide selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden and discloses key behavioral traits: idempotency, history kept on supersede, and replacement semantics. This goes beyond a simple CRUD statement, though it omits details like return values or failure modes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences, each earning its place: the primary action and idempotency, the conditional behavior, and when to use it. Front-loaded with the key verb and resource, no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 4-parameter tool with no output schema, the description covers purpose, behavior, and usage context well. It could add what happens to tags on update, but overall it provides enough for an agent to select and invoke the tool 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 coverage is 50% (tags and namespace lack descriptions). The description adds meaning by explaining key as a semantic key and (namespace,key) as the identity, which compensates partially. It does not explain the tags parameter, so it is not fully compensating for the coverage gap.
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 uses a specific verb+resource ('Create-or-update a memory by semantic KEY') and clearly distinguishes from sibling tools by noting idempotency and the supersede-or-create behavior. It is immediately clear what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states 'Use for stable values an agent overwrites over time' and gives concrete examples, providing clear context. However, it does not mention alternatives or when not to use it, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full behavioral burden and succeeds: it lists the types of issues flagged (contradictions, superseded facts, missing evidence, canon conflicts, overconfidence, dishonest omissions, irreversible actions) and the exact verdict values returned (STOP/RECONSIDER/PROCEED WITH CAUTION/PROCEED). This goes far beyond what structured fields could provide.
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 three efficient sentences, front-loads the core purpose, and avoids redundancy. Every sentence adds value: what it does, what it returns, and when to call it.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema, the description lists the verdict types and thoroughly describes its behavioral scope. Minor gaps remain, such as what 'canon' refers to and how this relates to sibling tools like preflight_action, but overall it is sufficiently complete for the tool's complexity.
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 description coverage is 0%, so the description must compensate, but it does not. The description mentions 'claim or proposed action,' which maps loosely to the 'claim' and 'action' parameters, but the boolean semantics of 'action' and the purpose of 'namespace' are entirely unexplained. This is a clear gap for a low-coverage schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to challenge a claim or proposed action against memory and canon, enumerating specific checks (contradictions, superseded facts, missing evidence, etc.). It uses a specific verb ('challenge') and distinguishes the tool from sibling memory operations like remember, recall, and preflight_action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Call before consequential moves,' providing clear timing guidance. It implies use when an action could have significant consequences, though it does not name alternative tools or explicitly state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses determinism, current-value semantics, and null behavior. While it does not explicitly state it is read-only, the read nature is clear from 'Exact key lookup' and 'reads back', which is sufficient for a simple lookup tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence with a colon and dash, front-loading the core purpose. Every phrase adds value, with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter read tool, the description is complete: it states the return value, null behavior, and deterministic nature. The reference to upsert provides relationship context, and no output schema is needed for such a straightforward tool.
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 0%, so the description must compensate. It names (namespace,key) and explains that the value is stored under this pair, giving meaning to both parameters. However, it does not elaborate on allowed namespace values or format, leaving some gaps.
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 performs an exact key lookup, specifying it returns the current value under (namespace,key) or null. It explicitly distinguishes itself from fuzzy recall, separating it from sibling tools like recall.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says when to use this tool (deterministic point-read vs fuzzy recall) and identifies it as the complement to upsert ('reads back what upsert wrote'). It explicitly contrasts with 'not fuzzy recall', providing a clear when-not and alternative.
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:

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

Score Badge

Copy to your README.md:

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

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/bitmaster162/continuityos'

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