sqlite-memory-mcp

by miles990

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

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

Latest release: v1.0.2
Disambiguation5/5
Each tool follows a clear resource-action pattern (memory, context, skill, failure) with distinct operations. List vs search tools are differentiated by retrieval mechanism, so no two tools are ambiguous.
Naming Consistency5/5
All tools use a consistent resource_verb snake_case pattern (e.g., memory_write, context_set, skill_usage_start). The naming is uniform and predictable, making it easy to infer functionality.
Tool Count3/5
At 23 tools, the server covers four distinct resource areas, but this is on the heavy side. While each tool serves a purpose, the volume approaches the upper boundary of what is typical for a coherent server.
Completeness3/5
The surface covers CRUD for memory and context, but memory lacks an update operation, and skills/failures have no delete operation. These are notable lifecycle gaps that agents may need to work around.
Average 3/5 across 22 of 23 tools scored. Lowest: 2.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
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.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It merely states 'list' without explaining behavior such as pagination, sorting, maximum results, or what a 'failure experience' entails. This is insufficient for an agent to understand side effects or execution characteristics.
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 a single concise sentence, which is easy to read. However, it is under-specified and lacks any structural elements like examples or additional context. It reads as a fragment rather than a well-rounded tool description.
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?
This is a simple list tool with two parameters and a partial schema, but the description provides no information about return format, pagination, relevance, or how it compares to failure_search. The lack of annotations and output schema makes the description inadequate for an agent to fully understand the tool's context and capabilities.
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%, with both 'limit' and 'skill_name' already documented. The tool description adds no additional meaning to the parameters. Because the schema handles parameter semantics well, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List failure experiences' directly restates the tool name 'failure_list' without adding any specifics beyond the resource type. It does not differentiate itself from sibling tools like failure_search, which likely provides similar functionality. This is essentially a tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as failure_search. The description contains no context about preferred use cases, limitations, or exclusions. The only hint of a filter is in the parameter schema, but the description itself offers no usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. 'Register' implies a write operation, but side effects, idempotency, permissions, and return values are completely unexplored. The description is a bare phrase with no behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only one short sentence, but it is not appropriately sized because it is under-specified rather than concise. It lacks necessary details and does not earn its place with useful information. A concise description should still convey essential usage context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 5 parameters, 3 required, no output schema, and no annotations, this description is drastically insufficient. It does not explain what happens on success, how the tool behaves, or how it fits into the skill management workflow. The description is effectively a single phrase and fails to provide any contextual depth.
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 schema provides basic field names and descriptions (e.g., 'Skill name', 'Source (e.g., "plugin:evolve@evolve-plugin")'), but the tool description itself adds no additional meaning about how parameters relate or are used. The schema descriptions are sufficient for a baseline, but nothing extra is contributed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Register a skill installation' uses a verb and resource, but 'register' is vague and doesn't specify what the action entails or how it differs from sibling tools like skill_usage_start or skill_recommend. It is not a tautology, but it lacks the specificity to fully distinguish 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool vs alternatives. The description only implies it is for recording an installation, but does not mention exclusions, prerequisites, or related tools. This is insufficient for an agent to choose it confidently over sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry behavioral disclosures. It only says 'Get' which implies a read operation, but does not state side effects, error handling, access requirements, or return format. This is insufficient for a tool with no other metadata.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief (three words), but it is under-specified and simply restates the tool name. It lacks substantive content, making it less a model of conciseness and more a symptom of missing 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?
Although the tool has a simple single-parameter schema, there is no output schema and no annotations. The description does not explain what information is returned, how it differs from 'skill_list', or what happens if the skill name does not exist, so it is not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents the single 'name' parameter with a description ('Skill name'), and the tool description adds no additional meaning. With 100% schema coverage, 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.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get skill information' is a near-verbatim restatement of the tool name 'skill_get' and provides no additional specificity. It does not distinguish from sibling 'skill_list' or clarify that it retrieves a single skill by name.
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 offers no guidance on when to use this tool versus alternatives like 'skill_list' or 'skill_stats'. It does not mention prerequisites, such as requiring a skill name, or scenarios where this tool is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits itself, but it merely restates the tool's name. It does not mention whether the operation is read-only, what happens if the key does not exist, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, but it is under-specified and adds no value beyond the tool name. It is not appropriately sized because it omits necessary context, making it an incomplete, not merely concise, description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with no output schema, the description should explain the return value and error behavior, but it does not. It also does not clarify the role of session_id or how the context value is scoped, leaving the agent underinformed.
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 describes both parameters (key as 'Context key' and session_id as 'Session identifier') with 100% coverage, so the baseline is 3. The description adds no further semantic meaning beyond implying that the key identifies the value within a session.
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 uses the verb 'get' and identifies the resource as 'a context value', clearly indicating a retrieval operation. However, it does not differentiate from sibling tools like context_list or memory_read, which also perform read operations.
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 this tool versus alternatives. It lacks any mention of prerequisites, exclusions, or scenarios where context_get is preferred over context_list or memory_read.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full behavioral burden. It only restates the tool's name and doesn't disclose read-only nature, return format, rate limits, authentication needs, or potential side effects. The description adds no transparency beyond the tool name itself.
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 concise sentence with no wasted words. It is front-loaded and easy to parse. While it could include more detail, it is appropriately sized for its simplicity.
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 no output schema and no annotations, the description should explain what kind of memory statistics are returned, but it doesn't. It leaves the agent guessing about the output and context, making it incomplete for a stats-fetching tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, and the schema is empty with 100% coverage. The description doesn't need to add parameter semantics, and the baseline for zero parameters is 4. It doesn't mislead or obscure anything about parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Get memory statistics') and resource, but 'statistics' is vague and it doesn't distinguish from sibling stats tools like skill_stats or failure_stats. It's not a tautology, but lacks specificity about what statistics are provided.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives such as memory_list or memory_write. There is no mention of use cases, prerequisites, or exclusions, leaving the agent without context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only says 'share', which is ambiguous: does it copy or move context? What happens when the target already has context? Does omitting 'keys' share everything? None of these are addressed. The schema partially helps, but the description itself adds no behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, economical sentence with no filler or redundancy. It front-loads the action and resource, and every word earns its place. While it could be more informative, it remains highly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that transfers context between sessions, the description is under-specified. It does not explain default behavior (e.g., sharing all keys when 'keys' is omitted), side effects (copy vs. move), or return values. The schema mitigates some gaps, but the overall description is inadequate for an agent to fully predict tool behavior.
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 provides 100% coverage for all three parameters, including clear descriptions for optional keys, target session, and source session. The description adds no additional parameter information, so it stays at the baseline score of 3.
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 action ('share') and the resource ('context') with directional scope ('from one session to another'). This distinguishes it from sibling context tools like context_set or context_get, though it does not explicitly name alternatives. It misses the optional 'keys' detail, but the core purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 like context_set or memory_write. There are no exclusions, conditions, or references to sibling tools. The description only states the action, leaving the agent to infer applicability 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?
With no annotations available, the description carries the full burden of behavioral disclosure. It states 'clear' implying destructive behavior, but does not explain whether this clears all context or only a specific session, whether the action is reversible, or any side effects. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (three words), which is concise but under-specified. It does not waste words, but it also fails to front-load necessary context. The brevity feels like under-specification rather than effective conciseness, especially given the lack of behavioral 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?
The tool is part of a larger context/memory suite, but the description gives no sense of how clearing context fits into the workflow. There is no output schema, no annotations, and no explanation of scope or consequences. For a destructive operation, the description is incomplete and leaves the agent without enough information to invoke it safely.
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 one parameter, session_id, with a clear description. Schema description coverage is 100%, so the baseline is 3. The tool description adds no additional parameter semantics beyond what the schema provides, but the schema itself sufficiently explains the parameter's purpose.
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 'Clear context values' clearly identifies the action (clear) and the resource (context values). It is distinguishable from sibling tools like context_set and context_get, though it could be more specific about what 'context values' entails. The verb+resource structure is clear and non-tautological.
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 like memory_delete or context_share. There is no mention of prerequisites, exclusions, or typical scenarios. The description implies clearing context but gives no context on when that is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It only says 'for future reference', which implies persistence but doesn't clarify side effects, whether it overwrites existing records, or what response to expect. For a write operation, this is a significant gap.
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 sentence, concise and front-loaded. The phrase 'for future reference' provides a hint of purpose without extra fluff. However, it is slightly redundant with the tool name, preventing a perfect score.
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 5 parameters, no output schema, and no annotations, the one-sentence description is insufficient. It doesn't explain how the parameters relate, the required error_pattern, or what constitutes a successful record. The description is minimal and leaves the agent with many unresolved questions.
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 all five parameters already have meaningful descriptions. The tool description adds no additional parameter semantics, 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 'Record a failure experience for future reference' clearly states the verb ('Record') and resource ('failure experience'), which aligns with the tool name 'failure_record'. It distinguishes itself from sibling search/list/stats tools by implying a create/write operation, though it doesn't explicitly exclude update/delete behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like failure_update or memory_write. There are no preconditions, exclusions, or mentions of related tools. The agent is left to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states it gets statistics, but does not disclose whether it is read-only, what aggregation is performed, or what the output format is. 'Get' implies a safe read, but no further detail is given.
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 a single sentence, which is concise, but it is under-specified. It could be considered too vague to be fully useful, but it is not overly verbose. It earns a middle score for structure but lacks substance.
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 no parameters and no output schema, the description should describe what statistics are returned. It does not, leaving the agent unclear about the return value. The tool is simple but the description lacks necessary context for effective invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero properties, so parameters are not a concern. The description doesn't need to explain parameters, and with no params, the baseline score of 4 applies.
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 uses a specific verb 'Get' and resource 'failure statistics', which distinguishes it from sibling tools like failure_list or failure_search that return raw records. However, it doesn't specify what statistics are included, making it somewhat vague but still clear about its general purpose.
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?
There is no guidance on when to use this tool versus failure_list or failure_search. The description does not mention any exclusions, prerequisites, or alternatives, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'List memory entries' and does not mention ordering, pagination, return format, authentication needs, rate limits, or whether this is a safe read operation. This is a minimal disclosure with no additional context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with only five key words, front-loaded with the verb and resource. It contains no redundant information or filler, making it highly concise and easily parsable by an agent.
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 being a simple listing tool, the description lacks important context. There is no output schema or mention of return values, no guidance on filtering behavior (e.g., whether prefix is exact match), and no explanation of how this tool relates to the broader memory/context tool family. The description is technically present but incomplete for making an informed invocation decision.
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 the schema already describes all three parameters (limit, scope, prefix) with brief descriptions. The tool description adds no new semantic detail beyond the word 'filters', so it does not improve on the schema's parameter documentation.
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 uses a specific verb ('List') and resource ('memory entries') with explicit mention of optional filters. It clearly states what the tool does, but does not distinguish it from sibling tools like memory_search or memory_read, which may also list or retrieve memory content.
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 such as memory_search or memory_read. The phrase 'optional filters' implies filtering capability but does not explain the intended use cases, exclusions, or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for disclosing behavioral traits. It does not mention whether writing overwrites an existing key, requires unique keys, has permission requirements, or what the return value looks like. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It is concise, but lacks the enriching details that would make it truly valuable; still it is not overlong and gets to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 parameters, no output schema, and no annotations, the description is too sparse. It does not explain return values, overwrite behavior, key uniqueness, or interaction with sibling tools like memory_read/delete, leaving a notable completeness 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?
All five parameters have descriptions in the schema (100% coverage), so the schema handles parameter semantics. The description adds no extra meaning beyond naming the action itself, so the baseline score of 3 applies.
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 action ('Write') and the resource ('a memory entry to the knowledge base'), which distinguishes it from sibling read/search/list/delete operations. However, it could be more specific about the target knowledge base or the write semantics (e.g., create vs. update).
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?
There is no guidance on when to use this tool instead of alternatives like memory_update or context_set. The description merely states what it 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavior. It does not state whether the tool is read-only, whether it involves side effects, or how success rates are used to order recommendations. The lack of such context is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no unnecessary words. It front-loads the primary action and includes relevant criteria, earning a high score for efficiency.
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 the simple tool signature with only two optional parameters, the description lacks information about output format, recommendation criteria, or typical use cases. No annotations or output schema exist to compensate, making the description incomplete for a new agent.
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 clear descriptions for both parameters (limit and project_type), so baseline is 3. The description adds the 'success rates' context, which hints at the ranking logic, but does not elaborate on how parameters influence results 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 the function: get skill recommendations based on project type and success rates. This distinguishes it from sibling tools like skill_get or skill_list, which focus on retrieval or listing, though it could be more explicit about the recommendation nature.
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 this tool versus alternatives such as skill_list or skill_get. It does not mention scenarios, prerequisites, or exclusions, leaving the agent to infer proper usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does not state whether this tool updates a usage record, requires a success flag, calculates duration, or handles invalid usage_ids. The minimal phrase gives no insight into side effects or requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words. It is appropriately sized for a simple mutation tool, though it sacrifices depth for brevity.
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?
The tool has a clear workflow (paired with skill_usage_start) and five parameters, but the description offers no context about how to use it correctly. There is no output schema, and the description does not explain the lifecycle or expected behavior, leaving the agent with insufficient information for proper 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?
The schema provides 100% coverage with descriptions for all five parameters, including 'Usage ID from skill_usage_start' for usage_id. The description adds no additional meaning beyond the schema, 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'End skill usage tracking' uses a specific verb and resource, clearly indicating the action of stopping a tracking session. It distinguishes from the sibling tool skill_usage_start, which implies the complementary action. However, it lacks detail on what 'end' entails, such as recording final results or updating a record.
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?
There is no guidance on when to use this tool versus alternatives, nor any prerequisites like calling skill_usage_start first to obtain a usage_id. The description provides no context for the expected workflow or exclusions, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits, but it only states 'Start tracking skill usage' without explaining side effects, idempotency, or what state changes occur. It does not clarify whether starting tracking creates a session, overwrites existing sessions, or requires prior setup, leaving significant behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words, making it highly concise and front-loaded with the key action. It lacks any additional structure or context, but for a simple tool this is acceptable. It would earn a 5 if it incorporated more value 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?
The tool is a state-changing operation with no annotations and no output schema, so the description should provide workflow context. It does not mention that a tracking session should eventually be ended with 'skill_usage_end', nor does it explain the lifecycle or any consequences of calling the tool. Parameter schema is complete, but the overall context is insufficient for an agent to fully understand the tool's role.
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 both parameters (skill_name and project_path) are already documented with meaningful descriptions. The tool description adds no parameter-specific meaning, which is acceptable given the schema carries the full burden. There are no enums or nested objects complicating parameter understanding.
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 action ('Start tracking') and the resource ('skill usage'), making the tool's purpose understandable. It implicitly distinguishes itself from the sibling tool 'skill_usage_end' by indicating the starting point of a tracking lifecycle. However, it lacks detail on what 'tracking' entails, leaving some ambiguity about the exact scope.
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 usage guidance is provided. The description does not state when to use this tool versus alternatives, nor does it mention the companion tool 'skill_usage_end' or any prerequisites for tracking. The intended context is only implied by the tool name and terse description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure. It only mentions FTS5, which is already present in the schema. It does not indicate whether the operation is read-only, whether there are rate limits, or what the return format is.
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, focused sentence: 'Search memories using full-text search (FTS5)'. Every word contributes to the core purpose, with no filler 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?
For a simple search tool with a complete schema, the description provides a minimal viable overview. However, there is no output schema, and the description does not mention return behavior, pagination, or typical use cases, leaving some gaps for an agent deciding to invoke 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?
Schema description coverage is 100%, so both parameters and their semantics are fully documented in the schema. The description adds no additional parameter context, but this is acceptable because the schema already provides complete information.
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 searches memories using full-text search (FTS5). It identifies the action (search) and resource (memories), and the FTS5 mention hints at a distinct capability compared to sibling tools like memory_read or memory_list, though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/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 memory_list, memory_read, or other search tools. The description implies usage through its name but does not state contexts, exclusions, or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. It only mentions 'using FTS5,' which is an implementation detail, but it does not explicitly state that the operation is read-only, what the return format is, how results are ordered, or any limitations (e.g., does it search raw text or metadata?). The absence of such disclosures leaves the agent uncertain about the tool's behavior beyond the basic search action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence: 'Search for failure experiences and solutions using FTS5.' It is appropriately short, front-loads the core purpose, and contains no filler or redundant information. Every word contributes meaning, making it an example of efficient writing.
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?
The tool has two parameters, no output schema, and no annotations. The description is too sparse to be contextually complete. It does not explain what the results will look like, how the query is interpreted (e.g., exact phrase vs. fuzzy), or when this tool is the right choice. For a search tool, the absence of return-format details and usage context leaves a significant gap, especially compared to richer descriptions for similar tools.
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 provides descriptions for both parameters: 'query' is described as 'Search query for error messages or patterns' and 'limit' as 'Maximum results.' Since the schema coverage is 100%, the description adds little parameter-specific value. The description does not elaborate on parameter usage or format; the baseline score of 3 is appropriate because the schema already handles 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 clearly states the tool's function: 'Search for failure experiences and solutions using FTS5.' It uses a specific verb ('Search') and a specific resource ('failure experiences and solutions'). The mention of FTS5 adds technical specificity, and the tool name 'failure_search' plus the description distinguish it from sibling tools like failure_list, which is a list-not-search operation.
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 this tool versus alternatives. It does not mention any exclusions, prerequisites, or the relationship to failure_list or other failure tools. No context is given about when searching is preferred over listing or other retrieval methods, so the usage context is entirely implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description offers minimal behavioral context beyond the read intent implied by 'get'. It does not disclose whether statistics are aggregated, which skills are covered, or any access requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no redundant wording, earning full marks for brevity.
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?
For a simple zero-parameter tool, the description is adequate at a high level, but without an output schema, it leaves unclear the shape or content of the returned statistics. It could mention whether results are counts, durations, or per-skill breakdowns.
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?
Since the tool takes zero parameters, the empty schema fully covers parameter documentation. The description adds no parameter semantics, but none are needed, aligning with the baseline of 4 for zero-parameter tools.
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 uses the verb 'get' and identifies the resource as 'skill usage statistics', which distinguishes it from sibling tools like skill_usage_start/end and skill_list. However, it lacks specificity about what metrics are included, keeping it from a perfect score.
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 usage guidance or alternatives are provided. The description only states the action without telling the agent when to choose this over similar tools like failure_stats or skill_usage_start.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description gives no behavioral context beyond the verb 'update'. It does not disclose whether the solution overwrites previous solutions, what happens if the record doesn't exist, or any side effects, leaving the safety and behavior profile completely opaque.
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 packages the verb and target concisely. It is front-loaded and contains no redundant words, making it highly efficient for understanding the tool's core function.
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?
For a simple tool with only two parameters and no output schema, the description is minimally adequate. However, it lacks key context such as error behavior on missing IDs or whether the update is partial/full, which leaves some ambiguity for an agent invoking the 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 description coverage is 100%; both 'id' and 'solution' already have descriptions. The tool description adds no additional semantic meaning beyond what the schema 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update'), the resource ('a failure record'), and the specific purpose ('with a solution'). It distinguishes the tool from sibling tools like failure_record, failure_search, and failure_list, which handle other operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage is implied: you use this tool to attach a solution to an existing failure record. However, the description does not explicitly state when to use this over alternatives or mention any exclusions, providing only minimal guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits on its own. It only states the operation ('Delete a memory entry') but does not disclose whether the deletion is permanent, what happens if the key does not exist, or any side effects. For a mutation tool, this is insufficient 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 a single, focused sentence with no filler. It is appropriately sized for a simple CRUD operation and clearly front-loads the action ('Delete') and the target ('memory entry').
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema) and the absence of annotations, the description is minimally viable but lacks behavioral context. It does not mention irreversibility or failure behavior, which would be expected for a mutation tool, leaving some gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100% for the single required 'key' parameter, with the schema already explaining 'Key of the memory to delete'. The description adds no additional parameter semantics beyond what the schema provides, 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's function with a specific verb ('Delete') and a specific resource ('a memory entry'). This distinguishes it from sibling tools like memory_write, memory_read, and memory_list, which perform different operations on the same resource.
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 this tool versus alternatives. There is no mention of conditions that warrant deletion, prerequisites (e.g., key existence), or exclusions (e.g., when to use context_clear instead). It leaves the agent to infer usage purely from the name and schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of behavioral disclosure, but it only states 'Set a context value'. It does not mention overwrite behavior, scoping by session, expiration, or any side effects, which are crucial 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?
The description is a single concise sentence with no fluff, front-loading the action and purpose. Every word contributes value, making it appropriately sized for a tool with this simplicity.
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 5-parameter schema, no annotations, and no output schema, the description is too sparse to fully inform the agent. It does not explain the return value, overwrite semantics, expiration behavior, or how this tool differs from memory_write, leaving significant gaps for a state-setting operation.
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 documents all five parameters with descriptions (100% coverage), so the description does not need to explain parameter syntax. However, the description adds no semantic context beyond the schema, such as how 'cross-skill state sharing' relates to session_id or skill_name, leaving the baseline score of 3 unchanged.
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 explicit verb 'Set' and identifies the resource as 'context value' with a purpose ('cross-skill state sharing'), clearly distinguishing it from sibling tools like context_get, context_clear, and context_share. This provides a specific action and scope.
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 cross-skill state sharing, which suggests when to use it, but it does not explicitly state when not to use it or point to alternatives such as memory_write or context_share. There is no exclusion or comparative guidance, so the usage context is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description is the sole source of behavioral disclosure. It states the action but does not disclose whether the operation is read-only, what the return payload looks like, whether pagination applies, or any permission requirements. The word 'list' implies a read operation, but this is not made explicit.
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 with the verb front-loaded. Every word earns its place; zero wasted words. It is appropriately sized for the tool's simplicity.
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 parameter, no output schema, and no annotations, but the description gives no indication of the response format, whether 'all' includes metadata, or if there are pagination limits. While the action is clear, the lack of any return-value context leaves a gap in completeness for an AI agent to understand what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100% since 'session_id' has the description 'Session identifier'. The tool description adds no additional semantic detail beyond the schema, so it meets the baseline but does not exceed it. No examples, format hints, or relationship to other parameters are provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' with the resource 'context values' and scopes it to 'for a session', clearly distinguishing it from sibling tools like context_get (single value) and context_set (write operation). It is immediately obvious what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage ('List all context values for a session') but gives no explicit when-to-use or when-not-to-use guidance. It does not mention alternatives such as context_get for a single value or context_search for filtering, so the guidance is only implied by contrast with sibling tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It clearly indicates a read operation ('List') but does not mention the optional project_path filter or describe the return format. It adds minimal context beyond the tool's name, so a mid-range score is appropriate.
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, complete sentence: 'List all registered skills'. It is concise, front-loaded, and contains no filler or redundant content. Every word contributes to the meaning.
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 no output schema. The description provides the core purpose but omits key context such as the optional filtering behavior (implied by the parameter) and the return value shape. Given the simplicity, it is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%: the only parameter, project_path, is fully described in the input schema as an 'Optional project path filter'. The description itself adds no parameter information, and the baseline for high schema coverage is 3.
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 'List all registered skills' uses a specific verb (list) and resource (registered skills), clearly distinguishing from sibling tools like skill_get (retrieves a specific skill) and skill_recommend. The scope is explicit ('all registered'), 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 that this tool is for listing all skills, which serves as basic usage guidance. However, it does not explicitly state when to use this rather than skill_get or other sibling tools, nor does it exclude any cases. No alternative tools are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It indicates the operation is a read, implying non-destructive behavior, but it does not address edge cases like missing keys, return format, or any side effects. The minimal wording provides some transparency but leaves common behavioral questions unanswered.
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 target. It contains no filler or redundant information, earning a top score.
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—one parameter, no output schema, and no annotations—so the description is largely complete for basic usage. However, it could mention what happens when the key is not found or what the return value looks like, but given the low complexity, the current description is near-sufficient.
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 already covers the single parameter 'key' with a description, achieving 100% schema coverage. The description adds little beyond the schema—'specific memory entry' and 'by key' mostly rephrase the schema. As a result, it does not significantly enhance parameter understanding beyond the baseline.
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 ('Read') and resource ('memory entry') with a clear scope ('by key'). It clearly distinguishes from sibling tools like memory_write, memory_delete, and memory_list, which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'by key' implies the intended use case of retrieving a single known memory entry, which is distinct from listing (memory_list) or searching (memory_search). However, it does not explicitly mention when not to use this tool or name alternative tools, so it lacks full exclusionary guidance.
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:

[![sqlite-memory-mcp MCP server](https://glama.ai/mcp/servers/miles990/sqlite-memory-mcp/badges/card.svg)](https://glama.ai/mcp/servers/miles990/sqlite-memory-mcp)

Score Badge

Copy to your README.md:

[![sqlite-memory-mcp MCP server](https://glama.ai/mcp/servers/miles990/sqlite-memory-mcp/badges/score.svg)](https://glama.ai/mcp/servers/miles990/sqlite-memory-mcp)

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/miles990/sqlite-memory-mcp'

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