ERINYS
Server Quality Checklist
Latest release: v0.6.0
- Disambiguation3/5
Many tools are distinct, but there are several overlapping pairs: erinys_session_end versus erinys_session_summary, erinys_delete versus erinys_forget, and erinys_update versus erinys_supersede. Descriptions clarify, but an agent could still be uncertain which to call in common scenarios.
Naming Consistency4/5All tools share the 'erinys_' prefix and use snake_case consistently. However, some names are verbs (save, search, delete) while others are nouns (context, stats, timeline, lineage), creating minor style deviations from a strict verb_noun pattern.
Tool Count2/5With 29 tools, this server exceeds the 25-tool threshold for 'too many'. While the domain (memory management) is broad, the surface feels heavy and could likely be consolidated.
Completeness4/5The tool set covers CRUD operations, session lifecycle, graph traversal, memory quality evaluation, and forgetting. Minor gaps exist, such as no unlink edge tool and no prompt retrieval, but core functionality is solid.
Average 3/5 across 29 of 29 tools scored. Lowest: 1.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- No commit activity data available
- Last stable release on
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add
glama.jsonto the root of your repository:{ "$schema": "https://glama.ai/mcp/schemas/server.json", "maintainers": [ "your-github-username" ] }Then . Browse examples.
Add related servers to improve discoverability.
How to sync the server with GitHub?
Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.
To manually sync the server, click the "Sync Server" button in the MCP server admin interface.
How is the quality score calculated?
The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).
Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.
Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).
Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.
Tool Scores
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for disclosing side effects, whether the operation is a read or write, and what happens to the original observation. 'Distill' implies a transformation, but there is no mention of mutating state, creating new records, or reversibility. The description is entirely silent on these behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no wasted words, but it is under-specified rather than concise. It lacks structured detail about inputs, outputs, or purpose nuances, so the brevity is a deficiency rather than an asset.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the tool description provides no information about what the distillation produces or how it integrates with the broader tool set. With only two parameters, no annotations, and no description-level detail, the description is inadequate for an agent to invoke the tool correctly in most contexts.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate by explaining what the parameters mean. It does not mention 'observation_id' or 'level' at all, nor does it explain the meaning of the default 'abstract' level. The parameter semantics are entirely left to inference from the schema names, which is insufficient for an agent to choose correct values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Distill') and resource ('observation'), indicating it transforms an observation into a higher abstraction level. However, the phrase 'higher abstraction level' is vague and does not clarify what the output represents or how this differs from sibling tools like erinys_reinforce or erinys_supersede.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. The description does not mention any preconditions, exclusions, or scenarios where another tool would be more appropriate, leaving the agent without contextual decision-making information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior itself, but it only states that a session is started. It leaves unaddressed whether this is a mutation, whether it requires authentication, whether it resets ongoing work, or what side effects may occur. This is a significant omission for a tool that changes state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, but its brevity results in under-specification rather than efficiency. Essential information about parameters, behavior, and usage context is missing, so the sentence does not earn its place as the sole documentation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has three parameters, no annotations, and a session-lifecycle context involving sibling tools, the description is far too minimal to be complete. It does not explain what the output schema represents, whether sessions can overlap, or any prerequisites, making it inadequate for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema lists id, project, and directory with no descriptions, and the tool description does not mention any of them. At 0% schema description coverage, the agent has no way to know the expected format, purpose, or defaults of these parameters from the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific action (start) and resource (session), distinguishing it from siblings like erinys_session_end and erinys_session_summary. However, it does not explain what a session is or what starting one entails, so it is clear but lacking depth.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool, what conditions should hold before starting a session, or how it relates to alternatives such as erinys_session_end or erinys_context. It is simply a command with no situational or exclusions context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully convey behavioral traits. It only says 'recall', which suggests a read operation, but does not clarify side effects, return format, or whether it is read-only. No contradiction with annotations exists since there are none.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no fluff, making it structurally concise. However, it is so terse that it borders on under-specification rather than effective conciseness, as it omits critical operational details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has three parameters, an output schema, and no annotations, yet the description offers no context about how 'recent' is defined, how parameters influence results, or what the output contains. It is wholly inadequate for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description gives no information about the three parameters (limit, project, intended_use). It does not compensate for the schema's lack of descriptions, leaving parameter semantics completely ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the action ('Recall') and the object ('recent observations'), and indicates the purpose ('for context'). It is a specific verb-resource statement, though it does not explicitly differentiate from sibling tools like erinys_context or erinys_search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as erinys_search or erinys_get. The phrase 'for context' implies a use case, but there are no explicit instructions, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of explaining side effects, safety, and behavior. It does not state whether this is a read-only evaluation or if it mutates memory, nor does it describe what metrics are computed or how results are returned. The only behavioral hint is 'LOCOMO-inspired metrics', which is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no redundant or filler text. It is well-structured and front-loads the core purpose. However, it is so brief that it borders on under-specification, though that issue is more relevant to other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the low complexity (one optional parameter) and presence of an output schema, the description lacks essential context: it does not explain when to use the tool, what 'memory quality' entails, or how the project parameter influences the evaluation. The description is too minimal to be considered complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one optional 'project' parameter, and the schema description coverage is 0%. The description does not mention the parameter at all, leaving its purpose and effect entirely unexplained. The description fails to compensate for the missing schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('self-evaluate') and target ('memory quality'), and adds context with 'LOCOMO-inspired metrics' to clarify the evaluation approach. It distinguishes itself from sibling tools by focusing on evaluation rather than storage, retrieval, or manipulation. However, the term 'self-evaluate' is slightly ambiguous, potentially implying the tool evaluates itself rather than the memory system.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool or how it compares to alternatives like erinys_stats or erinys_recall. The description implies it is for assessing memory quality but provides no situational context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It says 'Create,' indicating a write operation, but does not mention idempotency, whether edges can be duplicated, whether source and target observations must exist, or any 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler or redundancy, making it easy to parse. While it is under-specified, this dimension rewards efficient communication, and the one-liner is appropriately front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 4 parameters, no annotations, and only a one-sentence description. The presence of an output schema may cover return values, but the description still lacks usage context, behavioral details, and parameter guidance, making it insufficiently complete for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description says 'typed edge,' which hints that the relation parameter specifies the type, but it does not elaborate on source_id, target_id, or weight. With schema description coverage at 0%, the description adds almost no meaning beyond the parameter names themselves.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Create' with a clear resource 'typed edge' and target 'observations,' making the action unambiguous. It does not explicitly contrast with sibling tools like erinys_lineage, but the phrase 'typed edge' strongly implies this is the edge-creation tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as erinys_lineage or erinys_supersede. It only states what the tool does, leaving the agent to infer appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses what statistics are returned but does not state whether the operation is read-only, has side effects, requires permissions, or any other behavioral traits. The name 'stats' implies read-only, but it is not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with key information front-loaded. It is appropriately sized for a simple tool, though it could be slightly more structured with parameter details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has one optional parameter and an output schema, but the description lacks any explanation of the parameter's role. It also provides no usage guidance or behavioral context, making the overall description incomplete for effective tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter 'project' with no description, and schema description coverage is 0%. The tool description does not mention the parameter at all, failing to explain its meaning, format, or how it filters the statistics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides database statistics with specific categories (observation count, project breakdown, health). It distinguishes itself from sibling tools by offering a unique stats function, though it lacks an explicit verb like 'get' or 'show'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention any usage context, prerequisites, or when other tools would be preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose side effects. It does not explain what happens to the old observation (deleted, archived, linked), whether the operation is reversible, or any cascading effects. The word 'supersede' hints at mutation but leaves behavior opaque.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler, but it is under-specified for a tool with three required parameters. It is efficient but not appropriately sized given the complexity; it lacks structure to explain the operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the presence of an output schema, the description lacks crucial context: no behavioral details, no parameter semantics, no mention of how it differs from update/save/reinforce. The one-liner is not complete enough to understand the tool's full effect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description adds minimal parameter meaning. It implicitly maps 'old observation' to old_id and 'updated fact' to new_content, but entirely omits the purpose of 'reason'. This fails to compensate for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'supersede' and identifies the resource ('old observation') and the replacement ('updated fact'). It clearly conveys the action of replacing outdated data, but does not explicitly differentiate from siblings like erinys_update, so it's clear but not fully distinguishing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description implies a scenario where an old observation is outdated, but lacks explicit prerequisites, exclusions, or contrast with related tools. Minimal guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, but it only implies a read-only operation via 'get'. It does not explain what 'session context' refers to, whether results are sorted or paginated, or how 'recent' is determined. This is insufficient for a tool that retrieves contextual data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no redundant phrasing. It is front-loaded with the main action and resource, but it is so short that it omits important usage and parameter details, which trades conciseness for completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with three parameters, an output schema, and a long list of siblings, this description is too minimal. It does not explain return values (though output schema exists), parameter meanings, or how this tool relates to others. The tool's niche remains ambiguous.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only implicitly mentions the 'project' parameter. It does not explain 'limit' or 'intended_use' (which has a default of 'context'), leaving two of three parameters semantically opaque. The description fails to compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get recent session context for a project' clearly identifies the verb ('get') and resource ('recent session context for a project'), providing a straightforward purpose. However, it does not differentiate itself from sibling tools like erinys_session_summary or erinys_recall, 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 Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives such as erinys_session_summary or erinys_recall. It lacks any context about appropriate use cases, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It hints at a batch operation but fails to state whether it mutates memory, requires an active session, or has side effects. The meaning of 'Dream Cycle' is left unexplained, leaving the agent without critical operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, consisting of a single sentence without waste. However, it is under-specified, which technically reduces clarity, yet the structure itself is appropriate and every word adds some meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the availability of an output schema, return values are presumably covered, but the description lacks context about when the Dream Cycle should be invoked, its relationship to sibling tools, and any state changes. As a batch operation, more context is needed about prerequisites and effects to make the tool safely usable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not mention 'max_collisions.' While the parameter name is somewhat self-explanatory, the description does not compensate for the lack of schema documentation by explaining how the parameter influences the batch collision process, such as limits or defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Run' and identifies the 'Dream Cycle' as a distinct operation, further elaborated as 'batch collision of candidate memory pairs.' This differentiates it from sibling tools like 'erinys_collide' by emphasizing the batch aspect, making the purpose reasonably clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention prerequisites, relationships to session tools, or cases where other collision-related tools might be preferred. The description gives no contextual usage hints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states the basic action and does not explain how 'as_of' is interpreted, what happens when 'as_of' is null, whether multiple facts are returned, or any limitations. This is a significant gap for a temporal query 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single, focused sentence that is front-loaded with the core action. Every word contributes meaning, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description is too minimal to support correct tool selection among many temporal and query siblings. It lacks usage context, parameter semantics, and any behavioral details, leaving the agent to infer too much from the name alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description provides no parameter information. The only hint is 'specific point in time' which relates to 'as_of', but the 'query' parameter is entirely unexplained. The description fails to compensate for the schema's lack of detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'query' and a resource 'facts valid at a specific point in time', making the core purpose clear. The temporal qualifier differentiates it from generic query tools like erinys_get or erinys_search, though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus siblings such as erinys_recall, erinys_get, or erinys_search. The description implies time-based querying but gives no exclusions, prerequisites, or alternative tool references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose whether traversal is read-only, how cycles are handled, maximum depth effects, or any other behavioral traits. The word 'Traverse' implies navigation but the actual behavior remains opaque.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no redundancy. However, it is so brief that it borders on under-specification rather than efficient packing of information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters, no annotations, and an output schema, the description still fails to provide essential context about depth limits, filtering options, or how this traversal relates to sibling tools. It is minimally adequate but leaves significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description should explain the parameters. It loosely maps start_id to 'starting observation' but leaves max_depth and relation_filter completely unexplained. The output schema does not compensate for this gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Traverse') and target ('graph from a starting observation'), making the core purpose clear. However, it does not distinguish this tool from sibling tools like erinys_lineage or erinys_timeline, which may also involve graph exploration.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, context, or exclusions, leaving the agent to infer the appropriate usage scenario.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must carry the full burden. It only states the operation and return value, but omits details about path semantics, default backup location, file overwrite behavior, or what 'consistent' means regarding SQLite locking/checkpointing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that gets straight to the point. It is front-loaded with the verb and resource, but could usefully mention the path parameter without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no parameter documentation, the description is too thin. It doesn't explain how the 'path' parameter affects the backup, what metadata is returned, or any prerequisites/limitations. The output schema exists but that does not excuse the missing parameter semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter 'path' with no description, and schema description coverage is 0%. The description does not mention the parameter at all, failing to compensate for the schema's lack of documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (create a consistent SQLite backup) and the result (return backup metadata). It uses a specific verb and resource, distinguishing it from sibling tools like 'erinys_export' or 'erinys_save' by explicitly naming backup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as 'erinys_export' or 'erinys_save'. There are no exclusion criteria or mentions of alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of disclosing behavior. 'Detect' implies a read-only operation, but the description does not state whether the tool writes, what it returns, what side effects exist, or how contradictions are determined.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no unnecessary words or repetition. It is concise and front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even though the tool is simple, the description is too minimal. With no annotations and an opaque output schema, it lacks sufficient context for an agent to know what happens when invoked, what the output looks like, or why this tool should be chosen over similar siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does 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 single observation_id parameter. While the parameter name is somewhat self-explanatory, the description fails to clarify what ID to pass or how it relates to the conflicting observations.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Detect') and the resource ('contradicting observations'), distinguishing the tool's core function from the name alone. However, it does not explicitly differentiate this from sibling tools like erinys_collide or erinys_supersede, which may also deal with observation conflicts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives, no scenario examples, and no mention of prerequisites or when not to use it. The description gives no context beyond the basic function.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the principal fallback logic (env ERINYS_PRINCIPAL → 'unknown') and the access gate priority (explicit args > env > None), including POLICY_DENIED rejection. However, it does not disclose other behavioral aspects like return values, side effects, or permissions for the save operation itself, so it partially covers the burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively short, with the purpose front-loaded, but it mixes Japanese and English and includes a cryptic 'P0-7' reference, which adds noise. It is not excessively long but could be clearer.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the tool has 12 parameters with no schema descriptions and no annotations. The description covers only the access-control and provenance aspects, leaving the rest of the parameters and the overall save behavior under-specified. It is incomplete for a complex tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description only explains principal, allowed_projects, and allowed_scopes (3 of 12 parameters). The remaining parameters (type, scope, project, metadata, topic_key, session_id, source_class) are undocumented, leaving a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Save a structured observation to ERINYS memory,' which is a specific verb and resource. It distinguishes from sibling tools like erinys_save_prompt or erinys_batch_save by focusing on 'structured observation,' but it does not explicitly name alternatives, so it is clear but not fully differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as erinys_batch_save or erinys_save_prompt. The description only explains internal behavior (principal resolution, access gates) rather than usage context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'save' without mentioning side effects, required permissions, whether the operation is idempotent, or what the response contains. This is a significant gap for a mutation 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no wasted words. It is appropriately front-loaded and concise, conveying the core purpose efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even with an output schema and three parameters, the description provides no behavioral context, no parameter explanations, and no usage guidance. The tool's complexity is not addressed, leaving the agent with insufficient information to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description mentions no parameter details. It does not explain what 'content' represents, nor the purpose of 'project' or 'session_id'. The description fails to compensate for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('save') and the resource ('user prompt') with a specific purpose ('track intent and goals'). It is relatively specific, but it does not explicitly differentiate from sibling tools like erinys_save or erinys_batch_save.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'to track intent and goals' implies a use case, but there is no explicit guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites. The usage context is only implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description bears full responsibility for behavioral disclosure. It mentions 'event-ledger idempotency', which is a useful behavioral trait, but it does not explain the side effects of applying records, whether 'plan' is a dry-run, permission requirements, or any limits. The description is too terse to provide adequate transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words, and the key verb phrase 'plan or apply' is front-loaded. However, it is so brief that it sacrifices clarity, making it slightly less effective than a perfectly concise but more informative description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a complex tool with five parameters, dual modes, and an idempotency control, yet the description provides only a high-level statement. It does not explain how the plan/apply modes differ, what 'bounded' means, the role of the digest, or how the event-ledger guarantee is realized. The presence of an output schema reduces the need to describe return values, but the overall contextual picture remains incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate by explaining parameters. It only loosely connects 'historical records' to the 'items' parameter and 'idempotency' to run_key/digest, but it never defines any parameter semantics. The agent is left to guess the meaning of mode, expected_plan_digest, and repair_temporal_projection.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses clear verbs 'plan or apply' and identifies the resource as 'bounded historical records', which conveys the tool's core function. It hints at a distinct purpose from sibling save/update tools through the backfill focus, but does not explicitly differentiate itself or define 'bounded', 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 Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'historical records' implies a backfill scenario, giving some context for when this tool would be used. However, there is no explicit guidance on when to use this over alternatives like erinys_batch_save or erinys_save, nor any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden for behavioral disclosure. It does not state whether pruning is destructive, reversible, or whether the dry_run parameter simulates the operation. This is a significant gap for a likely state-changing action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the core action and condition, containing no fluff. It is highly concise and easy to parse, though its brevity sacrifices necessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With two parameters, an output schema, and no annotations, the description is too sparse to inform an agent about parameter semantics, safety, or expected results. For a potentially destructive operation, this is insufficient for confident tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does 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 parameters. The only reference to 'threshold' merely echoes the schema without adding meaning about how it is used or what values are appropriate, and dry_run is completely unmentioned.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'prune' and resource 'observations', with a condition 'below threshold', making the tool's core action clear. It distinguishes from siblings like erinys_delete by implying a targeted cleanup of decayed data, though 'decayed' is not defined, leaving some ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when observations have decayed below a threshold but does not explicitly state when to use this tool versus alternatives like erinys_delete or erinys_forget. No exclusions or context guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. It does disclose the precedence and filtering behavior of allowed_projects/allowed_scopes and the default return-all behavior, which is useful. However, it does not explicitly state read-only status, return format, pagination, or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the core search mechanism in one sentence. The Japanese access-gate paragraph is dense but relevant, and the overall length is reasonable, though the language mixing could hinder scannability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 10-parameter search tool with no annotations, the description is incomplete. It covers the retrieval mechanism and access-control semantics but omits critical parameter details and behavioral expectations. The presence of an output schema reduces the need for return-format documentation, but does not compensate for the missing parameter guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does 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 only explains allowed_projects and allowed_scopes in detail; the other eight parameters (query, limit, project, principal, intended_use, metadata_filter, include_distilled, include_anti_patterns) remain undocumented, leaving significant ambiguity for invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as an RRF hybrid search combining FTS5 keyword and vector similarity. This gives a specific verb/function and the hybrid nature distinguishes it from plain retrieval, though it does not explicitly contrast with sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives like erinys_recall or erinys_context. The description focuses on access-gate behavior but does not state search scenarios, exclusions, or preferred use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavior, but it does not state whether the collision mutates state, persists data, requires a session, or has side effects. 'Generate insight' is vague about what the tool actually does or returns.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or repetition. Every word contributes to conveying the action and purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The presence of an output schema covers return values, and the two simple parameters are self-explanatory. However, the description lacks usage context, behavioral transparency, and any relationship to sibling tools, making it minimally viable but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions 'two observations', conceptually mapping to obs_a_id and obs_b_id, but it does not explicitly name the parameters or explain ID requirements. Since schema description coverage is 0%, more detail would help, but the parameter names are self-explanatory.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'collide' paired with a clear target ('two observations') and an intended outcome ('generate insight'). It is distinct from sibling tools by naming a unique action, though 'collide' remains metaphorical and does not explicitly differentiate from tools like link or traverse.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given for when to use this tool versus alternatives such as erinys_link, erinys_traverse, or erinys_conflict_check. The word 'Manually' hints at user-initiated use but does not provide context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the output format but does not disclose side effects, whether it is read-only, required permissions, or what happens to the exported data. The lack of behavioral details beyond the format is a gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the verb and object. It is appropriately concise with no unnecessary words, earning its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return values need not be explained, but the tool has two optional parameters with no descriptions. The description does not provide enough context about parameter usage or when to apply this tool, making it incomplete for an agent to invoke correctly without guessing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, and the description does not explain the 'format' or 'project' parameters. It only mentions 'markdown', which aligns with the default, but does not clarify other possible values or how 'project' filters observations. The description fails to compensate for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Export observations as markdown payload (Obsidian-compatible [[wikilinks]])'. It specifies the verb 'export', the object 'observations', and the output format, which distinguishes it from siblings like erinys_save or erinys_get.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for exporting observations in a portable format, but it does not explicitly state when to use it over alternatives or provide exclusions. The Obsidian mention hints at a use case but no direct comparison to sibling tools is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It does not explain what 'ending' entails—whether data is persisted, destroyed, or whether the action is reversible. No side effects or required permissions are mentioned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It concisely states the action and the only optional input, earning its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although an output schema exists to cover return values, the description omits behavioral context such as what happens to the session, whether a valid session is required, or how the summary is used. For a mutation-like tool, this is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does 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 only restates that the summary is optional, which the schema already encodes via default null. The 'id' parameter is left unexplained, and the purpose of the summary is not elaborated.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'End' with a clear resource 'session', and mentions the optional summary parameter. This unambiguously distinguishes it from siblings like erinys_session_start and erinys_session_summary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when ending a session, but does not explicitly state when to use it versus alternatives or include any exclusions. It lacks guidance on prerequisites such as whether a session must be active.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'Save', which implies a write operation, but does not disclose whether this overwrites an existing summary, requires an active session, what happens with the optional session_id, or any side effects. This lack of detail is a significant gap for a tool with no annotation safety nets.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that is front-loaded with a clear verb and object, followed by a parenthetical with the expected content structure. Every word earns its place, with no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 parameters and no annotations, the description leaves out critical context: the meaning of 'project' and 'session_id', whether the operation is idempotent, and any prerequisites. The output schema exists but is not shown in the description, so the return behavior is also undisclosed. This makes the description incomplete for a reliable tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does 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 provides some semantic value by indicating what 'content' should include (Goal/Discoveries/Accomplished), but it leaves 'project' and 'session_id' completely unexplained. With three parameters, the description only partially clarifies one, which is insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Save comprehensive end-of-session summary' with a specific verb ('Save') and resource ('end-of-session summary'), and it even specifies the expected content structure (Goal/Discoveries/Accomplished). This distinguishes it from sibling tools like erinys_save and erinys_session_start/end.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'end-of-session' implies this tool is for use at the conclusion of a session, providing some contextual guidance. However, it does not explicitly mention when not to use it or compare it to alternatives such as erinys_save or erinys_session_end, leaving the selection decision partially to inference.
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 behavioral burden. It discloses the traversal algorithm (following provenance.parents, falling back to distilled_from) and the 'lineage-complete' chain construction, which adds meaningful context. However, it does not mention depth limits or cycle handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences and fairly efficient, though the opening phrase 'VMG Provenance Visibility' is vague and not front-loaded with the most critical information. Still, every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return format is covered. However, the description does not explain the impact of max_depth, behavior on missing provenance, or invalid IDs, leaving gaps for a traversal tool. It is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only names and defaults (id, max_depth) with zero description coverage, yet the description does not explain what these parameters mean or how they affect the traversal. The names are somewhat self-explanatory, but the description fails to compensate for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool traces the lineage of a memory in the ancestor direction using provenance.parents or distilled_from, with a specific verb ('traces') and resource (memory provenance). It is distinguished from siblings by focusing on ancestry, though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving ancestor chains of a memory, but it does not provide explicit guidance on when to use this tool versus siblings like erinys_traverse or erinys_get, nor does it mention when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosure. It does state that the tool mutates access_count and last_accessed, which is useful, but it omits side effects, exact semantics (e.g., whether access_count is incremented or set), and any authorization requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that directly states the action and affected fields. Every word earns its place, with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple single-parameter mutation with an output schema, so the description does not need to explain return values. However, it lacks usage context and alternative guidance, leaving the agent uncertain about when to select this tool over sibling tools like erinys_update or erinys_recall.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not mention observation_id or explain how to identify the observation. While the parameter name is self-explanatory, the description fails to compensate for the lack of schema descriptions, as required for low-coverage cases.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Reinforce' and identifies the resource ('observation'), while explicitly stating the action taken: 'updating access_count and last_accessed.' This clearly differentiates it from general update or recall tools, such as erinys_update or erinys_recall.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. It does not mention prerequisites, intended context, or tools to avoid, leaving the agent to infer usage from the vague term 'reinforce.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses a key behavioral trait: deletion cascades to dependent rows via FK rules, which alerts the agent to side effects. However, with no annotations provided, the description carries the full burden and does not mention irreversibility, required permissions, or what happens to related data beyond the cascade. This partial disclosure warrants a mid-range score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is concise and free of unnecessary details. It earns its place by stating the action and the cascade behavior, with no fluff or repetition of the tool name or schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, straightforward delete action) and the presence of an output schema, the description is mostly adequate. However, it omits important context such as whether the deletion is permanent, whether confirmation is required, or any restrictions on use. These gaps are notable because there are no annotations to fill them, making the description slightly incomplete for a tool with side effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for the 'id' parameter, and the description only implicitly defines it as the identifier of the observation to delete. While this is sufficient to infer the parameter's purpose, it does not explicitly state that 'id' must be an existing observation ID or handle edge cases like non-existent IDs. The description partially compensates for the schema gap but leaves room for clarification.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete an observation') and the specific resource (an observation), along with the cascading behavior on dependent rows via FK rules. It distinguishes the tool from siblings like erinys_forget and erinys_prune by explicitly naming 'observation' as the target, which is more specific than generic deletion/removal verbs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like erinys_forget or erinys_prune, and does not mention any prerequisites or exclusions. It simply describes the action without context on appropriate use cases, which is a significant gap given the number of similar sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden for safety and side effects. It only states 'automatic similarity linking,' which hints at behavior but does not disclose whether this is a mutating operation, how links are formed, or what happens on partial failure. This is insufficient for a bulk write 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the core purpose without any filler. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a batch operation and the absence of annotations, this description is too thin. It lacks details about atomicity, failure handling, item schema, and the linking algorithm. The presence of an output schema covers return values, but the behavioral and error semantics are absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameters. It clarifies that 'items' are observations and 'auto_link' corresponds to similarity linking, giving some semantic meaning. However, it does not describe the expected structure of items or the exact behavior of auto_link beyond the name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Bulk-add') with a clear resource ('observations') and a distinguishing feature ('automatic similarity linking'), which sets it apart from siblings like erinys_save (single add) and erinys_link (manual linking). It is specific and 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Bulk-add' clearly implies this is for adding multiple observations at once, which is a distinct use case from the single-item erinys_save. However, it does not explicitly mention when not to use it or name alternative tools, so it stops short of being fully explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It adds the useful detail that content is untruncated, but does not mention potential side effects, error behavior for missing IDs, or any access constraints. The read-only nature is implied by the verb 'Get' but not explicitly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that communicates the essential action and a key behavioral detail. Every word 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.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple get-by-ID with an output schema present, so return values are covered externally. However, the description omits any context around the 'intended_use' parameter and does not clarify how this tool relates to the broader system of sibling tools, leaving some contextual gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does 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 clarifies that 'id' is the lookup key, but does not explain the 'intended_use' parameter at all. This leaves one of two parameters semantically undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: retrieving a single observation by ID, with the specific behavioral trait of returning full, untruncated content. This distinguishes it from sibling tools like erinys_search or erinys_recall, which likely perform broader or different query operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you have a specific observation ID and need the full record. However, it provides no explicit guidance on when to use this tool versus alternatives (e.g., using erinys_search without an ID), and no exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden. It discloses a key behavioral trait: partial update (only provided fields are changed), which is not immediately obvious from the schema. However, it omits other behavioral aspects such as error handling when the id doesn't exist, whether the update is reversible, or concurrency behavior. Given the mutation nature, this is a moderate disclosure but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise, consisting of two short sentences. It front-loads the purpose and adds a crucial behavioral note without any wasted words. Every sentence earns its place and improves clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 7 parameters, is a mutation operation, and has no annotations, but it does have an output schema, so return values are handled. The partial-update behavior is a critical piece of context and is provided. However, the description remains thin for a tool of this complexity, lacking information about error conditions, id requirements beyond the schema, and what 'observation' means in the broader system context. It is minimally adequate but leaves gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. The description adds no meaning to the parameters themselves; it only explains that unspecified fields remain unchanged. Parameter names like type, scope, title, content, project, and metadata are self-explanatory to some degree, but the description fails to provide any additional semantic detail, such as allowed formats or relationships. This falls short of compensating 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/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Update an existing observation.' It specifies the verb (update) and the resource (observation), and the phrase 'existing' distinguishes it from creation. This directly differentiates it from sibling tools like erinys_save and erinys_delete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for usage: it is for updating an existing observation, and the partial-update behavior is explicit with 'Only provided fields are changed.' While it doesn't explicitly name alternatives or exclusions, the context is sufficiently clear to infer when this tool is appropriate versus others.
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 behavioral burden. It discloses propagation to distilled descendants, leaf-first single-transaction deletion, affected stores (observations/vec/FTS/edges/collisions CASCADE), dry_run non-destructive behavior, and explicit out-of-scope exclusions (Obsidian vault, .bak backups). This is comprehensive and honest.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense yet well-structured, with the core purpose front-loaded in the first sentence. Every subsequent sentence adds meaningful behavioral, transactional, or exclusionary detail, with no irrelevant filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex, destructive tool with no annotations, the description is remarkably complete: it covers side-effect propagation, transaction semantics, dry-run mode, and exclusions. The output schema handles return shapes, but the implicit id semantics is a minor completeness gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no parameter descriptions, so the description must compensate. It explains dry_run's default and effect, but does not explicitly state that the required 'id' parameter identifies the observation or root node of the closure to forget. Some inference is required for a core parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool deletes observations and their distilled derivatives from the entire DB substrate and verifies absence via membership test. It explicitly distinguishes itself from erinys_delete by noting it can forget parents with children, making its purpose and differentiation 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: forgetting propagates to derived descendants, uses a single transaction, and defaults to dry_run. It contrasts with erinys_delete for the specific case of parents with children, but does not explicitly enumerate when to use this tool versus all other siblings, leaving some room for inference.
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:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/GhostyAI-HA/ERINYS-mem'
If you have feedback or need assistance with the MCP directory API, please join our Discord server