Zaxy

Server Quality Checklist

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

Latest release: v3.2.0
Disambiguation4/5
Most tools have distinct purposes, but context_assemble and memory_checkout overlap in functionality since checkout wraps assembly. memory_feeling_of_knowing is clearly experimental and distinct. Descriptions guide usage, preventing major confusion.
Naming Consistency2/5
Naming is inconsistent: most tools start with 'memory_', but context_assemble does not. Verbs and nouns are mixed (e.g., memory_append vs memory_capabilities), and context_assemble uses noun_verb order instead of verb_noun.
Tool Count5/5
8 tools is appropriate for a memory management system. Each tool covers a core operation (append, invalidate, query, feedback, capabilities, prediction, assembly), without being excessive or sparse.
Completeness4/5
The tool set covers the memory lifecycle: add (append), retrieve (checkout/query), update (invalidate), feedback, and discovery (capabilities). Missing a dedicated delete tool, but invalidate handles temporal updates. Minor gaps, but core workflows are supported.
Average 3.7/5 across 8 of 8 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- 1 of 2 community issues answered or closed in the last 6 months
- 129 commits in the last 12 weeks
- Last stable release on July 7, 2026
- 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.
This repository includes a glama.json configuration file.
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?
No annotations are provided, so the description must disclose behavioral traits. It mentions assembly of replay and retrieval but does not state whether the tool has side effects, requires authentication, or what happens on error. The mention of 'greedily packed' in the max_tokens schema description is not in the tool description.
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 two sentences, front-loading the core purpose. The second sentence provides useful context about the relationship with memory_checkout. It is concise without waste, but could be slightly more informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, six parameters (only one required), and no annotations, the description is insufficient. It does not explain the return value, the assembly process, parameter interactions, or how this tool differs from the sibling memory_checkout adequately.
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 only 17% (only max_tokens described). The tool description does not explain the parameters (query, session_id, replay_from_seq, limit, max_recent_events, max_tokens) beyond the vague mention of 'replay' and 'ranked retrieval.' It fails to compensate for 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 states the tool's action: 'Assemble replay plus ranked retrieval into a prompt-ready context bundle.' It distinguishes from siblings by mentioning 'memory_checkout, the front door, wraps this assembly,' implying this is a lower-level tool. However, it could be more explicit about the primary function.
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 that context_assemble is used internally or directly when the full wrapping of memory_checkout is not needed. No explicit guidance on when to use vs. alternatives, nor any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the tool 'discovers' information, implying a read-only operation, but does not explicitly confirm no side effects or disclose permissions, rate limits, or any behavioral constraints. Some context is provided but incomplete.
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?
Two sentences with no waste: first lists what the tool does, second gives usage guidance. However, it uses jargon ('ambient usage loop') which slightly impacts clarity. Efficient overall.
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?
No output schema, so the description should describe return values. It mentions discovering capabilities, usage loop, etc., but does not specify the format or structure of the output. Also, parameter effects on output are not explained. Given the complexity (multiple memory siblings), the description provides a starting point but lacks completeness.
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 50%: current_task has a description in schema, session_id does not. The description adds no additional meaning for either parameter; it does not explain how to use session_id or how current_task affects behavior. The description fails to compensate for the gap in 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?
Description uses 'discover' as a specific verb and lists what is discovered (capabilities, usage loop, tool profile, callable tools). It provides a clear purpose and differentiates from siblings by referencing memory_checkout as the front door, though the relationship could be clearer.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises calling 'at session start or whenever tool awareness is unclear,' providing clear context. Mentions memory_checkout as the front door, suggesting a distinction, but does not give explicit when-not-to-use or alternative tools beyond that.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description calls it 'checkout' but does not disclose if it locks state, has side effects, or requires specific authorization. Lacks behavioral context beyond being an entry point.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficient sentences, front-loaded with key purpose, no filler.
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 an 8-parameter tool with no output schema and no annotations, the description is too sparse. It lacks details on output format, parameter usage, and error conditions.
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?
Description does not mention any of the 8 parameters. With 38% schema coverage, it fails to compensate; parameters like session_id, ref, and purpose remain unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'front door' and 'checkout current, cited, prompt-ready memory state'. Distinguishes from siblings by labeling them 'plumbing or power use'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'call this first, before substantial work' and 'Start here', providing clear when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description takes on full behavioral disclosure. It explains the bi-temporal update, history preservation, and that corrections surface in memory_checkout. This provides useful context about the tool's effect. However, it does not mention the need for an admin token or what happens if the entity doesn't exist.
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 concise, containing only two sentences that are front-loaded with the core purpose. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (bi-temporal update with 4 parameters, no output schema), the description explains the core behavior and links to memory_checkout. However, it lacks details on error handling, prerequisites (e.g., entity must exist), and the optional admin_token parameter. It is adequate but has gaps.
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 50%, with only 'invalid_at' and 'admin_token' having descriptions. The tool description adds no extra meaning for the parameters 'entity_name' and 'entity_type', which lack schema descriptions. The description should have compensated for the missing parameter documentation but did not.
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's purpose: 'Mark a fact as invalid at a given time (bi-temporal update).' It identifies the verb 'Mark' and the resource 'fact', and mentions the bi-temporal nature. It references memory_checkout as a related tool where corrections appear, providing some differentiation, but does not explicitly distinguish from other siblings like memory_append or memory_query.
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 for invalidating facts while preserving history, but does not explicitly state when to use this tool versus alternatives. Sibling tools include memory_append (add facts) and memory_query (search), but no guidance on when to choose memory_invalidate over them.
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 behavioral details. It only states that feedback is recorded, but lacks information on updates, side effects, permissions, or the mismatch between described feedback types ('useful, stale, corrected, reinforced') and the actual enum ('used', 'helpful', 'irrelevant').
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, concise and front-loaded. The first sentence states the action, the second provides context. No unnecessary details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 13 parameters and no output schema, the description is insufficient. It does not explain the impact of feedback on future retrievals, how to choose between enum values, or the overall workflow. More context is needed for a comprehensive understanding.
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 descriptions cover all 13 parameters, so baseline is 3. The tool description adds no additional semantics beyond the schema, such as explaining how parameters like 'purpose' or 'outcome' should be used in context.
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: recording feedback on a memory item after using retrieved context. It specifies the possible feedback types (useful, stale, corrected, reinforced) and explicitly ties to sibling memory_checkout, distinguishing it from other tools.
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 indicates the tool should be used after memory_checkout, as it 'closes the loop' on that context. It does not explicitly state when not to use or list alternatives, but the context is clear enough for an agent to infer proper usage.
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 carry the full burden. It does not disclose whether the tool is read-only, requires authentication, or has any side effects. While the name 'query' suggests read-only, the description fails to explicitly state this or any other behavioral traits.
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 extremely concise: one sentence stating the core action, followed by a usage guideline sentence. No wasted words, and the main purpose is front-loaded.
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?
Despite 7 parameters and no output schema, the description explains the tool's role and usage context adequately. However, it lacks behavioral transparency and does not describe return values or pagination behavior in detail, limiting completeness.
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 baseline is 3. The description adds overall context (e.g., 'targeted hits, temporal filters, pagination') but does not add specific parameter details beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Query the temporal knowledge graph for relevant context,' specifying the verb and resource. It distinguishes itself from siblings like memory_checkout by noting it is for targeted hits, temporal filters, or pagination rather than a prompt-ready packet.
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 says 'reach for it when you need targeted hits, temporal filters, or pagination rather than a prompt-ready packet,' providing clear when-to-use guidance and contrasting with an alternative tool (memory_checkout).
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 adds some behavioral context by stating that appended state becomes retrievable, but does not cover idempotency, error handling, or 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?
Two sentences, no wasted words, efficiently communicates core functionality and a key linkage to a sibling tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and moderate complexity, the description covers the essential purpose and retrieval linkage, though it omits details about return value or payload structure guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for each parameter; the tool description adds no additional parameter-level meaning beyond what the schema already provides.
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 appends a typed event to persistent memory, using specific verb and resource, and distinguishes it from the reading tool memory_checkout.
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 implicitly guides usage by noting that appended state is retrievable via memory_checkout, but lacks explicit when-not-to-use or alternative conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It fully discloses behavioral traits: the tool is non-authoritative, cheap (no embedding call or graph query), returns a verdict with breakdown, and its calibration is still being measured. This provides rich transparency beyond what annotations might offer.
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 concise at three sentences, front-loading the key purpose and constraints. Every sentence adds value, with no redundancy or fluff. It is well-structured for quick comprehension.
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?
Although there is no output schema, the description adequately explains the return value (a verdict with signal breakdown and raw score). It covers all necessary aspects for an agent to decide when to use this tool, including its limitations and relation to memory_checkout.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by explaining cues as 'encoding-specificity cue fields' probed alongside query terms, which enriches understanding beyond the schema's 'Optional encoding-specificity cue fields' description. This justifies a slight increase.
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: an experimental metamemory pre-check to predict whether memory_checkout would return something for a query. It uses specific verbs ('predict') and resource ('memory_checkout result'), and distinguishes from sibling tools by emphasizing it is cheap, non-authoritative, and based only on in-memory session state.
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 usage context: use this tool for a quick, cheap prediction about memory_checkout. It explicitly advises 'when in doubt, call memory_checkout', giving a decision rule. However, it does not list specific scenarios where this tool should or should not be used compared to siblings, though the context is implied.
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:

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

Score Badge

Copy to your README.md:

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

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/syndicalt/zaxy'

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