Leteo

by asanabrial

Overview Schema Related Servers Score Discussions

Rust

Local

Server Quality Checklist

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

Latest release: v0.1.2
Disambiguation5/5
Each tool targets a distinct operation: saving, retrieving, updating, deleting, session management, project handling, pinning, review, relations, and diagnostics. Even similar retrieval tools (search, context, timeline, get_observation) are clearly differentiated by their specific purpose and return format.
Naming Consistency3/5
All tools share the 'mem_' prefix, which provides cohesion, but the action part mixes imperative verbs (save, search, delete), nouns (context, stats, timeline), and noun-verb constructs (session_start, session_end). This inconsistent pattern makes it less predictable than a uniform verb_noun convention.
Tool Count4/5
With 22 tools, the set is on the heavy side but each tool covers a distinct aspect of memory management—sessions, projects, observations, reviews, and diagnostics. The breadth justifies the count, and it remains navigable due to the consistent prefix and clear individual purposes.
Completeness5/5
The toolset provides comprehensive coverage of the memory domain: full lifecycle for observations (create, read, update, delete), session management (start, end, prompts, summaries), project handling (detect, merge), plus pinning, review, relation verdicts, statistics, and diagnostics. No obvious gaps prevent core workflows.
Average 4.1/5 across 22 of 22 tools scored. Lowest: 3.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 64 commits in the last 12 weeks
- Last stable release on August 12, 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.
Tools from this server were used 4 times in the last 30 days.
This repository includes a glama.json configuration file.
This server has been verified by its author.
View related servers

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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and readOnlyHint=false, so the write nature is known. The description adds the 'stable manual-save session' default when session_id is omitted, which is valuable context. It does not elaborate on irreversibility or side effects, but the annotation covers the destructive nature. No contradictions detected.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the primary action and a key default behavior. There is no filler or redundancy; every word earns its place.
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 high parameter count (12) and rich schema descriptions, the one-sentence description is lean. It covers the primary purpose and a key default, but it omits usage guidance and does not mention important behaviors like topic_key revision, project ambiguity handling, or capture_prompt linking. The rich schema and annotations compensate partially, but the description itself leaves contextual 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 100%, so the baseline is 3. The tool description does not add anything beyond the schema's own detailed parameter descriptions (e.g., session_id default is already documented in the schema). Therefore, the description contributes no additional parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb+resource: 'Save an observation to persistent memory.' It distinguishes from sibling tools like mem_save_prompt by focusing on 'observation' rather than 'prompt', though it does not explicitly name alternatives. The core purpose is immediately understandable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use mem_save vs alternatives such as mem_save_prompt or mem_capture_passive. It mentions the session_id default behavior, which is a useful context, but it does not state explicit usage conditions, exclusions, or scenarios where another tool would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false and destructiveHint=false, covering the basic safety profile. The description adds that the summary is 'persistent memory', which is some behavioral context, but does not disclose details about overwriting, session relationships, or the recovery-token workflow hinted by the schema parameters.
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, direct sentence that front-loads the tool's purpose. It contains no fluff or redundancy, making it efficient and appropriately sized.
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?
While the schema and annotations are rich, the description lacks important context such as the ambiguous-project recovery workflow (recovery_token, project_choice_reason) and how this tool differs from mem_save. Given the tool's complexity, more contextual guidance would be needed for complete understanding, though the schema partially compensates.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are thoroughly documented in the JSON schema. The description adds no parameter-specific meaning beyond what the schema already provides, so the baseline of 3 is appropriate.
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 saves a structured end-of-session summary as persistent memory, specifying the resource (summary) and action (save). However, it does not explicitly differentiate from sibling tools like mem_save, which also saves to memory, though the 'end-of-session' qualifier provides some distinction.
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. There are no references to mem_save, mem_session_end, or exclusion criteria. The description only states what the tool does, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only/non-destructive, so the description's mention of 'read-only' adds no new behavior. It does add specific diagnostic domains, but no deeper behavioral traits like performance impact or required session state are disclosed.
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?
A single, front-loaded sentence with zero waste. It clearly states action and scope without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema, annotations, and full parameter schema coverage, the description covers the essential diagnostic scope. It lacks usage context and report expectations, but those are likely handled by the output schema and sibling tool composition.
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?
Both parameters are fully described in the schema (100% coverage), and the tool description adds no additional parameter information. Baseline of 3 is appropriate since the schema does the heavy lifting.
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 the specific verb 'Run' and clearly identifies diagnostic scope (SQLite, FTS, foreign-key, mutation-journal). This distinguishes it from the many sibling memory-management tools, making the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance on when to use this tool versus alternatives. It implies diagnostic use but does not state conditions for invocation, prerequisites, or 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?
Annotations already provide idempotentHint=true, and the description essentially restates that with 'return it unchanged if its identifier exists.' It adds minor specificity but no deeper behavioral context such as side effects or prerequisites. No contradiction with 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?
A single, front-loaded sentence that conveys the core action and idempotent behavior with zero wasted words. Excellent structure.
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, idempotent create tool with full schema descriptions, annotations, and an output schema, the description is sufficient. It could have mentioned typical usage context (e.g., as a setup step before using memory tools), but that is not essential.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and every parameter has a description. The tool description adds no additional meaning to the parameters, just uses the word 'identifier' which maps to the required 'id'. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('Create') and resource ('memory session'), and it distinguishes behavior via the idempotent clause 'or return it unchanged if its identifier exists.' This sets it apart from siblings like mem_session_end and mem_session_summary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. It does not mention mem_session_end for closing sessions or any other sibling, and there are no stated prerequisites or contextual triggers.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds the useful behavioral trait 'stable', indicating deterministic output across calls. However, it does not explain how the key is generated or how edge cases (e.g., empty title and content) are handled.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundancy. It immediately communicates the tool's purpose and key distinguishing trait ('stable'), making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity, comprehensive parameter descriptions in the schema, and presence of an output schema, the short description is largely sufficient. It lacks only an explicit tie-in to the upsert workflow (e.g., suggesting use before mem_save/mem_update), but this is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover 100% of the three parameters, including the type enum and title/content fallback behavior. The description itself adds no additional parameter-specific semantics beyond what the schema already provides, so baseline 3 applies.
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 states a specific verb 'suggest' and resource 'stable topic_key' with the context 'for observation upserts'. This clearly distinguishes it from sibling tools like mem_save or mem_get_observation, which perform different actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for observation upserts' implies when this tool should be used, but there is no explicit guidance on when not to use it or how it compares to alternatives. The usage context is clear but not elaborated with exclusions or preferred workflow placement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds useful postcondition information beyond the sparse annotations: each Key Learnings item becomes its own memory and is filed under the producing tool. While it does not detail side effects or error cases, it provides meaningful behavioral context that is not derivable from 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 fluff. Every clause contributes meaning: action, source, language scope, and storage behavior. The structure is front-loaded 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?
For a simple write tool with high schema coverage and an output schema present, the description covers purpose and behavior sufficiently. It lacks explicit alternative guidance or caveats, but these are not critical given the tool's straightforward nature.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so each parameter is already explained. The description does not add extra parameter-level semantics beyond noting the content requirement and language scope, which is partially schema-covered. Baseline 3 is appropriate.
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 specifies a concrete action ('Extract and save') and resource ('Key Learnings items a subagent ended with'), and distinguishes itself from sibling tools by noting the items are 'filed under the tool that produced it' and supported in 'twelve languages'. This goes beyond a generic save tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for subagent outputs with a Key Learnings section, but it does not explicitly state when to use this tool instead of alternatives like mem_save or mem_save_prompt, nor does it mention exclusions or conditions. It is not misleading, just minimally guiding.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds the key behavioral nuance that 'Semantic not_conflict is a successful no-op,' which is not captured by the annotations. It also confirms the write nature of the operation, aligning with readOnlyHint=false. This adds value beyond the structured annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that conveys the core purpose and an important edge-case behavior. Every word earns its place, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the rich schema (100% param coverage), output schema presence, and annotations (idempotentHint, destructiveHint), the description is sufficient. It captures the essential purpose and the no-op nuance, and additional details are not necessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are already well-documented. The description's mention of 'two observation IDs' simply echoes memory_id_a and memory_id_b, adding no new semantic meaning beyond the schema. The relation values are listed in the schema itself.
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 provides a specific verb+resource+scope: 'Persist a semantic verdict between two observation IDs.' This clearly distinguishes the tool from siblings like mem_save or mem_review, and the note about not_conflict being a no-op adds crucial specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a semantic verdict is to be recorded between two observations, but it does not explicitly state when to use this tool versus alternatives (e.g., mem_judge, mem_review). No exclusions or alternate tool references are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false and destructiveHint=true, so the agent knows it's destructive. The description adds the context of canonicalization and comma-separated variants, but does not elaborate on consequences (e.g., whether 'from' entries are deleted or just aliased). This is minimal but non-contradictory, consistent with a '3' for adding some value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the action verb and specifies the resource and outcome. There is zero waste or redundant phrasing, making it highly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with two fully documented parameters, an output schema, and annotations covering destructive behavior. The description is nearly complete for the tool's purpose, though it could benefit from stating whether the 'from' projects are deleted or merely reassigned. However, the existence of output schema and annotations reduces the burden, so a 4 is appropriate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and both 'from' and 'to' have descriptive schema text. The description adds no new parameter semantics beyond what the schema already provides; it merely restates the relationship. Therefore the baseline of 3 applies.
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 'Merge' with a clear resource ('comma-separated project name variants') and outcome ('into one canonical project'). It immediately distinguishes this tool from siblings like mem_update or mem_save by focusing on consolidation of variants, making the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use the tool: when there are multiple project name variants that should be consolidated. It provides a clear context without explicit exclusions or named alternatives, which aligns with the '4=clear context, no exclusions' level.
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?
Annotations already cover the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=true). The description adds meaningful behavioral context by explaining the effect on recency ordering, which goes beyond the annotations. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the core action and effect. It contains zero filler and every word contributes to understanding.
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 parameter, output schema exists, annotations present), the description is sufficient to convey the core purpose and effect. The term 'local observation' is a minor domain ambiguity, but overall the description is complete for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%; the id parameter is already well-documented in the schema (numeric identifier, also accepted as observation_id). The description adds no additional parameter semantics, so baseline score is appropriate.
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 ('unpin') and resource ('local observation') plus a clear effect ('returns to normal recency order'). It clearly distinguishes the tool from sibling mem_pin, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (you unpin something that was pinned), but it does not explicitly state when to use this tool versus alternatives like mem_pin, nor does it describe any prerequisites or exclusions. The context is inferred rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context by explaining the effect on memory ordering, which goes beyond the annotations. However, it does not disclose additional traits such as reversibility via mem_unpin or any side effects on existing pins. Annotations (idempotentHint=true, destructiveHint=false) cover some behaviors, so the description provides partial added value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the action and purpose without any fluff. Every word contributes to understanding.
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 simplicity of the tool (one parameter, output schema present, annotations provided), the description is complete enough. It states the action and its effect, and the structured fields cover the remaining details.
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 input schema already fully describes the single parameter 'id', including the alias 'observation_id'. The description does not add any parameter-specific information beyond what the schema provides, so the baseline score of 3 is appropriate.
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 ('Pin') and resource ('local observation'), and clearly states the effect (appears before recent observations in memory context). This distinguishes it from siblings like mem_unpin and mem_get_observation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: to prioritize an observation in memory context. It does not explicitly mention alternatives or exclusions, but the purpose is unambiguous and the sibling mem_unpin implies the reverse operation.
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?
Annotations already declare the tool as read-only, idempotent, and non-destructive. The description adds a valuable behavioral guarantee—'without failing on ambiguous or invalid project context'—which is not present in the annotations and helps the agent understand edge-case behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. Every element adds meaning, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this is a zero-parameter, read-only tool with an output schema and comprehensive annotations, the description is sufficiently complete. It captures the core purpose and a key behavioral nuance, with return details covered by the output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema coverage is 100%, so the description has no additional burden. The baseline of 4 applies because there are no parameter semantics to clarify.
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 'Detect' with a clear resource 'current project' and adds a distinguishing qualifier about handling ambiguous/invalid context. This clearly separates it from broader sibling tools like mem_context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Detect the current project' implies when to use it, but there is no explicit guidance about alternatives or when not to use it. The usage context is inferred rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint=false, idempotentHint=true), the description adds useful behavioral details: 'Manual not_conflict verdicts are persisted' and reason/evidence return as 400-character previews with truncation flags. This informs the agent about response behavior without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences that front-load the core purpose and then add relevant detail about persistence and truncation. Every sentence earns its place; no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity and presence of an output schema, the description covers the essential behavior: source of judgment_id, persistence semantics, and response preview behavior. It could elaborate on the effect of other verdict types, but that is not critical for selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already explains all parameters. The description references the truncation of reason/evidence, but that is more about output behavior than parameter meaning. It adds no significant parameter semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Record a manual verdict on a pending relation surfaced by mem_save.' It uses a specific verb ('record') and resource ('verdict on a pending relation'), and distinguishes itself from siblings by referencing the mem_save workflow and manual verdicts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use the tool: when a pending relation is surfaced by mem_save and a manual verdict is needed. However, it does not explicitly mention alternatives or exclusions, such as when to prefer automatic review or comparison tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already indicate non-read-only and non-destructive, but the description adds important behavioral details: list returns only 400-character previews marked with `content_truncated`, and full reads require a separate tool. This goes beyond the annotations and is valuable for the agent.
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: three sentences that front-load the core purpose, list the actions, and mention the preview behavior plus an alternative. Every sentence contributes value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (5 params, two actions) and the presence of an output schema, the description covers the essential context: what the tool does, the preview limitation, and a pointer to mem_get_observation for full content. It could mention which params apply to each action, but that is inferable from the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so all parameters already have descriptions. The description only reinforces that `action` can be 'list' or 'mark_reviewed', which is already in the schema. It does not add new semantic meaning for `id`, `limit`, or `project`. The baseline of 3 is appropriate.
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 identifies the tool as a review manager: it lists actions ('list, mark_reviewed') and specifies the resource ('observations due for review'). It also differentiates from mem_get_observation by noting the preview limitation, so the purpose is distinct and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly provides an alternative for a specific need: 'read one in full with mem_get_observation'. This indicates when to use another tool. However, it does not explicitly state when not to use this tool or contrast it with other sibling tools like mem_search, so guidance is clear but not exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses important behavioral details beyond the annotations: the 400-character preview with the `content_truncated` flag and the need to retain the sync_id. This adds meaningful context about return behavior and follow-up actions, going beyond what annotations alone indicate.
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 no filler, front-loading the core action and immediately providing the most critical behavioral caveat (truncation and sync_id). Every word serves a purpose, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the essential behavior (save, preview, sync_id) and benefits from a detailed schema and output schema. It does not explain the ambiguous-project recovery flow or the project_choice_reason/recovery_token interaction, but those are thoroughly documented in the schema, so the overall context is sufficient for an agent to operate effectively.
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 input schema already provides complete descriptions for all 5 parameters (100% coverage), so the description does not need to compensate. The mention of sync_id refers to an output field rather than a parameter, adding no extra clarity to parameter usage beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Save') and resource ('a user prompt') with a clear scope ('in an existing session'). It distinguishes itself from sibling tools like mem_save by referencing the existing-session requirement and the sync_id linking behavior, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies the context of use: saving a prompt into an existing session, and emphasizes keeping the sync_id for linking later saves. However, it does not explicitly mention when not to use this tool or name alternatives, so it falls short of the highest bar.
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?
Annotations already indicate destructiveHint=true and readOnlyHint=false. The description adds meaningful behavioral context: partial-update semantics (omitted fields preserved) and the 400-character preview with content_truncated marker, along with a path to retrieve the full memory. This goes beyond the annotations without contradicting them.
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—and front-loaded with the core purpose. The second sentence packs two critical behavioral details (partial update and preview truncation) without extra words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a medium-complexity update tool with a fully described schema and an output schema, the description adequately covers purpose, update semantics, response format, and a follow-up action. A minor gap is not explaining how to clear a field (e.g., via null), but this is not critical given the schema allows null values.
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 input schema has 100% description coverage for all parameters. The description supplements this by clarifying that omitted fields retain their current values, which is essential for understanding how to use the optional parameters. This adds value beyond the schema itself.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Revise a stored memory') and the resource (memory). It also differentiates from siblings by specifying partial-update behavior ('Fields left out keep their current value'), making it distinct from tools like mem_save or mem_delete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for revising existing memories, especially partial updates, but does not explicitly contrast with alternative memory tools or state when not to use it. The pointer to mem_get_observation for full reads is contextually useful but not an alternative for updating.
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?
Annotations already indicate destructive behavior. The description adds the crucial distinction between soft-delete (default) and hard-delete (permanent), which is valuable context beyond the structured metadata. However, it does not detail what happens to associated data or potential side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the action and includes the key default behavior. No unnecessary words; every element contributes value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with annotations and an output schema, the description adequately covers the essential behavior (soft vs. hard delete) and the acceptance of `observation_id`. No further context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers all parameters with descriptions and defaults. The description only echoes 'by ID' and 'hard_delete' without adding new semantic meaning. With 100% schema coverage, the baseline is 3, and the description does not elevate it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: deleting an observation by ID, with a specific verb and resource. It also distinguishes between soft-delete and hard-delete modes, which sets it apart from other memory tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The context is clear: to delete an observation, use this tool. It does not explicitly mention alternatives or when not to use it, but the delete operation is unambiguous and distinct from sibling tools like mem_update or mem_get_observation.
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?
Annotations already provide idempotentHint=true and destructiveHint=false, which cover the safety profile. The description goes beyond annotations by explaining the return behavior: the session comes back with a 400-character preview marked 'summary_truncated'. This adds useful contextual detail about the output without contradicting any annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the action, and every phrase provides value. There is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (2 params, no nested objects) and the presence of an output schema, the description covers the essential functional context and the notable return behavior (truncated preview). No critical information seems missing for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents both parameters: 'id' (with an alias) and 'summary'. The description merely reinforces 'optionally attach a summary', which is already stated in the schema. With 100% schema coverage, the description adds no new parameter-level semantics beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('End') and resource ('existing memory session'), and distinguishes it from siblings like mem_session_start and mem_session_summary. The optional summary attachment is also mentioned, leaving no ambiguity about the tool's 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 clearly indicates when to use this tool (to end an existing memory session) and mentions an optional action (attach a summary). It does not explicitly exclude alternatives, but the context is clear enough that an agent can differentiate it from related session tools like mem_session_start.
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?
Annotations already provide readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds transparency about the 400-character preview with `content_truncated` and the default project scoping, which are not captured in annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each with a distinct purpose: what it returns, how scoping works, and warning about truncation with a pointer to another tool. 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?
With an output schema present and 6 parameters fully documented, the description covers the essential behavior: return types, default scope, and truncation. It could mention ordering or that pinned observations may span scopes, but this is sufficient for a tool invocation decision.
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 100%, so baseline is 3. The description adds semantic meaning for `project` and `all_projects` by explaining the default behavior ('Answers about the current project unless you pass a project or all_projects'), going beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Get pinned and recent observations plus the recent sessions and user prompts of a project.' This specifies a concrete action and resource, and it distinguishes itself from the sibling tool mem_get_observation by noting that tool is for reading full observations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explains the default scope ('Answers about the current project unless you pass a project or all_projects') and points to an alternative for full reads ('read one in full with mem_get_observation'). It lacks explicit 'when not to use' guidance for other siblings, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, and non-destructive hints. The description adds a meaningful behavioral trait: the tool reads state and returns deleted memories with an indication, which is beyond what annotations convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no fluff. The first sentence states purpose and differentiators; the second discloses a key edge case. Every word 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?
Given the simple one-parameter tool with an output schema, the description covers purpose, sibling comparison, and a specific behavioral edge case. It is fully sufficient for an agent to select and call the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% coverage, already describing the id parameter and its alias. The description does not add any extra parameter-specific meaning, so the baseline of 3 applies.
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 gets one complete observation by numeric identifier, with full body. It explicitly distinguishes from mem_search and mem_context, which preview it, making the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly contrasts with sibling tools (mem_search, mem_context) and indicates this tool returns the full body rather than a preview. The note about deleted memories being returned also informs when to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the safety profile is clear. The description adds the useful scope detail that it 'counts the whole store,' but it does not disclose other behavioral traits such as return format or pagination. With annotations covering the core safety aspects, this is adequate but not richer than expected.
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 long, with the primary purpose front-loaded. The first sentence states what the tool does, and the second sentence adds an alternative. Every word earns its place with no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple tool with no parameters and an output schema (not shown but present). The description provides the essential context: aggregate scope, no arguments, and a clear alternative for project-specific counts. Given the low complexity and strong annotations, this is complete enough for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema fully covers parameter semantics (100% coverage). The description redundantly says 'Takes no arguments,' aligning with the schema. Per the rubric, 0 params earns a baseline of 4, and no additional parameter explanation 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 uses a specific verb+resource construction: 'Get aggregate memory store statistics.' It clearly distinguishes from siblings by explicitly noting that 'for one project's counts call mem_doctor with that project,' which prevents confusion with similar memory tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit contextual guidance: it states the tool counts the whole store (when to use) and directs users to mem_doctor for project-specific counts (when not to use, with an alternative named). This is a clear and useful usage guideline.
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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, but the description goes beyond by disclosing that long bodies are truncated to a 400-character preview with a content_truncated flag. This is critical behavioral context not present in the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each earning its place: the action, the scope default/override, and the truncation behavior with a pointer to the alternative tool. It is concise and well-structured with key information front-loaded.
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 7-parameter schema and presence of an output schema, the description covers the essential caveats (default project scope, preview truncation, and how to get full content). It gives the agent enough to select and invoke the tool correctly without requiring extra external knowledge.
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 input schema has 100% parameter coverage, providing detailed descriptions for all 7 parameters. The tool description adds no new parameter-specific semantics beyond summarizing that filters are optional, so it appropriately relies on the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: searching persistent observations via full-text query with optional filters. It specifies the scope behavior (current project unless overridden) and explicitly distinguishes itself from mem_get_observation, which is used to read full bodies.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit guidance on default behavior (current project) and how to alter it (project or all_projects). It also names an alternative tool (mem_get_observation) for the specific case of retrieving a full observation, fulfilling the when/when-not/alternatives criterion.
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?
Discloses key behavioral detail that bodies are returned as 400-character previews marked with `content_truncated`, and directs to mem_get_observation for full content. This adds value beyond the annotations which already declare read-only/idempotent hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: the first states the purpose concisely, the second discloses critical behavior and an alternative. No redundancy or extraneous information.
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?
With a rich schema, annotations, and existing output schema, the description fully covers the tool's purpose, unique behavior, and usage boundaries. No significant gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed descriptions for each parameter (after, before, project, observation_id). The tool description adds no additional parameter-specific meaning, so baseline 3 applies.
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 ('Show') and resource ('chronological context around a specific observation'), clearly distinguishing it from sibling tools like mem_get_observation (full read) and mem_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?
Explicitly states when not to use this tool by directing users to mem_get_observation for full observation bodies, and implies the appropriate use case of viewing chronological context.
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:

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

Score Badge

Copy to your README.md:

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

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/asanabrial/leteo'

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