PseudoLife-MCP

Official

by Pseudogiant-xr

Overview Schema Related Servers Score Discussions

Python

Hybrid

Server Quality Checklist

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

Latest release: v0.14.0
Disambiguation3/5
Many tools serve overlapping purposes (e.g., memory_store, memory_fact_set, memory_world_set, memory_supersede, memory_forget) and the differences are subtle, relying on detailed descriptions. An agent could easily misselect between memory_search vs memory_recall, or memory_get vs memory_fact_get, without careful reading.
Naming Consistency4/5
Naming is largely consistent with a memory_ prefix and action-oriented suffixes (get, set, search, store, forget). However, some tools use noun phrases rather than verb_noun forms, such as memory_episode_summary, memory_consolidation_candidates, and memory_session_title, which are minor inconsistencies.
Tool Count2/5
With 35 tools, the server is well above the 25-tool threshold for 'too many'. While the breadth reflects a comprehensive memory system, many tools could be consolidated (e.g., multiple fact-setting and consolidation variants) to reduce cognitive load without losing capability.
Completeness5/5
The tool set covers the full memory lifecycle: acquisition (store, fact_set, world_set), retrieval (search, recent, recall, lesson_search), maintenance (supersede, forget, consolidate, resolve), graph operations, episode tracking, and document indexing. There are no obvious dead ends; every major memory operation is represented.
Average 4.4/5 across 35 of 35 tools scored. Lowest: 3.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1069 commits in the last 12 weeks
- Last stable release on August 20, 2026
- 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

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 that the edge is kept for audit, removed from query results, and can be revived by re-asserting the same triple. This is valuable behavioral context beyond a simple 'retract' action, though it does not address edge cases like non-existent edges.
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 sentences, front-loaded with the core action, and contains no fluff. Every clause adds useful information: retraction, audit marker, removal from results, and revival on re-assertion.
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 core effect and audit behavior are covered, and an output schema exists, so return values need not be described. However, parameter semantics are undocumented, and there is no guidance on usage conditions or error scenarios. For a simple 3-parameter tool, this is adequate but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the three parameters (src, relation, dst). It only refers to 'the same triple' without describing their formats or meaning. The agent must rely solely on the parameter names, which are not fully self-explanatory.
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 'Retract a relation' and clearly states the effect: the edge is marked superseded and removed from memory_graph results. It also distinguishes from siblings like memory_graph_relate and memory_graph by focusing on removal and audit behavior.
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 alternatives. It does not mention exclusions, prerequisites, or compare with memory_supersede or memory_forget. The intended usage is only implied by the verb 'Retract'.
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?
Annotations provide no hints, so the description carries the burden. It discloses that compaction thins chains past ~30 days and that as_of filters versions by time, which is useful behavioral context. It does not mention side effects (likely read-only) or output size limits, but the mention of compaction and merged events adds transparency beyond the bare schema.
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 moderately sized and well-structured: it leads with the mode distinction, follows with the as_of behavior, and ends with the return shape. The backtick formatting around parameter names aids scanning. It could be slightly tighter by dropping redundant clarifications like 'oldest→newest' appearing in both modes, but it stays within reasonable length.
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 output schema is present, and the description specifies the return object shapes for both modes ({entity, attribute, count, versions} and {found, entity, count, events}), so return values are covered. Given the tool's moderate complexity (paging/time filtering, conditional mode), the description covers the essentials: mode selection, chronological order, as_of semantics, and compaction behavior. Missing details like what 'versions' contains or how errors surface are minor for an agent to discover from the output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains attribute (canonical fact slot) and as_of (ISO or epoch, filters versions written by then), but entity is not described beyond the schema typing. The description adds meaning for two of three parameters, which is helpful but not complete for a zero-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 distinguishes two modes (with and without attribute) and states exactly what each returns: the change history of a fact slot with version details such as writer/session, tx/valid time, and age, or the entity's causal chain of dated events. The verb 'change history' and 'causal chain' are specific and differentiate this from siblings like memory_get or memory_recall.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use each mode: use with attribute to see versions of a specific fact, without attribute to see the chain of events leading to a state. It does not explicitly name alternatives or say when not to use this tool, but the mode distinction is clear enough for an agent to infer the right context.
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 transparency burden. It discloses the effect on lookups and that it returns the full alias list, but it does not mention permission requirements, reversibility, or error behavior. The mention of the alias list is a useful 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 three concise sentences, each adding distinct value: action+example, effect, return value. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-param alias binding tool, the description covers purpose, effect, and output. With an output schema present, the return value disclosure is a bonus. It could mention idempotency or duplicate alias handling, but these are minor gaps for this simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no descriptions (0% coverage), but the description maps the parameters through the example: `pg` (alias) and `postgres` (entity). The phrase 'Bind an alternative name to an entity' defines the relationship between the two params, compensating for the schema 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 'Bind' and identifies the resource: an alternative name to an entity. The example `pg → postgres` clarifies the action, and the mention of facts/graph lookups distinguishes it from other memory tools.
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 when to use it (to create an alias for an entity) but gives no explicit guidance on when not to use it or alternatives like memory_supersede. The context is clear via the example, but no exclusions are stated.
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 burden. It reveals that this is a read-only candidate-finding operation ('read the clusters... commit it via memory_consolidate'), and it specifies the return format: `{count, clusters: [{cohesion, size, members}]}`. It also explains the effect of `min_cohesion`. It does not mention any side effects, but the read-only nature is implied clearly.
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 reasonably concise and well-structured, using an 'Args' and 'Returns' breakdown. The first sentence includes a bit of colorful language ('the same thing phrased five ways') but it is not excessive. It conveys the core purpose and usage in a compact form. It loses one point for the slightly informal metaphor that adds little practical information.
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 tool has 8 parameters and no annotations, and the description covers only a few of them. While the central workflow is clear, the unexplained parameters like `top_k`, `max_clusters`, `min_cluster_size`, `tags`, and `sources` could affect results significantly. The return format is provided, but for a tool with this complexity, a bit more parameter context would be needed to be fully complete.
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 `query` and `episode` as anchoring options, and `min_cohesion` with a concrete example ('raise to flag only near-duplicates'). However, it leaves five parameters unexplained (`tags`, `top_k`, `sources`, `max_clusters`, `min_cluster_size`), so the agent cannot fully understand the tool's configurability without additional inference.
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: 'Find clusters of near-duplicate memories ripe for consolidation.' It uses a specific verb ('find'), a clear resource ('clusters of near-duplicate memories'), and differentiates from siblings like memory_consolidate (which actually commits the consolidation) and memory_search (which searches broadly). The purpose is unambiguous.
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 usage pattern: 'Anchor with a `query` (topic-driven) or an `episode` id (session-driven); read the clusters, synthesise one canonical note, then commit it via `memory_consolidate`.' This tells the agent when and how to use the tool and explicitly connects it to the next step. It does not explicitly state when not to use it, but the guidance is sufficient for common scenarios.
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 of explaining side effects. It discloses the reinforcing nature and effect ('helps it resist forgetting') but does not mention whether this is a write operation, whether it is reversible, or any failure modes. The behavioral detail provided is useful 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary action, and every clause adds value. There is no redundancy or filler.
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 simple one-parameter interface and presence of an output schema, the description covers the essential context: what the tool does, when to use it, and the reinforcing effect. It does not explain return values or error cases, but the output schema likely covers the former, and the low complexity makes this acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but there is only one parameter, entry_id, with a clear title. The description implies that entry_id identifies the memory to reinforce by referring to 'one memory' and 'it', but it doesn't explicitly state that entry_id must come from memory_get. The schema type and title carry most of the meaning, but the description adds modest 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 a specific action ('Strengthen one memory') and the resource, with an explicit precondition ('after reading it via memory_get'). It distinguishes this from sibling tools like memory_forget or memory_consolidate by framing it as a deliberate 'this mattered' signal to resist forgetting.
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 gives explicit context for when to use: after reading a memory via memory_get and finding it genuinely useful. The instruction 'Read first, then reinforce' provides a clear precondition, though it does not name alternatives or explicitly state when not to use beyond implying if not useful.
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 full burden. It discloses a key behavioral trait—'audit row kept'—indicating that the operation retains history. It also specifies the return object. However, it does not cover permissions, error cases, or reversibility, which keeps it below a 5.
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 concise sentences plus a return line, with no filler. The main action is front-loaded, making it easy to scan.
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 tool is simple, but with zero schema descriptions, the description is expected to define parameters. It doesn't fully do so, though it covers the core behavior, audit note, and return structure. Gaps remain in parameter semantics and edge-case 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?
Input schema has 0% coverage and no descriptions for entity, attribute, or member. The tool description mentions these fields only in the return object, not their meanings or constraints. It does not compensate for the schema gap beyond the self-explanatory parameter names.
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 'Retract' and identifies the resource as 'set member', which clearly distinguishes it from sibling tools like memory_set_add. It also adds the audit note and points to a complementary read tool, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Read with memory_fact_get' provides a clear usage hint for a complementary read operation, giving context for when to follow up. However, it does not explicitly contrast with memory_set_add or other set operations, so no when-not-to-use guidance is given.
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. It discloses the state transition (closing and popping to session), the return value, and the empty-open edge case. However, it does not mention whether the close is destructive/reversible, any side effects on child data, or permission requirements, leaving some behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no filler. The description is front-loaded with the action and immediately states the result and edge case, making it highly scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with straightforward behavior, the description fully covers the action, result, and empty case. The output schema exists and the description already explains the return value, so no additional context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description does not need to add parameter-level detail; it correctly focuses on behavior and return 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 uses a specific verb ('Close') and resource ('current open episode'), and clearly differentiates from sibling tools like memory_episode_start and memory_episode_summary by stating it ends an episode and pops to its parent. The scope is unambiguous.
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 phrase 'current open episode' implies the tool should be used only when an episode is active, and the note about returning {} when nothing is open clarifies the no-op case. However, it does not explicitly state when to use this instead of other memory tools, nor provide alternatives or preconditions.
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 full burden. It discloses that the tool opens a sub-episode, nests under the session episode, and that memories stored while open carry its id + title, enabling scoped search. It also notes that memory_episode_end pops back to the session. This is meaningful behavioral context, though it doesn't cover potential errors or idempotency.
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 and well-structured: a clear opening statement, a sentence explaining nesting and memory effects, a pointer to the closing tool, and a return format line. Every sentence contributes essential information without 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 that the tool has only two parameters and no annotations, the description covers the core behavior, nesting, memory association, closing mechanism, and return shape. It omits the purpose of the 'hint' parameter, but with an output schema present, the lacking explanation of hint is a minor gap for such a simple 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?
Schema description coverage is 0%, so the description must compensate for parameter meaning. It implies that 'title' is used as the episode name ('named sub-episode'), but it does not explain the 'hint' parameter at all. The description adds minimal value beyond the schema's existence of 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's action: 'Open a named sub-episode for a substantial multi-step task.' It identifies the resource (sub-episode) and its nesting behavior, and distinguishes it from sibling tools like memory_episode_end by explicitly referencing that tool for closing.
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 specifies when to use the tool ('for a substantial multi-step task') and clarifies how it fits into the episode lifecycle ('nests under the auto-managed session episode'). It also mentions memory_episode_end as the counterpart, providing context but not explicit exclusions or alternative tools.
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 and does well: it discloses that matching entries are 'marked superseded', new_text is 'stored fresh', the bank shortens, and the audit trail is preserved. It also lists the return fields. Minor gap: behavior when no matches occur is not clarified.
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 tight and front-loaded: two sentences cover the core action, the matching behavior, the side effect, and the return structure. Every sentence adds value with no filler.
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 effectively covers purpose, behavior, and return values, which is good for a tool with no annotations. It omits clarification of optional params and explicit sibling differentiation, but the overall flow is complete enough for an agent 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?
The description adds meaning to the required parameters: 'replaces' is explained as exact text or close paraphrase matching, and 'new_text' as what is stored fresh. Optional parameters 'tags' and 'source' are left entirely unexplained, which is significant given 0% schema description coverage.
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 opens with a specific verb and resource: 'Replace a cluster of near-duplicate memories with one canonical note.' This clearly distinguishes it from sibling tools like memory_supersede by emphasizing the cluster and the goal of making the bank shorter.
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 provides a clear context for use: when there are near-duplicate memories that should be merged into one canonical note. However, it does not explicitly state when not to use it or compare it to alternatives such as memory_supersede, which would strengthen the 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?
With no annotations, the description carries the full burden of behavioral disclosure. It does add useful non-obvious behavior: 'Returns {found: false} for an unknown id'. However, it does not explicitly state whether the operation is read-only or if any side effects occur, which is a meaningful gap for a tool with no annotation safety hints.
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 sentences and every part earns its place: the summary content, the real-world phrase, the source of ids, and the not-found return. It is front-loaded with the main action and avoids redundant filler, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with an output schema, the description covers the core aspects: what is returned, how to obtain the parameter, and an edge case. It does not explain terms like 'tag/source distribution', but the output schema can handle return details, so the description is complete enough for selection and correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the schema has no description for the 'id' parameter (0% coverage), the description compensates by indicating the id refers to an episode and by specifying where to find episode ids ('Episode ids appear on search/recent results'). This gives the agent enough semantic grounding to supply the correct 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 a specific verb and resource: provides 'Stats, tag/source distribution, and recent entries for one episode'. It immediately distinguishes from siblings by focusing on episode-level summaries rather than global stats or individual records, and the quoted user intent 'summarise what we worked on' makes the purpose unmistakable.
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 gives clear usage context: use when you need a summary of a specific episode, and it explicitly explains how to obtain the required id ('Episode ids appear on search/recent results'). It does not explicitly name alternatives or exclusions, but the context is sufficient for an agent to infer when this tool is appropriate.
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 a notable behavioral trait: transitive/inverse edges are pre-derived with 'derived: true' and rule provenance. It also states the return structure. Since it says 'Read', it implies read-only behavior, though it doesn't explicitly mention absence of 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 concise and well-structured, with a clear opening sentence, a compact Args section, and a Returns summary. Every sentence contributes useful information without unnecessary verbosity.
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 purpose, most parameters, and return format. The omission of include_facts is a notable gap, but the existence of an output schema mitigates the need for detailed return field explanations. Overall, it provides enough context for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, requiring the description to explain parameters. It adequately explains depth, to, and relation_filter, but omits include_facts entirely. The required entity parameter is implicit but not described. This partial coverage leaves a clear 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 clearly states the tool reads an entity's graph neighborhood, specifying the verb 'Read' and the resource (graph neighborhood). It distinguishes itself from sibling write tools like memory_graph_relate/unrelate by focusing on reading, and the mention of nodes, edges, and facts adds specificity.
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 on what the tool does (reads graph neighborhoods) and offers parameter-specific usage guidance (e.g., 'Pass `to` for the shortest path', 'relation_filter keeps only...'). However, it does not explicitly mention alternatives or exclusions, though the read-only nature implies usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses key behavioral traits: similarity-based retrieval, polarities with known dead-ends, verbose toggle for full provenance, and compact default entries. Also specifies return fields. This is strong but not exhaustive (e.g., no error behavior or rate limits).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is three short sentences, front-loaded with purpose, then usage guidance, then return format. No fluff or redundant repetition, every sentence earns its place.
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 purpose, when to use, polarity caveat, verbose behavior, and return shape. With only 3 parameters and an output schema present, this is nearly complete. It could add more on top_k behavior or similarity mechanics, but overall strong.
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 verbose meaningfully ('verbose=True for full provenance metadata, default entries are compact'), but query and top_k remain self-explanatory from their names and defaults without additional semantic detail. Partial compensation.
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 specific action 'Search learned lessons (procedural memory) by similarity to the task at hand', distinguishing it from sibling memory tools that deal with facts, episodes, or storage. The verb 'search' and resource 'learned lessons' are precise and useful.
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 instructs to call at the START of a task and warns to heed negative polarity entries as dead-ends. However, it doesn't mention when not to use this tool or provide explicit alternatives, so it lacks exclusion criteria.
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 must carry the safety/behavior burden. It implies a pure read operation by describing 'vital signs' and statistics, but it never explicitly states that the tool does not modify memory. The listed metrics do add useful behavioral context about what the call reports.
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 compact and well-structured: a front-loaded summary label, the specific metrics, then two concrete use cases. Every sentence earns its place and there is no redundant filler.
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 no-parameter, output-schema-backed diagnostic stat list, the description covers the main invocation purposes and the categories of returned information. Additional details like time window or persistence would be nice, but the output schema can supply those where needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the input schema leaves nothing to explain. The baseline for no parameters is 4, and the description appropriately emphasizes what the response/statistics reveal rather than parameters that do not 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 defines the tool as a memory-bank statistics reader: it lists the exact metrics returned (occupancy vs capacity, hit rates, true-drop count, totals). This distinguishes it from content-focused siblings like memory_search or memory_get and states the diagnostic role rather than simply restating the name.
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 gives explicit use cases: 'gauge how much has been remembered' and 'diagnose why retrieval feels off.' It does not name alternative tools or say when not to use it, but the context is clear enough for an agent to select this tool over the sibling lookup/management tools.
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 must carry the behavioral disclosure burden. It explicitly reveals a key behavioral trait: the tool only searches ingested documents excluding conversational memories. This is valuable, but it does not mention other behavioral aspects like ranking criteria, pagination, or potential staleness. Given its brevity, it does disclose the most critical scope constraint.
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 concise sentences. The first delivers the core purpose and scope; the second gives a clear pointer to an alternative. Every word earns its place, with no redundancy or filler.
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 (search with query, optional top_k) and the presence of an output schema, the description provides essential context: the scope of the search and the alternative for broader memory search. However, it lacks any elaboration on result handling or limitations, which would be beneficial but is not strictly required given the output schema exists.
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%, and the description provides zero information about the 'query' or 'top_k' parameters beyond what the schema already shows in parameter names. The description does not compensate for the lack of parameter documentation, leaving top_k's purpose and behavior 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?
The description clearly states the tool's action ('Search the reference bank only') and scope ('ingested documents, no conversational memories mixed in'). It distinguishes itself from memory_search in the same sentence, which fully clarifies its specific purpose relative to siblings.
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 when to use this tool (searching the reference bank only) and explicitly names the alternative (memory_search) for combined docs and memories. This provides clear decision guidance beyond any other context.
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 the full burden of behavioral disclosure. It does this thoroughly: explains that entities auto-create and resolve through aliases, re-assertion bumps confidence, separator variants normalize, and unknown relations are rejected with suggestions. These are significant side effects and error behaviors that are not apparent from the schema alone.
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 dense and well-structured, with three distinct parts: purpose and example, behavioral details, and registry/error handling. Each sentence contributes useful information, though it is longer than strictly necessary. The inclusion of the return format at the end is helpful without being redundant.
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 graph mutation tool with no annotations and 0% schema parameter coverage, this description covers the essential operational context: relation constraints, side effects, error handling, and return values. It misses explicit explanations of optional parameters and the exact content of `warnings`, but overall provides enough information for an agent to use the tool correctly. The presence of a textual output schema reduces the need to describe return values further.
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 description coverage is 0%, so the description must compensate. It explains the core parameters (src, relation, dst) via the example `(web-app, runs-on, host-1)` and the relation registry, and mentions `confidence` in the context of bumping confidence. However, it does not clarify `origin`, `src_type`, `dst_type`, or how the `confidence` parameter affects initial assertion, leaving a gap for these optional fields.
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: "Assert a typed relation between two entities" with a concrete example. It distinguishes itself from related tools by mentioning the closed relation registry and the alternative `memory_relation_define` for growing vocabulary, making its role unambiguous.
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 useful guidance on when to use this tool: it handles relations from a closed registry, offers fallbacks for unknown relation names, and directs users to `memory_relation_define` for new relation types. However, it doesn't explicitly compare against graph-related siblings like `memory_graph_unrelate` or `memory_graph`, so the usage context is clear but not fully exhaustive.
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 key behavior: idempotency (call again to rename) and the fact that default titles are generic. It does not mention side effects or error conditions, but for a naming tool, these are the most important traits and are covered.
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, front-loaded with the main purpose, and every sentence adds value. It includes usage timing, examples, and a behavioral note without wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with an output schema, the description covers all essential aspects: what it does, when to call it, and its idempotent nature. The context is sufficient 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?
The schema has 0% description coverage, so the description must compensate. It provides examples of valid titles (e.g., 'Pseudolife-MCP', 'auth-refactor') and implies the parameter is a string, but does not explicitly describe the parameter or constraints. The examples add some meaning beyond the schema, but the coverage is minimal.
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: naming the session's auto-opened episode. It uses a specific verb ('Name') and resource ('THIS session's auto-opened episode'), and distinguishes the tool from siblings by focusing on session naming and recaps. The examples further clarify the intended use.
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 to call it once at the start of work and provides examples, giving clear timing and context. It does not mention when not to use it or alternatives, but those are less critical given the tool's specific purpose and simplicity.
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, the description carries the full burden and does so thoroughly. It explains the two branches (accept=true adopts, old value kept as history; accept=false discards the contender), and discloses the return format including the failure case (resolved:false, reason:'no_contender'). This goes beyond minimal requirements and clarifies 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 focused sentences that front-load the purpose and then detail the decision branches and return values. Every sentence adds necessary information with no redundancy. Markdown formatting for booleans and return structure improves readability.
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 provides all essential invocation details: the action (settle), the decision parameter (accept), and return values for both success and failure. It does not explicitly describe what a 'contender' is, but that is an internal concept. Overall, it is sufficient for an agent to understand the tool's operation without missing critical information.
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 0%, so the description must compensate. It explains the semantics of the accept parameter (true/false behavior) but does not elaborate on entity or attribute. These are implicitly understood as the fact identifier, but the description does not explicitly define them, leaving a partial 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?
Description uses a specific verb+resource: 'Settle a CONTESTED fact slot'. It clearly differentiates from siblings like memory_fact_set (sets a fact) and memory_supersede (replaces) by focusing on contest resolution, not just setting or superseding a value.
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?
Provides clear context: use when there is a contested fact slot and after 'checking with the human'. However, it does not explicitly mention when not to use this tool or compare it to alternatives, such as memory_fact_set or memory_consolidate. No exclusions are stated, but the context is unambiguous.
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 full burden. It discloses side effects for each action: 'writes the relation edge', 'dismisses the pair', 'deletes an over-extraction artifact', 'fold a near-duplicate into its twin'. It also specifies return behavior ('per-action dict; {error} on bad input') and mentions batch triage with proposal_ids. While it does not discuss permissions or reversibility, the level of disclosure is above average for a multi-action 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 appropriately sized for a tool with 10 distinct actions. It front-loads the purpose in one sentence, then uses a clean bulleted list to enumerate actions, each on a single line with clear wording. The 'Returns' line at the end is concise. No filler or repetition; every sentence earns its place, making it easy to scan.
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 complexity (10 actions, 9 parameters) and the presence of an output schema (noted in context), the description covers the main behaviors and parameter requirements. It explains the propose format, slot pair keys, batch triage, and returns. It does not detail all edge cases or error handling, but the output schema likely covers return structures. The description is sufficient for an agent to understand what each action does and how to invoke them.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains several parameters: 'scope' filters in list, 'proposals' format with a full object shape, 'store' with key format for slot pairs, 'proposal_ids' for batch triage, and 'relation' implied in the relate action. It does not explicitly define 'src', 'dst', 'proposal_id', or 'store' meaning beyond action context, but the action list gives enough inference. This is better than most zero-coverage tools but not exhaustive.
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 opens with a clear statement of purpose: 'Work the graph review queue — deep-dream proposals that need a verdict before they touch the graph.' It distinguishes itself from sibling tools by focusing on review/verdict actions (accept/reject/dismiss/relate) rather than creating or reading entities directly. The action list makes the resource and its scope unambiguous.
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 makes the tool's context explicit ('review queue') and lists specific actions for different verdict types. It clearly implies that this is the tool for triaging proposals and link/slot pairs. However, it does not explicitly name alternatives or state when not to use it (e.g., for direct graph manipulation use memory_graph_relate). The lack of explicit exclusions prevents a 5, but the context is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description fully carries the behavioral disclosure burden. It reveals important traits: URL scheme validation ('any other scheme is rejected'), freshness_class setting trust decay at read time, supersession behavior ('A newer source supersedes an older value at the same slot'), and the returned action set. It could go further on edge cases like missing source_url or auth, but it is notably transparent.
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 well-structured: purpose first, then usage guidance, then a compact Args list, and finally the return shape. Every sentence adds substantive value without redundancy, and the format is front-loaded with the most important information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 9 parameters and no annotations, the description is quite complete. It covers the tool's purpose, routing, parameter semantics, and return values (also aided by an output schema). Key behaviors like supersession and trust decay are explained. The main gaps are explicit definitions for required parameters and the optionality of citation fields, but overall it provides a strong operational picture.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description's Args section is critical. It explains source_url's http(s) requirement, source_quote length, freshness_class enum meanings, confidence bounds, and the optional retrieved_at/content_hash pair. However, it does not explicitly describe the required parameters entity, attribute, and value, leaving them to inference from the schema titles.
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 asserts a canonical WORLD fact sourced from external knowledge, with examples (versions, prices, who-holds-a-role, research findings). It explicitly distinguishes this from user/project facts, which differentiates it from sibling tools like memory_fact_set. The verb 'Assert' plus 'WORLD fact' is specific and action-oriented.
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 gives clear context for when to use this tool: 'Route verified web/docs findings here' and 'kept separate from user/project facts.' This implies the alternative use of user/project fact tools, though it does not name a specific sibling. It also notes that a newer source supersedes an older value, which is a key usage rule.
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 full burden. It discloses the indexing behavior, the separate reference bank, the cosine similarity retrieval, source defaulting to filename, server-side path resolution with the Docker caveat, and the return format. It does not explicitly state that it is a write operation, but 'index' implies mutation. Overall, good transparency for a tool with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured. It covers what, where, parameter semantics, a critical environment caveat, and the return value in a few sentences. Every sentence provides value, with no redundancy or filler.
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 is largely complete for a two-parameter tool, covering purpose, parameter details, environment constraints, and return values. It lacks explicit mention of error conditions or prerequisites (e.g., file existence, permission requirements), which would make it fully complete. Given no annotations and an output schema that likely specifies the return, the description handles the main context well but leaves a few edge cases unaddressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does so effectively: 'source defaults to the filename' clarifies the optional parameter, and 'path resolves on the SERVER's filesystem' with the Docker note explains the required parameter. The supported file types also add meaning to 'path'. This is excellent parameter-level guidance.
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: 'Index a file (.txt / .md / .pdf) into the reference bank.' It specifies the resource (files), the action (index), and the destination (reference bank), and distinguishes it from conversational memory tools. This is a specific and unambiguous purpose.
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 on when to use it: for background documents (papers, manuals, codebases) kept apart from conversational memory. It implies that for conversational memory, other tools should be used, but it does not explicitly name an alternative. The Docker path caveat offers practical usage guidance, but explicit 'when not to use' is absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It discloses the Postgres dependency, the polarity inference behavior ('usually omit (inferred)'), and the downstream effect on Dream. It does not cover failure modes or auth, but it adequately explains the core behavioral traits for a recording 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 tightly organized: a one-sentence purpose, a rationale, a structured Args list, and a Returns line. Each sentence earns its place, and the format is easy to scan. It avoids redundant explanations while covering necessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 6-parameter complexity and zero annotations, the description covers all relevant aspects: purpose, parameter meanings, return value shape, and the Postgres requirement. The output schema is also reflected in the Returns section, making the tool self-contained for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the Args section explains every parameter with concrete examples and semantics. It defines the outcome enum, clarifies polarity as optional and inferred, and explains 'about' aids traversal. This fully compensates for the bare schema and adds meaning well beyond the field names.
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 opens with a specific verb and resource: 'Record a procedural outcome — what worked, failed, or was corrected.' This immediately distinguishes the tool from generic store/set tools by focusing on outcome logging. The example 'deploy engine to host' further clarifies the intended scope.
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: use this to log procedural outcomes so that 'Dream synthesises signals into lessons surfaced next session' and 'logging stops repeated mistakes.' While it doesn't explicitly name alternative tools, the purpose is well-scoped enough that an agent can infer when it is appropriate compared to sibling memory tools.
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 the full burden and delivers well. It states the operation is read-only, explains the low_confidence behavior, describes the default fact/edge shapes, and summarizes the return payload. This is substantial behavioral context beyond the schema.
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 front-loaded with the core purpose, then expands into usage guidance, fallback behavior, parameter details, and return structure. Every sentence contributes distinct value, and the structured Args/Returns layout is easy to scan without being bloated.
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 complex (graph multi-hop retrieval) with no annotations, but the description covers purpose, usage, safety (read-only), fallback behavior, parameter semantics for most params, and return values. The only clear gap is the semantics of top_k, but overall this is nearly complete for an agent to invoke 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 0%, so the description must compensate. It adds meaning for 'hops' (max 5, graph links) and 'verbose' (full provenance with explicit shape), and implicitly for 'query' via seed entity. However, 'top_k' is not explained at all, leaving one of four parameters without added semantics.
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 names the tool as 'Multi-hop retrieval over the knowledge graph' and specifies the exact use case: RELATIONAL questions answered by following links, with concrete examples. It explicitly distinguishes itself from sibling tool memory_search by noting what it can chain that single-shot search cannot.
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?
It provides explicit when-to-use guidance ('for RELATIONAL questions whose answer is reached by following links') and an explicit fallback rule: if low_confidence is true, no seed entity matched, so fall back to memory_search. This clearly frames the tool relative to its alternative.
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: timestamp ordering, compact vs. verbose output, AND-combined filtering, and optionality of filters. It does not mention edge cases like empty results or max N, but the disclosed behavior goes well beyond a bare list.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tightly written sentences front-load the main action and ordering, followed by use cases and parameter guidance. Every sentence adds value with no repetition or 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 listing tool with no required parameters, the description covers ordering, filters, verbosity, and use cases. An output schema exists, so return-format details are structured elsewhere. The description is complete 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.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description explicitly explains every parameter: 'N' for n, the filter names and AND-combination for sources/episodes/tags, and 'verbose=True for full per-entry metadata' for verbose. This fully compensates for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List'), names the resource ('memories'), and clarifies the ordering ('newest first — timestamp order, not relevance'), which directly distinguishes it from relevance-based search tools like memory_search and memory_recall. This is a clear, non-tautological statement of purpose.
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 provides concrete use cases ('what did I just store?', 'catching up at the start of a session') and implicitly excludes relevance-based retrieval with 'not relevance.' However, it does not explicitly name alternative tools or provide a 'when not to use' statement, so it stops short of full alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden, and it delivers: it explains ordering of cortex vs entries, deduping behavior, contested facts routing to memory_fact_resolve, low-confidence semantics, superseded entry handling, temporal events, and even cost implications of rerank. This is unusually rich behavioral 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 dense but well-organized: a short behavioral intro followed by a parameter list that maps cleanly to the schema. Every sentence adds information, and the most important guidance is front-loaded before the detailed argument list.
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 12-parameter tool with no annotations, this description is remarkably complete. It covers invocation context, behavioral edge cases, parameter semantics, output structure, and even default values. The rich output schema exists, but the description independently provides the behavioral context needed to call the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description compensates fully by explaining every parameter's meaning and nuances: filter semantics (AND/OR), min_score's role as a relevance floor, tri-state behavior for rerank/bm25, explain implying verbose, and the default compact output shape. This exceeds what the raw schema gives the agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action ('Retrieve memories for a query') and resource ('memories'), and adds the notion of 'associative recall plus canonical facts,' which meaningfully distinguishes it from generic retrieval. However, it does not explicitly name or differentiate itself from sibling tools like memory_recall, memory_get, or memory_history, so it falls short of a 5.
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?
'Call at task start or when context may apply' is clear, actionable guidance for when to use the tool. It does not explicitly state when not to use it or name alternative tools, so it lacks the exclusions needed for a 5, but the context is well-defined.
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 itself reveals key behaviors: near-duplicates are dropped with 'stored=False, reason="below_surprise_threshold"', and the return object includes 'stored, surprise, reason, cortex_promoted'. This goes beyond the basic 'store' semantics. However, it does not explain the meaning of 'surprise' or 'cortex_promoted', nor any side effects beyond persistence, so it stops short of complete 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 well-organized: a one-line purpose, then usage rationale, then duplicate-handling detail, a pointer to an alternative, a compact Args block, and Returns. Every sentence carries distinct information, with no filler 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 moderate complexity (5 params, no annotations), the description covers the main usage scenarios, return format, and duplicate behavior. It does not explain the semantics of 'surprise' or 'cortex_promoted', which an agent might need to fully interpret the result, but the overall guidance is sufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must carry the parameter meaning. It does: each argument (text, source, tags, origin, episode) gets a concise purpose, e.g., 'source: Stable per-project/topic tag for later filtering.' This is a strong compensation. It misses noting schema defaults (e.g., source defaults to 'agent'), but the core semantics are provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Store one durable fact, decision, or observation', which is a specific verb+resource statement. It clearly distinguishes the tool from siblings by explicitly pointing to 'memory_fact_set' as the canonical alternative for NOW facts, and by noting near-duplicate handling as a unique behavior.
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 states when to use the tool: 'Use proactively for anything worth keeping — one claim per call.' It also names an alternative: 'For canonical NOW use memory_fact_set.' This gives clear when/alternative guidance, satisfying the criterion fully.
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 responsibility for behavioral disclosure. It richly explains the write behavior: history is kept, new values supersede old, conflicting writes are parked as contenders with action='contested', winner under 'current', and suggests human check and settlement via memory_fact_resolve. It also discloses defaults for optional parameters and the return shape. This goes well beyond what the schema reveals.
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 structured with a clear title line, a concise behavior summary, a compact args reference, and a returns line. Every sentence adds unique value: conflict handling, parameter defaults, and output format are all covered without fluff. It packs substantial information into a small space, making it easy for an agent to scan and apply.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (7 params, 3 required, conflict behavior, output schema), the description is remarkably complete. It covers the action's purpose, conflict semantics, parameter meanings, defaults, and return values. It also cross-references a related tool for conflict resolution, which helps the agent understand next steps. No critical information appears missing for safe and correct use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaning for origin ('user' vs 'action'/'agent'), confidence (0..1 default 0.8), episode (attribution handle), and freshness_class ('auto' infers decay). However, it does not explicitly define the required parameters entity, attribute, and value, though they are implied by 'slot' and the tool's purpose. Overall, it provides meaningful semantics for several parameters but leaves some required ones implicit.
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 opens with a specific verb and resource: 'Assert a canonical fact — insert, confirm, or correct a slot.' It clearly distinguishes itself from reading tools (memory_fact_get) and resolution tools (memory_fact_resolve) by explaining the write/update semantics with conflict handling. This leaves no ambiguity about 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?
The description provides clear behavioral context, such as how new values supersede old ones and how conflicting writes become contenders requiring human check, then points to memory_fact_resolve for settlement. It does not explicitly name alternatives like memory_store, but the conflict-resolution guidance implies when this tool is appropriate. The inclusion of default values for origin, confidence, and freshness_class further aids invocation.
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 fully carries the burden of disclosing behavior. It reveals a side effect ('Reading it gently reinforces it') and the failure mode ('Returns {found: false, faded: true} when the episode has since been forgotten'), which are important behavioral traits not inferable from the tool name or schema.
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 sentences, front-loaded with the core action, and includes the return contract. Every clause adds value: source of the id, what is returned, side effect, and forgotten behavior. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with an output schema, the description is complete. It covers what the tool does, how the parameter is meant to be used, a notable side effect, and the behavior when the episode is missing. The output schema can handle detailed return field documentation, so no further description is necessary.
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 has only a parameter name ('entry_id') with no description, so the description must compensate. It explains that entry_id is a memory id and specifies where it comes from, providing meaningful semantic context despite not detailing the exact format or value constraints.
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: dereferencing a memory id to retrieve the full stored episode plus consolidated_into. It specifies the source of the id (search results or a fact's source_entries), making it distinct from sibling tools like memory_fact_get or memory_search.
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 implies when to use the tool: when you have a memory id from search results or a fact's source_entries. It does not explicitly mention when not to use it or name alternatives, but the context is clear and specific enough for correct selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the operation is deliberate and rare, supports transitive closure and inverse pairing, and that type expectations are soft (warn but never reject), which goes beyond simple purpose and gives important 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 two focused sentences, front-loads the core purpose, and includes examples and constraints without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and the presence of an output schema, the description covers purpose, usage guidance, key behavioral traits, and parameter semantics enough for an agent to select and invoke it correctly. It also differentiates from siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaning for transitive, inverse_of, src_type, and dst_type, clarifying their roles and the soft-mismatch behavior, though it does not fully enumerate syntax or types for all six 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's action ('Add a relation to the closed graph vocabulary') and identifies it as a deliberate, rare act, distinguishing it from sibling tools like memory_graph_relate which likely relate existing entities rather than define new relation types.
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?
It explicitly advises preferring builtins and defines when to use this tool ('only when a recurring connection genuinely fits none of them'), offering clear when-not guidance and an alternative approach.
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, the description carries the full burden, and it delivers: it discloses that the old entry is kept but flagged superseded, that retrieval ranks the correction higher and shows both together, and explains the exact matching algorithm (exact-text first, embedding fallback). This is thorough and transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences: purpose, behavior, and return value. Front-loaded with the main action, no redundant words, and each sentence earns its place. Excellent conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and only 2 simple parameters, the description covers the essential operational details: how matching works, what happens to the old memory, and what the return object contains. It is complete for this tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions are empty (0% coverage), but the description clarifies old_text semantics by noting that 'a close paraphrase of old_text works,' and new_text is clearly implied as the replacement. It could be more explicit in naming both parameters, but the context makes the meanings clear enough.
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 core function: 'Mark a stored memory obsolete and record its replacement.' This distinguishes it from siblings like memory_store (which stores new memories) and memory_forget (which removes memories). The verb 'supersede' is specific and the description explains the intended effect on retrieval.
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 implies when to use this tool (to correct/update an existing memory) and describes the matching process, providing clear context. However, it does not explicitly name alternatives or state when not to use it, so it stops short of a full 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?
No annotations exist, so the description carries the full behavioral burden. It discloses identity scoping ('scoped to your credential/writer identity'), cost and latency ('free, instant'), and the operational consequence of hidden tools ('clients reject hidden-tool calls'). It also specifies exactly which capability groups each tier unlocks.
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 dense sentences front-load the purpose and then add only high-value details: tier contents, status behavior, and expansion warning. There is no filler or redundant restatement of the schema.
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 one-action tool with an output schema, this description is complete. It defines the tier model, the three action semantics, identity scoping, and the operational warning about hidden-tool calls. An agent can decide to expand, collapse, or check status without needing further documentation.
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 has one enum parameter with 0% description coverage, so the description compensates by explaining 'expand' (move up the ladder) and 'status' ('reports the ladder'). 'Collapse' is left to inference from 'one tier at a time' and the minimal→core→full ordering, but the word and direction make it sufficiently clear.
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?
States the exact verb and resource: 'Adjust YOUR visible toolset, one tier at a time.' It enumerates tier contents and actions, making clear this is a toolset-management tool, not a memory-content operation like any sibling memory_* or document_* tool. The purpose is unambiguous and distinct.
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?
Provides an explicit precondition: 'Expand first: clients reject hidden-tool calls,' which tells the agent when to use this tool. It also explains that 'status reports the ladder' as a diagnostic use. It doesn't explicitly state when to collapse or name alternative tools, but no sibling tool is a substitute, so the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries transparency. It discloses that entries carry age-decayed effective_confidence, a stale flag, source_url and source_quote for citation, and explains the verbose=True behavior for full provenance metadata. It also gives the return structure. This is rich behavioral context beyond the schema.
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 and well-structured: purpose first, then usage guidance, then result fields and parameter behavior, and finally the return type. Every sentence adds value with no redundancy or 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 search tool with an output schema, the description is complete. It covers what the tool does, when to use it, what the results contain, and how to get more detail. It also differentiates itself from memory_search and other siblings on the WORLD fact domain, making it self-sufficient.
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 0%, so the description must compensate. It adds meaningful semantics to 'verbose' by explaining that verbose=True returns full provenance metadata and default entries are compact. Query and top_k are self-explanatory from their names and the search context, though not explicitly detailed. This is decent compensation for a 0%-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 uses a specific verb ('Search') and resource ('current WORLD facts (sourced external knowledge)') with a clear scope ('by similarity'). It distinguishes from sibling tools like memory_search and document_search by emphasizing external knowledge and the WORLD fact domain.
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 when to use the tool: 'Use when a task turns on an external fact your training data may have stale.' It provides contextual guidance about re-verifying stale entries but does not explicitly mention when not to use it or name alternatives.
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, the description carries the full burden and succeeds. It discloses that status is read-only, deep is dry-run unless apply=true and snapshots graph tables first, pull writes facts and commits cursors, rollback reverts facts and events but preserves traces/cursor, and responses are per-action dicts with {error} on bad input.
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 structured as a short purpose line plus per-action bullets, with each line earning its place. It packs substantial semantics into compact wording without unnecessary repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given six parameters, seven sub-actions, no annotations, and broad sibling context, the description covers all actions, all side effects, the main workflow patterns, and the error/return convention. Nothing critical an agent needs to call or chain this tool is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description documents every parameter in context: limit bounds pulls, cursor is the newest pulled timestamp for commit, apply controls deep's dry-run, snippets controls evidence inclusion, and run_id targets a rollback pass. This fully compensates for the empty schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a clear resource (memories undergoing consolidation) and gives each sub-action a concrete verb and object: status, pull, run, deep, runs, rollback. It differentiates manual pull-and-commit flow from server-side run and full-corpus deep, so an agent can tell this apart from sibling tools like memory_consolidate or memory_graph_review.
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 gives usage context for every action and names downstream tools to call: memory_fact_set for writing facts, memory_graph_review for settling candidates. It lacks explicit when-not-to-use statements against siblings, but the action workflows effectively tell an agent how to orchestrate the dream process.
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?
Even with no annotations, the description discloses critical behaviors: case/separator-insensitivity, null meaning, set-valued slot representation, return shape (record, contenders, entity_ref), and semantics of 'candidates' as leads not answers. This is highly transparent for a getter.
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 dense but efficient: main purpose first, then set-valued exception, then return semantics. Every sentence contributes new information with no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, the description still goes beyond it by clarifying edge cases and return semantics. It covers null vs empty, set values, conflicts, and nearby slots, making it complete for an AI agent to decide when and how to invoke.
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 0%, so the description adds meaning by explaining that entity and attribute form a slot and are case/separator-insensitive. It doesn't give explicit format examples but provides enough context for the two string 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 opens with a specific verb and resource: 'Look up the one CURRENT value at an (entity, attribute) slot.' It clearly scopes the action and distinguishes it from nearby tools by contrasting with memory_search and memory_fact_resolve.
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 directs when to use alternatives: memory_search for context, memory_fact_resolve for unresolved conflicts. Also clarifies that a null record means EMPTY, not unknown, which guides the agent to search elsewhere when needed.
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, the description carries full burden and does so: it discloses one-way scalar-to-set conversion, protection for number-led scalars, and the contested action state. It also names the settle path (memory_fact_resolve), adding value beyond schema.
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 text is compact and front-loaded; the first sentence states purpose and key characteristic, and the second paragraph provides the return signature. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema and no annotations, but the description covers behavioral traits, edge cases, and related tools. It includes the return object shape and gives enough context for an agent to decide when to invoke it.
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 0% and params are just strings; the description explains 'member' in relation to set-valued slots, 'entity/attribute' context is implicit, and it distinguishes normal members from contested numerical ones. It would benefit from explicit formats for entity and attribute, but it compensates adequately for a 3-param tool.
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 opens with a specific verb ('Add/confirm') and identifies the resource ('set-valued slot'), clarifying that it is not for scalar NOW values. It also distinguishes from sibling memory_set_remove and memory_fact_get by mentioning read and resolve alternatives.
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?
It states the tool is for set-valued slots with many concurrent values, and explicitly directs readers to memory_fact_get for reading and memory_fact_resolve for contested settlements. It also warns about scalar conversion and number-led exceptions, giving clear when-to-use context.
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, the description fully discloses destructive behavior: 'Hard-delete', 'no audit trail', and 'ANY match deletes' for OR-combined filters. It explains edge cases like omitting attribute to purge the whole entity, and reports error behavior. This exceeds typical transparency for a destructive 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 well-structured with a short intro, explicit alternatives, and a scoped bullet list. Every sentence adds necessary information for a destructive multi-scope tool; there is no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (8 parameters, 4 scopes, destructive operation, no annotations), the description covers all key aspects: scope-specific filters, required parameters, alternative tools, return shape, and error behavior. The output schema exists, so return details are further supported, but the description already provides ample context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description compensates thoroughly. It explains every parameter's role within each scope: text/substring/source/episode/tag for memory, entity/attribute for fact/world/lesson, and the lesson mapping ('pass the task as entity'). This adds meaning far beyond the bare 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 opens with a specific verb+resource: 'Hard-delete from one memory store.' It clearly differentiates from sibling tools by explicitly naming memory_fact_set and memory_supersede as alternatives for non-destructive updates. The scopes section further clarifies what the tool does for each store type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance: 'Cleanup for junk/test data — no audit trail.' It then states when NOT to use it and points to alternatives: 'For "now wrong, keep history" use memory_fact_set (facts) or memory_supersede (memories) instead.' Scope-specific instructions also clarify parameter requirements per use case.
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:

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

Score Badge

Copy to your README.md:

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

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