Lore

Official

by agentkitai

Overview Schema Related Servers Score Discussions

Python

Remote

Server Quality Checklist

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

Latest release: v1.3.0
Disambiguation3/5
While individual tools have detailed descriptions, the large number of memory-related tools (remember, remember_observation, add_conversation, ingest) and retrieval tools (recall, search, get_memories, related, graph_query) creates potential confusion for an agent. However, the descriptions attempt to differentiate use cases, and there are no truly overlapping tools.
Naming Consistency3/5
Most tool names follow a verb_noun pattern using snake_case (e.g., list_memories, upvote_memory). However, there are exceptions like 'as_prompt' (starts with preposition), 'facts_at_time' (noun phrase), and 'on_this_day' (prepositional phrase). The overall pattern is fairly consistent but has several deviations.
Tool Count2/5
With 46 tools, the server is quite large. While each tool serves a distinct purpose in the memory management lifecycle, the count exceeds what is typically manageable and may overwhelm agents. A more focused set could reduce cognitive load without losing functionality.
Completeness5/5
The tool surface covers the entire memory lifecycle: ingestion (multiple methods), retrieval (semantic, categorical, temporal, graph), maintenance (consolidation, supersession, forgetting, voting, sharing), auditing (provenance, history, conflicts), and export/import. It is exceptionally comprehensive for a knowledge management system.
Average 4/5 across 46 of 46 tools scored. Lowest: 2.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 68 commits in the last 12 weeks
- Last stable release on June 25, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It does not mention side effects, persistence, permissions, or whether snapshots overwrite, leading to potential misuse.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (one sentence), which is efficient but sacrifices necessary detail. It could be expanded to cover key aspects without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters (1 required) and no annotations or parameter guidance, the description is insufficient. Even though an output schema exists, it is not provided, and the description does not hint at return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no information about the parameters (content, title, session_id, tags). The agent has no guidance on how to use them beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool saves a session snapshot to preserve context before it is lost. However, it does not differentiate from sibling tools like 'snapshot' or 'snapshot_list', which could cause confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when context might be lost, but does not provide explicit guidance on when to use versus alternatives, nor does it mention 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 exist, and the description does not disclose behavioral traits such as side effects, permissions, or operational constraints. It only states the basic function, failing to add value beyond the purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. However, it could be slightly more informative without losing conciseness, such as hinting at parameter roles.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite an output schema existing, the description is incomplete for a tool with four parameters and no parameter documentation. It lacks explanation of topic detection, filtering, or how it relates to sibling tools, leaving significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any of the four parameters (entity_type, min_mentions, limit, project). This is a significant gap, as the agent cannot infer parameter behavior from the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'auto-detected topics' with additional context 'recurring concepts across multiple memories.' It effectively distinguishes from siblings like 'topic_detail' and '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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention any context, prerequisites, or exclusions, leaving the agent to infer usage without support.
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 fully disclose behavioral traits. It mentions that data is synced into Lore as memories, but does not clarify whether the tool is idempotent, if it overwrites existing memories, or any side effects. It also lacks information about authentication scopes, rate limits, or error behavior. This is insufficient for a tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at two sentences, but it lacks structure such as parameter breakdown or return value info. The second sentence embeds the usage guideline effectively, but the overall brevity sacrifices necessary details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has four parameters with no schema descriptions and no examples, the description is far from complete. It does not explain the output schema, even though one exists, and provides no guidance on how to construct valid parameter values. Essential details for an ingestion tool are missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for parameters; the description does not explain any of the four parameters (repo, types, since, project). It only mentions the types of data (PRs, issues, etc.) in the tool purpose, but does not link them to the 'types' parameter or describe the format of 'since' or 'project'. This leaves the agent clueless about how to fill in the parameters correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool syncs GitHub repository data (PRs, issues, commits, releases) into Lore as memories, using a specific verb ('sync') and resource ('GitHub repository data'). It distinguishes itself from sibling tools, which are mostly about memory management and recall, not external data ingestion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes an explicit usage context ('USE THIS WHEN: you want to ingest tribal knowledge from a GitHub repo so it's searchable.') and states a prerequisite ('Requires the `gh` CLI to be installed and authenticated.'). However, it does not mention when not to use it or provide alternative tools for different scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. It indicates the tool returns connected entities and relationship types within a depth, implying a read-only query. However, it does not disclose side effects, limits, or required permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, front-loaded with the core purpose, and includes a usage hint. Every sentence adds value, but it could be slightly more concise by integrating the usage hint into the main sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 5 parameters, 0% schema coverage, and no annotation support, the description fails to provide adequate context for parameter usage. Although an output schema exists, the lack of parameter documentation makes the tool incomplete for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description provides no explanation for any of the 5 parameters (entity, depth, rel_types, direction, min_weight). The agent must infer meanings from parameter names alone, which is insufficient for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool queries the knowledge graph to find connected entities, with a specific verb and resource. However, it does not explicitly differentiate from sibling tools like 'entity_map' or 'related', which also explore connections.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides a 'USE THIS WHEN' condition, guiding the agent to use the tool for understanding relationships and dependencies. However, it does not mention when not to use it or suggest alternatives.
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 that only active (non-invalidated) facts are listed, which is a key behavioral trait. However, with no annotations, more details would be helpful, such as whether results are paginated, how large the response can be, or if any permissions are required. The presence of an output schema partially mitigates the lack of return format details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences. The main purpose is front-loaded, and the usage guidance is directly stated. No extraneous words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the number of sibling tools (44), the description provides a basic distinction via 'active (non-invalidated)' but does not clearly differentiate from other fact-related tools like facts_at_time or fact_supersession_chain. The schema and output schema exist but are not described. The description is adequate for a simple list operation but lacks full contextual completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must compensate. It implicitly mentions 'subject' by referencing 'what structured facts Lore knows about a subject,' but it does not explain the 'limit' parameter or any other details. The description is insufficient for the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists active (non-invalidated) facts from the knowledge base. The verb 'list' and resource 'facts' are specific. However, it does not explicitly differentiate from sibling fact tools like extract_facts or facts_at_time, which would strengthen clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes 'USE THIS WHEN' guidance for viewing facts about a subject or all facts, which provides context. But it lacks when-not-to-use instructions and does not mention alternative tools for other fact operations (e.g., extraction, temporal queries).
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 lists outputs but does not disclose potential costs, limits, or side effects. Since no annotations are provided, the description partially covers behavioral traits but omits details like performance impact or data freshness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, directly states purpose. Every word adds value, no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists and no annotations, the description is minimally complete for a read tool but lacks parameter details. For a tool with 3 parameters and 0% schema coverage, more description is warranted.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for parameters. The description does not explain 'max_memories' (default 20) or 'format' (default 'brief') beyond implying their roles. This leaves ambiguity for the agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves all information about a topic, including linked memories, related entities, and timeline. The verb 'Get' and specific outputs distinguish it from siblings like 'get_memories' or '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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'get_memories', 'search', or 'timeline'. With many sibling tools, explicit usage context is lacking.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states 'recent' but no time range, and implies a read-only list operation without mentioning side effects, auth, or rate limits. Adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences plus a usage note are concise and front-loaded. Every sentence adds value with no waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description fails to document parameters, leaving a significant gap. It is incomplete for a tool with two undocumented optional parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description does not explain the 'resolution' or 'limit' parameters. No added meaning beyond the schema defaults and types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List recent fact conflicts detected during memory ingestion' with specific verbs and resource. It distinguishes from siblings by explicitly mentioning conflicts, superseding, merging, and contradictions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a 'USE THIS WHEN' section that lists clear use cases: review knowledge changes, audit facts, resolve contradictions. However, it does not specify when not to use or mention alternatives.
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 must fully disclose behavior. It explains the mechanism ('Compares memories... against git commit history') implying a read-only operation, but it does not explicitly state non-destructiveness or mention any side effects, permissions, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: two sentences plus the usage hint. It is front-loaded with the purpose and each sentence adds unique value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema, so describing return values is not required. However, it lacks context about prerequisites (e.g., a valid git repository), what constitutes 'staleness', and how the output is structured. It is adequate but leaves gaps for a non-trivial tool interacting with git state.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, yet the description does not explain the parameters 'repo_path' or 'project'. It mentions 'file_path metadata' in the description but does not clarify how parameters relate to it. The description adds no semantic value beyond the parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Check if stored memories are still fresh' and specifies the resource ('stored memories', 'current git state'). It differentiates from sibling memory tools by focusing on 'code-pattern memories' with 'file_path metadata', implying a specific use case not covered by generic recall or search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an explicit usage scenario: 'USE THIS WHEN: you want to verify that code-pattern memories are still relevant before acting on them.' This frames the context well but does not mention when not to use it or list 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 provided, so description holds full burden. States state transition but omits effects on other users, reversibility, required permissions, or return behavior. Minimal behavioral disclosure 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with action and state change. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple one-parameter tool, but lacks mention of output schema return information and potential side effects. Could state if operation is reversible via promote_memory.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has memory_id with 0% description coverage. Description advises getting ID from recall output, adding some context, but does not specify format or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool changes a memory from SHARED to PRIVATE using specific verbs 'unshare' and 'making it private'. Distinguishes from sibling 'promote_memory' by indicating direction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit 'USE THIS WHEN' condition for shared memories that should become private. Tells user to pass memory ID from recall output. No explicit mention of when not to use or alternatives.
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 notes that facts already superseded are excluded, which is a key behavioral trait. With no annotations, it carries the full burden, but it doesn't disclose sorting, pagination, performance, or edge cases. Output schema exists, reducing the need to describe return structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief, well-organized with a clear purpose then usage section. Every sentence adds value, and it is front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (5 parameters, many siblings, no annotations, output schema exists), the description covers core behavior and usage but misses parameter details for direction/limit and doesn't differentiate from all related tools. Adequate but with gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description should compensate. It explains 'at', 'entity', and 'predicate' but omits 'direction' and 'limit'. Only 3 of 5 parameters are semantically described, leaving gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists facts about an entity valid at a point in time, using specific verb and resource. However, it does not explicitly differentiate from sibling tools like list_facts or fact_supersession_chain, which also deal with facts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'USE THIS WHEN' section provides explicit scenarios (audit, debugging, historical questions) and a concrete example. It does not mention when not to use the tool or list alternative tools, so it lacks exclusions.
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 full burden. It discloses that events are returned oldest first and implies read-only behavior, but lacks details on prerequisites, error cases, or limits. This is adequate 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences that cover purpose, usage context, and return ordering. Every word is necessary, and the key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one required parameter, existing output schema), the description covers the main aspects: purpose, usage, and return format. The lack of parameter description is a small gap, but overall it is sufficient for an agent to understand the tool's role.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema coverage is 0%—the description does not mention the single parameter 'relationship_id' or provide any guidance on its meaning or use. The schema only indicates it's a string, so the description adds no value for parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as showing the correction trail for a fact, with a specific verb 'show' and resource 'correction trail'. It distinguishes from siblings by emphasizing the historical chain aspect and provides concrete use cases like auditing changes over time.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides 'USE THIS WHEN' scenarios for auditing and tracing supersessions, which gives clear context. However, it does not explicitly exclude alternative tools or mention when not to use it, though the use cases are specific enough.
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 is the sole source of behavioral info. It states that only canonical memories at a timestamp are listed and that superseded ones are excluded, but lacks details on permissions, rate limits, or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with two sentences that front-load the core purpose and immediately provide usage guidance. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of an output schema, the description does not need to detail return values, but it lacks specifics on parameter formats (e.g., 'at' timestamp) and edge cases. It is adequate for a simple list tool but leaves gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning to 'entity' and 'type' parameters by stating they filter results, but does not explain the 'at' parameter format or the 'limit' parameter's role. With 0% schema coverage, the description partially compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists canonical memories at a given time, with a specific verb and resource. It implies distinction from siblings like 'facts_at_time' by focusing on memories, but does not explicitly differentiate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides a 'USE THIS WHEN' scenario and lists use cases: audit, debugging, historical questions. It also describes filtering options and what is excluded (superseded memories), but does not mention when not to use or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions that memories are grouped by year, defaults to today's date, and supports fuzzy matching via date window. However, it does not disclose whether the tool is read-only, required permissions, rate limits, or behavior when no memories are found.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences long, starting with a clear purpose statement, followed by usage guidelines, output format, and defaults/features. It is front-loaded and concise, with no redundant or irrelevant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 optional parameters and no annotations, the description covers main purpose, usage scenarios, and some behavior. However, it lacks details on how fuzzy matching works, what the date window entails, and the role of project/tier parameters. An output schema exists, which reduces the need to describe return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must add meaning. It explains that month/day default to today's date and mentions fuzzy matching, but does not clarify what 'date window' means or explain parameters like project, tier, and limit. The description adds minimal value beyond the schema for most parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves memories for a specific month+day across all years, using the verb 'retrieve' and resource 'memories'. It also lists use cases like reflecting on past events, finding anniversaries, and reviewing historical context, which distinguishes it from other memory retrieval tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes an explicit 'USE THIS WHEN' section outlining specific scenarios for using the tool. It mentions defaults and supports date window for fuzzy matching. However, it does not explicitly state when NOT to use this tool or suggest alternative tools from the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It describes the tool as producing a 'quick overview' of connections but does not disclose behavioral details such as whether it is read-only, performance characteristics, or limitations. The description minimally implies behavior but lacks comprehensive transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with a clear usage guideline. It is front-loaded with the main action and uses no unnecessary words. Every sentence serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the tool has three undocumented parameters and the description does not explain how to invoke them correctly. The description lacks completeness for effective use, especially since it positions itself as a simpler alternative to graph_query but does not describe how to use its parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, meaning no parameter descriptions exist in the schema. The tool description does not explain any of the three parameters (memory_id, entity_name, depth) beyond their names. The description says 'related to a given memory or entity' but does not specify which parameter to use, their mutual exclusivity, or the meaning of depth. This is a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Find memories and entities related to a given memory or entity.' It distinguishes from the sibling tool graph_query by noting it's a simpler interface for common lookups, and the 'USE THIS WHEN' section reinforces its purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states 'USE THIS WHEN: you want a quick overview... without needing the full graph_query options.' This provides clear guidance on when to use this tool versus the alternative graph_query, which is named directly.
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 must disclose behavioral traits. It mentions that results are 'oldest first,' but does not disclose whether the tool is read-only, requires permissions, or has side effects. This is sufficient 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences and a block of usage guidance. It front-loads the purpose and ends with a behavioral note. Every part adds value, though the usage guidance could be more structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a supersession chain and the presence of an output schema, the description does not explain what a supersession is or what the chain contains. It assumes prior knowledge, which may be insufficient for an agent unfamiliar with the domain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter 'memory_id' with no description, and schema coverage is 0%. The description only states it's 'for a memory,' adding minimal meaning beyond the schema. It does not explain the format or source of the memory ID.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Show the supersession audit chain for a memory.' It uses a specific verb-resource pair and distinguishes itself from the sibling 'fact_supersession_chain' by specifying 'for a memory.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage scenarios: 'investigating why a memory drops in retrieval score, auditing 'what changed' for a given fact, or tracing the lineage of a piece of knowledge across corrections.' It lacks explicit when-not-to-use or alternatives, but the guidance is strong.
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 is the sole source of behavioral info. It mentions the output is a formatted block of memories and lists supported formats. However, it doesn't disclose read-only nature, side effects, or rate limits, which leaves some gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: two sentences plus a usage directive. It is front-loaded with the core purpose and immediately provides a clear 'USE THIS WHEN' block. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 8 parameters and no annotation coverage, the description should provide more parameter context. The output schema exists but isn't referenced. The description covers purpose and usage well but leaves parameter semantics incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the description explains none of the 8 parameters. Only 'format' is implied by listing supported formats. The meanings of 'query', 'max_tokens', 'limit', 'tags', 'type', 'include_metadata', and 'verbatim' are left entirely to the schema, which is insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Export memories formatted for LLM context injection.' It specifies the resource (memories) and action (export into format), distinguishing it from other memory tools that perform different operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'USE THIS WHEN: you need to inject relevant memories directly into a prompt or system message.' This provides clear guidance on when to use the tool, though it doesn't specify when not to use it or mention alternatives.
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?
Without annotations, the description carries the burden. It discloses the default dry-run behavior and the merging/summarizing action, but does not mention side effects, reversibility, or authorization requirements. Adequate 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: a single sentence for the action, a usage hint, and a note on defaults. No wasted words, and the most critical information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and 0% schema coverage, the description should provide more context about parameters and behavioral nuances. It covers the core purpose and dry-run default but lacks depth for a complex tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description only addresses the `dry_run` parameter by stating 'Defaults to dry-run (preview only).' The `project` and `strategy` parameters are not explained, leaving significant gaps for the agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Trigger memory consolidation. Merges near-duplicate memories and summarizes related memory clusters into concise long-term memories.' It uses specific verbs and resources, and the action is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit WHEN guidance: 'USE THIS WHEN: memory bloat is high, or you want to compress episodic memories into semantic knowledge.' No alternatives or exclusions are mentioned, but the guidance directly addresses typical use cases.
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 must carry the behavioral burden. It discloses that rejected patterns are tracked to avoid re-suggestion, but does not detail whether it is read-only or destructive, authentication needs, rate limits, or error conditions. The description is partially informative 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences, no redundancy, and front-loads the purpose. However, it could benefit from a slightly more structured format, such as listing parameters or providing an example.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of parameter descriptions, no annotations, and an output schema that is not described, the description leaves gaps. It relies on familiarity with the workflow involving review_digest and does not fully explain the inputs or outputs for autonomous agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description does not explain the 'action' values or the 'reason' parameter explicitly. While 'approve or reject' implies possible actions, it does not specify valid values or the role of 'reason'. This is insufficient for an agent to construct correct invocations.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool approves or rejects a pending knowledge graph connection, using specific verbs and identifying the resource. It distinguishes from sibling tools like review_digest, which generates the list of connections.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly directs to use this tool after getting a review_digest and when the user has decided, providing clear when-to-use guidance. It also mentions that rejected patterns are tracked, indicating a learning mechanism.
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 must fully disclose behavior. It correctly implies a non-destructive read operation for backup, but lacks details on permissions, error conditions, or how the output file is handled. Filtering options are mentioned but not behavioral effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: first states purpose, second gives usage context and filter options. No fluff or repetition. Efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 7 parameters, 0 required, and an output schema (not shown), the description covers purpose and usage context but omits output format, error handling, and side effects. For a backup/migration tool, this is moderately complete but could explain what the exported JSON contains.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description helps by listing 'filtering by project, type, tier, and date,' which maps to the project, type, tier, and since parameters. However, it does not explain format, include_embeddings, or output, leaving gaps in parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Export all memories and knowledge graph to a JSON file for backup or migration,' specifying the verb (export), resource (memories and knowledge graph), and format (JSON). This distinguishes it from sibling tools, none of which perform a full export.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use scenarios: 'create a portable backup before risky operations, migrate data to another machine, or audit stored knowledge.' However, it does not mention when not to use or suggest alternatives like save_snapshot or snapshot, which are similar siblings.
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 provided; description carries burden. Discloses LLM processing for extraction but does not specify side effects (e.g., message storage, output format, or potential modifications to existing memories). Good but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences plus usage guideline section. No wasted words; information is front-loaded and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for core use case but missing details on output, error conditions, or processing guarantees. Output schema exists but its content is not visible to compensate fully.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 4 parameters with 0% description coverage. Description mentions 'messages' as raw conversation but fails to explain the required structure or the purpose of optional parameters (user_id, session_id, project).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it accepts raw conversation messages and extracts memories. Distinguishes from sibling 'remember' by noting it automates extraction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'USE THIS WHEN' for dumping raw conversation context, and contrasts with alternative 'remember'. Also mentions prerequisite (enrichment enabled).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must fully disclose behavioral traits. It implies read-only by saying 'List', but does not explicitly state nondestructive behavior, nor address side effects, permissions, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences plus targeted usage guidance. No unnecessary words, front-loaded with purpose. Efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 optional params, no annotations, and existing output schema, description covers purpose, usage, and one output format. Lacks mention of pagination or data shape, but output schema fills return value gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, baseline 4. Description explains 'entity_type' (filtering) and 'format' (JSON for D3), but does not explain 'limit'. This partially compensates for missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool lists entities in the knowledge graph with optional type filtering. It also provides usage contexts like 'find entity names for graph queries' and 'get an overview', differentiating it from siblings like graph_query.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit 'USE THIS WHEN' section lists scenarios, but does not mention when not to use or name alternatives. Still provides clear context for agent selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses that content goes through normalization and deduplication before storage and supports source-specific formatting cleanup. These details add behavioral context beyond the basic operation, though it could mention more about side effects or permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences plus a usage block. Every sentence adds value—purpose, processing details, and usage guidance. No redundant information, and the key points are front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 7 parameters and an output schema, the description adequately covers purpose and processing, but lacks detailed parameter explanations. It is complete enough for an agent to understand when to use it, but less so for correctly setting all parameters. The presence of an output schema reduces the need for return value details, so completeness is adequate but not excellent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 7 parameters with 0% description coverage. The description mentions that tracking includes 'who said it, where, when' which hints at user, channel, source parameters, but does not explain each parameter's purpose or format. It adds minimal meaning beyond what the schema provides, leaving ambiguity for agents.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool ingests content from external sources with source tracking, using specific verbs and resources. It distinguishes from siblings by listing supported sources (Slack, Telegram, Git) and features (provenance tracking, normalization, deduplication). This provides a precise and actionable purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'USE THIS WHEN' and provides clear contexts (importing content from external sources with provenance tracking). It gives a good usage scenario but does not explicitly mention when not to use or alternatives among siblings, so it stops short of full guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that it returns sources and chain events, but doesn't mention side effects, permissions, or safety characteristics. As a read-only tool, it's adequate but not fully transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two-sentence description plus usage hint is very concise and well-structured. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of lineage, the description explains what is returned (sources and chain) and when to use it. An output schema exists for return format details. Could mention pagination or limits.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% with no parameter descriptions. The description mentions 'for a memory' implying the memory_id parameter, but doesn't add explicit format or example. For a single required parameter, this is acceptable but minimal.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool shows the full lineage for a memory, including source memories and its supersession chain. It distinguishes from sibling tools like 'supersession_chain' by focusing on memory-level lineage and sources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit 'USE THIS WHEN' clause provides clear context: when a recall result looks suspicious or for auditing lesson synthesis. Could be improved by also stating when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description adequately discloses that the tool returns pending relationships grouped by type, includes entity names and source context, and mentions that rejected patterns are remembered. It implies read-only behavior without explicitly stating safety.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at 4 sentences, with a clear structure: purpose, usage, return details, and user action. It is front-loaded with the main purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the return format (grouped by type with entity names and source context) and user interaction. It adequately covers the tool's functionality given the single simple parameter and existing output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description does not mention the 'limit' parameter or its function. The parameter is simple but the omission means the description adds no value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'get' and the resource 'pending knowledge graph connections'. It explicitly mentions presenting for approval/rejection, which distinguishes it from siblings like 'suggest' or 'review_connection'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes an explicit 'USE THIS WHEN' statement indicating when to use it (present discovered connections for approval/rejection). It does not specify when not to use or mention alternative tools, but the guidance is clear and sufficient for most cases.
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 present, so the description carries full burden. It states 'Returns memories ranked by multi-signal relevance' but does not disclose behavioral traits like side effects, authentication, rate limits, or details on ranking. While it hints at being read-only, it lacks explicit transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: two sentences plus a usage note. It is front-loaded with the main purpose and provides immediate value without extraneous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 3 parameters with no schema descriptions, no annotations, but an output schema exists. The description covers purpose and usage but lacks parameter details, making it incomplete for proper invocation. Given the complexity, more information on parameters is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameters. It mentions 'current session context' but does not define the three parameters (context, max_results, session_entities) beyond their names and schema types. This is insufficient for an agent to correctly invoke the tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get proactive memory suggestions based on current session context.' It uses a specific verb ('Get') and resource ('memory suggestions'), and distinguishes from siblings by emphasizing proactivity without a query, unlike query-based tools like 'recall' or 'search'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit usage guidance is provided: 'USE THIS WHEN: you want to surface potentially relevant memories without a specific query. Useful at session start or before major decisions.' This tells when to use and implies when not to (when a specific query exists), effectively differentiating from alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that the tool requires configuration and that it is the manual counterpart to automatic enrichment. However, it does not specify whether enrichment overwrites existing metadata or is idempotent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise: two sentences plus a usage directive. Front-loaded with the core purpose. No superfluous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters, no annotations, and an output schema that is not described, the description is incomplete. It does not explain how parameters relate to each other, what the output contains, or edge cases like setting 'all' vs 'memory_id'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 4 parameters with 0% description coverage. The description does not explain the meaning of individual parameters like 'memory_id', 'all', 'project', or 'force'. It only loosely implies targeting via the phrase 'enrich older memories'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'enrich', resource 'memories', and output 'LLM-extracted metadata (topics, sentiment, entities, categories)'. This distinguishes it from sibling tools that perform different operations like classification or extraction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: 'USE THIS WHEN: you want to add structured metadata to existing memories for better filtering'. It also explains that automatic enrichment runs on remember() and this tool is for older memories, and lists prerequisites (LORE_ENRICHMENT_ENABLED=true, configured LLM provider).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description adequately discloses that the tool does not store facts and returns triples with confidence scores. It could be more specific about idempotency or rate limits, but for a read-only extraction tool this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences plus a usage note, front-loaded with the key action and no unnecessary words. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of an output schema (not shown but present), the description covers the essential context: purpose, behavior, and usage. It could mention that the tool is safe to call multiple times, but overall it is complete for a simple extraction tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description does not elaborate on the single 'text' parameter beyond what the schema shows. No details on expected format, length limits, or examples are provided, which would help an agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool extracts structured facts from text without storing them. It specifies the output format (subject, predicate, object triples with confidence scores) and distinguishes it from related tools like 'remember'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides usage guidance with 'USE THIS WHEN' for understanding facts in text or previewing before remembering. It does not mention when not to use or alternatives, but the guidance is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses key behaviors: natural-language search, filtering by multiple dimensions (tier, type, tags, etc.), temporal filters, knowledge graph connections, and scope control. It does not describe the return format or pagination behavior, but the output schema exists to cover that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: starts with purpose, then usage guidance, then query examples, then enumerates filters. Every sentence adds value. It is somewhat lengthy but justified by the parameter richness. No superfluous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 29 parameters, no schema descriptions, no annotations, and 45 sibling tools, the description provides a comprehensive overview of functionality. It covers the primary use case, filtering options, and special features (graph_depth, scope). It does not detail the output schema but that exists separately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must add meaning. It lists filter categories and temporal filters but does not explain all 29 parameters individually. It provides enough context for common use cases but leaves some parameters (e.g., 'session_id', 'include_session_context') without explanation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with a clear verb+resource: 'Search for relevant memories from past experience.' It further distinguishes itself by specifying natural-language search and providing query examples, which sets it apart from sibling tools like 'search' or 'get_memories' that may have different search semantics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states 'USE THIS WHEN' followed by concrete scenarios (solving problems, debugging errors, design decisions) and provides good/bad query examples. It does not explicitly mention when not to use or list alternatives, but the context is sufficiently clear for an agent to make appropriate selections.
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 fully carries transparency. It reveals that the tool works without LLM (structured listing) or with LLM enhancement (summary), and that results are grouped by project regardless of semantic relevance. No side effects are noted, but for a read-only tool this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three key sentences that front-load purpose and usage. It could be slightly tighter but is well-structured and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema covers return values, the description adequately covers overall behavior, grouping, time window, and mode. It lacks details on error handling and full parameter options, but is complete enough for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains 'hours' (last N hours) and 'project' (grouped by project) but does not explicitly detail 'format' or 'max_memories'. The reference to 'structured listing' vs 'summary' hints at format, but mapping is incomplete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get a summary of recent memory activity across projects' with a specific verb and resource. It distinguishes itself from sibling tools like search by emphasizing that it captures recent context that semantic search would miss.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to 'CALL THIS AT THE START OF EVERY SESSION' and explains why it is preferred over semantic search. However, it does not explicitly list alternative sibling tools or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that nothing is stored and returns structured classification, indicating non-destructive behavior and output structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences plus a clear usage cue. Every sentence adds value, front-loaded with the main action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter tool with an output schema, the description covers purpose, non-storage, and use cases. No annotations needed extra context; it's nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so description must compensate. It implicitly explains the 'text' parameter by saying 'classify a piece of text', but adds no format or constraints. Slightly above baseline due to mentioning classification dimensions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool classifies text by intent, domain, and emotion, and returns structured classification without storing. This distinguishes it from siblings that store or modify data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states use cases: before storing text or analyzing conversation patterns. Lacks explicit when-not-to-use but provides clear positive guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. States delete action but does not mention permanence, side effects, or required permissions. Adequate for a simple operation but could be more detailed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero wasted words. Action verb immediately in first sentence. Perfectly concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter delete tool with an output schema, the description covers purpose, usage conditions, and parameter origin. Lacks mention of output or feedback, but overall complete enough given simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description compensates by telling the agent to 'Pass the memory ID from recall output', which adds semantic meaning beyond the schema's parameter type. Does not specify formatting or validation but provides a clear source.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Delete a memory by its ID' – a specific verb and resource. Among sibling tools like demote_memory or downvote_memory, 'forget' explicitly means delete, distinguishing its purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Includes explicit usage conditions: 'USE THIS WHEN: a memory is outdated, incorrect, or no longer relevant.' Also provides parameter source hint: 'Pass the memory ID from recall output.' Lacks explicit alternatives but is clear on context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies a read-only operation ('list stored memories') and that it is for browsing/auditing, which suggests no side effects. However, with no annotations, it does not explicitly state it is non-destructive, safe, or provide any other behavioral traits beyond what is implied.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, consisting of two sentences and a usage tip. Every sentence adds value, with no unnecessary words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (so return values need not be described) and no required parameters, the description covers the basics: listing with optional filters and when to use. It lacks details on pagination or default limit, but is otherwise complete for a list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning for three of four parameters (type, tier, project) by stating they are optional filters. However, it does not mention the 'limit' parameter, and the schema provides no descriptions (0% coverage). Thus, the description partially compensates but is incomplete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies the action 'list' on resource 'memories', mentions optional filters by type, tier, or project, and contrasts with sibling tool 'recall' for semantic search, making the purpose very clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states 'USE THIS WHEN:' to browse, audit, or filter without semantic search, and directs to use 'recall' for semantic search, providing clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the burden. It indicates a read-like operation (list) but does not disclose details like data source, side effects, or limitations. Adequate for a simple list tool but lacks behavioral depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: one for purpose, one for usage guidance. No redundancy, front-loaded, and every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no parameters, and an output schema, the description provides adequate context for selection and invocation. It explains what the tool lists and when to use it, though it could mention return format or scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters (0 params), and schema description coverage is 100%. Per guidelines, baseline is 4. Description adds no param info but none is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List available snapshots for restore,' providing a specific verb and resource. It differentiates from sibling tools like save_snapshot by specifying 'for restore.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit usage guidance is given: 'USE THIS WHEN: you want to see what backups are available before restoring or cleaning up old snapshots.' No exclusions or alternatives mentioned, but clear context is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It describes the output components (total count, counts by type/tier, timestamps) but does not discuss side effects, auth needs, or rate limits. Since it is a read operation, the description is largely transparent. The existence of an output schema further clarifies the return structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two clear sentences that front-load the action and then provide usage guidance. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one optional parameter and an output schema. The description covers purpose and guidance well but omits any explanation of the project parameter, which is needed for complete understanding. The output schema likely describes return values, so the description is adequate but not fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one optional parameter 'project' with 0% schema description coverage. The description does not mention this parameter at all, leaving the agent unaware of how to use or the effect of specifying a project. Even though it is optional, the lack of explanation is a gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool returns memory statistics including total count, counts by type and tier, and timestamps. This distinguishes it from sibling tools like get_memories or list_memories that return individual memories, and from recall which retrieves by relevance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly specifies when to use the tool: for an overview of the knowledge base, checking memory counts, or seeing distribution across types and tiers. This provides clear guidance on context, though it does not 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?
The description explains the effect (boosts ranking) but does not disclose whether upvotes are reversible, if there are limits, or what the response contains. With no annotations, more detail would improve transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with no wasted words. It clearly states the purpose, usage condition, and effect in a compact format.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the essential aspects: purpose, usage condition, effect, and parameter source. It omits details about the response, but the tool is simple. Output schema exists but description doesn't reference it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description instructs the agent to use the memory ID from recall output, which is crucial context not present in the schema. This guides proper invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb-resource pairing 'upvote memory', clearly states the purpose (boosting ranking), and implicitly distinguishes from siblings like downvote_memory by focusing on helpfulness.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use: when a recalled memory helped solve a problem. It does not cover when not to use or suggest alternatives, but the context is straightforward.
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 provided, so description carries full burden. It discloses that it lowers ranking and accepts memory IDs from recall output, but does not mention reversibility, authentication needs, or other side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three front-loaded sentences: action, usage, effect, and parameter guidance. Every sentence adds value; no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given one required parameter, existing output schema, and clear sibling differentiation, the description covers purpose, usage, parameter source, and effect comprehensively for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must add meaning. It explains 'Pass the memory ID from recall output', which tells the agent the source and usage of the memory_id parameter beyond the schema's minimal type definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Downvote a memory' with verb+resource, and specifies it's for wrong or unhelpful memories, distinguishing it from siblings like upvote_memory and promote_memory.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use ('recalled a memory but it was outdated, incorrect, or misleading') and the effect ('lowers the memory's ranking'). Lacks explicit when-not-to-use, but context is clear.
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, description carries full burden. It discloses that memories are private by default and this opts one into shared pool, and instructs how to get the ID. No contradictions or omissions for this simple operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficient sentences: purpose, usage condition, default context, and instruction. No fluff, front-loaded. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and an output schema, description covers purpose, when to use, default state, and parameter source. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter (memory_id) with 0% schema coverage. Description adds value by saying 'Pass the memory ID from recall output', which explains the source, but does not provide format or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses a specific verb 'Share' and resource 'memory', and clearly distinguishes the action (PRIVATE → SHARED) from siblings. It states exactly what the tool does and its effect.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use ('when a memory is useful to teammates') and contrasts with default private behavior. Though sibling tools like demote_memory exist, no alternative is named, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that the memory is stored with type='observation' and affects future retrieval scoring. Also explains scope behavior. However, it does not mention side effects like overwriting or conflict resolution.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph with clear structure using capitalized cues like 'USE THIS WHEN' and 'PREFER THIS'. It conveys necessary information without excessive fluff, though some sentences could be streamlined.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and 6 parameters (3 required), the description covers purpose, usage, and key behavioral aspects. It lacks explanation of tags and project parameters but is otherwise complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description should compensate. It explains scope parameter in detail and mentions that facts are 'atomic facts', but does not clarify tags, project, or the exact format of title and narrative.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Record a structured observation extracted from a session' and differentiates from sibling tool 'remember' by specifying that this tool is for multi-faceted events while 'remember' is for polished single-fact memories.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use ('USE THIS WHEN: capturing a multi-faceted event') and when not to use ('Use the simpler remember(content, type=...) only for polished single-fact memories'). Provides clear alternatives.
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 provided, so description carries full burden. Describes storage location and restore capability but lacks details on potential side effects, idempotency, or naming conventions. Adequate but not comprehensive for a tool with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no waste. First sentence provides purpose, second gives usage guidance and storage location. Highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, usage context, and storage location. No missing aspects; output schema exists so return values need not be explained. Complete for a zero-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has zero parameters, and schema coverage is 100%. Baseline for 0 params is 4. Description adds no parameter info because none needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Create a quick snapshot backup of all Lore data.' Verb and resource are specific, and it distinguishes from siblings like 'save_snapshot' which may be an alias or similar.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: 'before consolidation, bulk imports, upgrades, or any operation that modifies many memories at once.' Provides clear context but does not mention when not to use or alternatives like restoring.
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?
Without annotations, the description discloses key behavioral effects: preserves history for audit and drops old memory's retrieval score. It also mentions un-superseding capability. Could be more detailed on error cases or side effects, but adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences, front-loaded with action, usage condition, and preference over alternative. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the context of many sibling tools, the description provides enough context on when to use this over alternatives. Output schema exists (not shown) so return values are covered. Missing full parameter documentation, but overall sufficient for moderate complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It explains 'superseded_by' (pass None to un-supersede) but does not explain 'reason' parameter at all. 'memory_id' is inferred but not explicitly described.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Mark a memory as superseded by a newer one.' It differentiates from sibling tools like 'forget' by explicitly preferring supersede for preserving history and retrieval score adjustment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use ('USE THIS WHEN: a fact has changed...') and when to prefer over alternatives ('PREFER THIS over forget'). Also provides guidance on un-superseding via 'superseded_by=None'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full responsibility for behavioral disclosure. It explains automatic enrichment behavior, the effects of setting tier (expiry) and scope (global vs project-specific). However, it does not describe error cases or behavior on duplicate memories, which would warrant a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph that efficiently front-loads the purpose and provides organized guidance on when and how to use the tool. Every sentence adds value, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (10 parameters) and the existence of an output schema, the description adequately covers the core functionality, usage guidelines, and key behavioral notes. Some parameter details are omitted, but the overall context is sufficient for an AI agent to decide when to use it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the schema has 10 parameters with 0% description coverage, the description adds significant meaning to `tier` (expiry details), `scope` (visibility defaults), and implicitly to `content` (should be clear and self-contained). However, many parameters like `type`, `tags`, `metadata`, `source`, `project`, `ttl`, and `session_id` are not explained, missing an opportunity to fully compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Save') and resource ('a memory'). It also provides concrete examples of when to use it (e.g., 'solved a tricky bug') and contrasts with not saving trivial things, differentiating it from siblings like `add_conversation` or `recall`.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states 'USE THIS WHEN:' followed by specific scenarios (solved a tricky bug, non-obvious fix, etc.) and 'DO NOT save trivial things', providing clear guidance on when to use and when to avoid. It also explains optional parameters like tier and scope to tailor behavior.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses cap, return format (JSON with content, tags, meta, timestamps), and error handling (errors array). Could explicitly state read-only nature, but sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is two sentences plus a brief error note, each sentence adds value without redundancy. Information is front-loaded and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema, description need not detail return values, but it still summarizes content. Covers usage, constraints, and error handling for a simple one-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It clarifies ids come from search and that one or more IDs are accepted, but does not add semantics like ID format or validation constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches full payloads for memory IDs, using specific verb-resource combination. It distinguishes from sibling search() by specifying it is used after search to drill into identified rows.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs 'USE THIS AFTER search()' and mentions a cap of 10 IDs per call, providing clear when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Explains critical behavioral detail: 'Provenance guarantee: every source_ids entry has its supersession_chain pointing at the returned id before this tool returns — even if the dream subagent crashes mid-loop.' This goes beyond empty annotations to disclose atomicity and crash resilience.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise: two terse sentences plus a usage note. Every phrase adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
High complexity (8 params, atomic operation, crash recovery) is well-addressed. Existence of output schema (not shown) reduces burden. Description covers provenance guarantees and general workflow, making the tool self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% (no param descriptions). The only hint is 'source_ids' and 'content' in the main description, but 6 other parameters (type, context, tags, reason, project, scope) are undocumented, leaving the agent to infer from schema names alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool's purpose: 'Atomic consolidation: create a new memory from N source memories and supersede every source in one operation.' It clearly differentiates from siblings like remember and forget by emphasizing atomicity and provenance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides precise guidance: 'USE THIS WHEN: merging near-duplicates or promoting an observation cluster to a lesson.' Also advises preferring this over remember+forget paths to preserve audit trails.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses cost comparison (~50 tokens vs ~300), return format, and scope behavior (default scopes to current project + global pool). No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-structured with headers and examples, but slightly lengthy. Still efficient and front-loaded with purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given output schema exists (covers return format), description is adequate: covers purpose, usage, param semantics for key params, and behavioral notes. Lacks details on limit and min_score, but overall complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so description adds meaning for query (example good/avoid queries) and scope (explains 'all' option). However, limit and min_score are not explained, leaving some gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it returns a compact index of relevant memories with specific fields (id, title, score, signals). Verb and resource are explicit. Distinguishes from siblings like recall and get_memories.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use (survey before drilling in), contrasts with recall (cheaper), and suggests pairing with get_memories. Also provides good/bad query examples and scope guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description fully covers behavioral disclosure. It explains that the old fact stops appearing in current queries but remains queryable as-of past dates, and that the correction is recorded in the audit chain. This gives the agent complete understanding of the tool's effects and side effects without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at about 100 words, front-loading the core action ('Supersede a fact...supercede-NOT-delete'), followed by usage guidance and parameter explanation. Every sentence adds value, with no redundancy or fluff. The structure is logical and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (so return values need not be described) and 3 parameters, the description is remarkably complete. It explains the behavioral impact (queryability, audit chain), provides a usage scenario, and references related tools (facts_at_time). No critical gaps are present; the agent can use this tool correctly without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must explain parameters, and it does for the two required ones: relationship_id is the old fact's ID, superseded_by is the newer fact's ID. The optional 'reason' parameter is not explained, but its purpose (a reason for supersession) is reasonably inferable. This adds significant meaning beyond the bare schema, though one parameter remains undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: supersede a fact with a newer one, explicitly contrasting with delete. It provides a concrete example ('ServiceX uses Postgres' → 'ServiceX uses MySQL'), making the function immediately understandable. The sibling tool 'supersede' exists but this is specifically for facts/relationships, and the description differentiates it from delete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a direct 'USE THIS WHEN' clause with a concrete example, specifying exactly when to invoke this tool (correction of a fact). It clearly states the required parameters and their roles (old relationship_id, new fact's id as superseded_by), and references facts_at_time for obtaining relationship_ids, providing clear actionable guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description fully discloses behavior: returns entries with specific fields, respects hard caps (±max_hours), scoped to project, non-destructive read operation. Also mentions cost (~60 tokens/entry). No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is a single well-structured paragraph that front-loads purpose, then adds constraints, entry format, usage guidance, cost, and parameter details. No redundant or irrelevant sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, the description still provides enough context: usage sequence, scope, constraints, entry structure, cost. Covers all essential aspects for an AI agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, but the tool description explains each parameter's meaning, constraints, and defaults: anchor_id (required), limit (1-50, default 10), direction (before/after/both), max_hours (>0, ≤72, default 2.0). Adds full semantics beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'return' and resource 'chronologically adjacent events' around an anchor memory ID. It distinguishes from siblings by specifying when to use (after search, before get_memories) and the scope (same project).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides a usage sequence: 'USE THIS AFTER search() identifies a promising hit, BEFORE get_memories()'. Also explains purpose ('to establish causality without paying for full content') and gives token cost estimation, helping the agent decide when to invoke.
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:

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

Score Badge

Copy to your README.md:

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

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/agentkitai/lore'

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