CarryMem

by lulin70

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.8.0
Disambiguation4/5
Most tools have distinct purposes, but classify_and_remember and classify_message overlap in functionality (the former combines classification and storage). Similarly, suggest_rules and promote_rules both analyze patterns for rule generation, though at different stages. Overall, descriptions help distinguish, but some pairs could cause misselection.
Naming Consistency4/5
Tools predominantly use snake_case and follow a verb_noun pattern (e.g., add_rule, list_rules, recall_memories). However, a few deviate: health_check is noun_noun, batch_classify is adjective_verb, and get_classification_schema mixes verb+noun phrase. These minor inconsistencies prevent a perfect score.
Tool Count3/5
With 28 tools, the server covers a broad domain (memory, rules, knowledge, consolidation). While each tool has a clear purpose, the count feels slightly high. Some consolidation is possible (e.g., merging suggest_rules into promote_rules with a flag) without losing functionality.
Completeness3/5
The tool set covers core CRUD for rules and memories, classification, retrieval, and consolidation. However, there is no tool to update a stored memory (only forget_memory), and knowledge management lacks update/delete operations. Additionally, bulk memory listing is absent, relying on recall_memories with filters.
Average 3.7/5 across 28 of 28 tools scored. Lowest: 2.3/5.
See the Tool Scores section below for per-tool breakdowns.
- 8 of 9 community issues answered or closed in the last 6 months
- 246 commits in the last 12 weeks
- Last stable release on July 22, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must disclose behavior. It omits important details such as pagination, ordering, rate limits, permissions, and the result of an empty query, leaving significant gaps for a list operation.
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?
While very short, the description includes an inaccurate filter (trigger topic) that wastes the agent's attention. Correctness trumps brevity here.
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 no output schema and 3 parameters with moderate schema coverage. The description lacks essential details about response format, sorting, or behavior when filters yield no results, leaving the agent underinformed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 67% description coverage; the description adds 'trigger topic' which is not a parameter, misleading the agent. It provides no extra meaning for the 'limit' parameter, which lacks schema-level description.
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 clearly identifies the action (list) and resource (rules in CarryMem's rule engine), but incorrectly mentions filtering by 'trigger topic' which does not exist in the input schema, causing potential confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus sibling tools like my_rules or match_rules. The mention of optional filters is incomplete and inaccurate, failing to set proper usage expectations.
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?
The description mentions returning a MemoryEntry JSON and optional storage, but it is unclear whether calling this tool has side effects (e.g., storing the memory). The phrase 'CarryMem is a CarryMem memory system with optional storage — it tells you WHAT to remember, and can optionally store it too' is ambiguous about the tool's behavior.
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 moderately concise (around 60 words) but the last sentence about the CarryMem system is somewhat confusing and could be streamlined. The core purpose is front-loaded, but the structure could be improved for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description should clarify side effects, output structure, and use cases. It vaguely mentions optional storage and return format but does not cover what happens if no memorable info is found or how to interpret the result. The presence of many sibling tools demands clearer context.
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 descriptions for both parameters. The description adds context about the output structure (MemoryEntry with fields) but does not enhance understanding of the parameters beyond the schema. 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 clearly states the tool analyzes a message to determine if it contains memorable information, which is specific. However, it does not explicitly differentiate from the sibling tool 'classify_and_remember', and the mention of optional storage blurs the boundary.
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 like 'classify_and_remember' or 'batch_classify'. The description mentions optional storage but does not clarify if this tool itself stores data or not, leaving the use case ambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description implies read-only but does not disclose behavior like result ordering, pagination limits, or error handling. Minimal behavioral context beyond basic retrieval.
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?
Two sentences, 18 words, no redundancy. Efficient but lacks depth; could include key details without adding bulk.
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?
No output schema; description omits return format, sorting, or pagination details. For a retrieval tool, this is insufficient for agents to interpret results 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 coverage is 67%; description summarizes existing parameter roles (filtering, full-text search) but adds no new meaning beyond what the schema descriptions state. 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?
Verb 'Retrieve' + object 'stored memories' clearly states action and resource. Differentiates from siblings like recall_all by specifying filtering and full-text search support.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this vs alternatives (e.g., recall_all, recall_from_knowledge). Only mentions prerequisite 'Requires storage adapter', but no context on when filtering is 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?
No annotations provided, so the description carries full burden. It indicates generating text with no side effects, but does not disclose permissions, rate limits, or whether the operation is read-only.
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 that efficiently state purpose and output characteristics with no superfluous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple generation tool, but missing details on max_rules behavior and exact output structure (no output schema). Could specify that output is a string suitable for embedding.
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?
Two of three parameters have schema descriptions (context and format). The description adds context about output content but does not explain max_rules. Schema coverage is 67%, so baseline 3 is justified.
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 it generates a formatted rules section for injection into AI prompts, which distinguishes it from siblings that add, list, or match rules. However, it does not explicitly differentiate from list_rules or match_rules.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The description only mentions 'for injection into AI prompts' but does not exclude cases where raw rule lists or other formats are needed.
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 burden. It only states 'Delete' and 'Requires storage adapter', omitting details like permanence of deletion, error cases, or side effects. Minimal 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?
Two sentences with no wasted words. The action is front-loaded, and the prerequisite is clearly stated. 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?
Given 27 siblings and no output schema, the description is too brief. It lacks information on return values, error behavior, and does not help the agent distinguish when to use this tool vs other memory tools like consolidate_memories.
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 a clear description for memory_id. The description adds no extra parameter meaning beyond what the schema provides, so 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 'delete' and resource 'stored memory' with method 'by ID'. It clearly states the action and distinguishes from siblings like recall_memories or consolidate_memories.
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 mentions a prerequisite ('Requires storage adapter'), providing some guidance on when it can be used. However, it does not specify when to use this tool versus alternatives or provide exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are available, so the description must fully disclose behavioral traits. It mentions 'schedule' and 'periodic' but fails to explain whether calling the tool again replaces an existing schedule, what permissions are needed, or what side effects occur (e.g., resource usage). The 'dry_run' parameter suggests a preview mode, but this is not highlighted.
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 that front-loads the verb and resource. It is efficient but could benefit from additional structure (e.g., bullet points for behavioral notes) to improve scannability. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core function, but given the complexity of scheduling (persistence, idempotency, cancellation) and the lack of an output schema, it leaves gaps. The schema explains parameters well, but the agent lacks information on how to cancel the schedule or what happens on repeated invocations.
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%, setting a baseline of 3. The description adds context about consolidation tasks (dedup, decay, cleanup) which loosely aligns with parameters like run_p1 and run_p2, but it does not add specific parameter-level semantics beyond the schema. The default values and descriptions in the schema are sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Schedule', the resource 'memory consolidation', and specifies the scope 'periodic'. It includes specific tasks (dedup, decay, cleanup) which distinguishes it from one-time consolidation tools like 'consolidate_memories' and cancellation tools like 'stop_consolidation'.
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 the tool is for scheduling periodic maintenance but does not explicitly state when to use this tool versus alternatives like 'consolidate_memories' for immediate runs. No when-not or exclusion guidance is provided, though the sibling list offers context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral transparency. It outlines the pipeline steps but does not disclose whether the operation is destructive, requires authentication, or has side effects like modifying memories. The description implies a multi-step process but lacks details on duration or state changes.
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 exceptionally concise with two short sentences. The first sentence front-loads the primary action and steps, and the second provides the use case. Every word adds value with no redundancy or fluff.
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 2-parameter pipeline tool with no output schema, the description gives a high-level overview but omits return values, error states, or preconditions. It mentions 'accumulated preferences' without defining the threshold. While the description is adequate for basic use, a more complete one would clarify outputs and edge cases.
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 description adds no new meaning beyond the schema: 'optionally auto-accept them' mirrors the auto_accept parameter description. The memory_type parameter is not elaborated further.
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 runs the full promotion pipeline, analyzing memories, detecting patterns, generating rule candidates, and optionally auto-accepting them. It specifies the verb 'run' and the resource 'promotion pipeline', and explains the outcome of converting preferences into active rules. However, it does not explicitly differentiate from sibling tools like suggest_rules, which may offer a similar but lighter functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a usage directive: 'Use this to convert accumulated preferences into active rules.' This provides context but no explicit guidance on when not to use the tool or what alternatives exist. For instance, it does not contrast with suggest_rules, which might be used for only generating suggestions without auto-acceptance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It describes the algorithm and requirements but does not state that the tool is read-only (no side effects), nor does it mention auth needs or rate limits. This is a significant gap for a graph traversal 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 two sentences: first states the purpose, second adds algorithmic detail and a prerequisite. No wasted words, front-loaded with key action. Perfectly concise.
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?
No output schema exists, so the description should clarify return structure. It mentions 'collecting all connected entities and memories' which hints at output but lacks specifics on format or pagination. With no annotations, completeness is adequate but not thorough.
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 with descriptions for all three parameters. The description adds context about BFS traversal but does not add meaning beyond what the schema already provides for each parameter. 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 clearly states the tool performs 'multi-hop graph traversal' from an entity using BFS, specifying the starting entity and collecting connected entities and memories within max_hops. This distinguishes it from sibling tools like 'shortest_path'.
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 mentions the prerequisite 'Requires storage adapter with graph capability' but does not explicitly state when to use this tool versus alternatives (e.g., shortest_path for path finding). Provides necessary context but lacks comparative 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 bears full responsibility for behavioral disclosure. It states the tool analyzes and suggests but does not mention side effects, required permissions, whether it modifies memory, or any read-only nature. This lack of detail 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 two sentences, front-loaded with the action and outcome, with no wasted words. It efficiently conveys the core purpose and usage context.
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 no output schema and no annotations, the description is sparse. It does not explain the output format, how candidates are presented, or limitations such as the number of memories analyzed. For a suggestion tool, more detail is needed for complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema describes memory_type with enum and description, and max_candidates with default/min/max but no description. The tool description adds no additional meaning beyond 'multiple times' which is not tied to parameters. With 50% schema coverage, the description fails to compensate for gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool analyzes stored memories and suggests rule candidates based on detected patterns, distinguishing it from sibling tools like add_rule, list_rules, etc. The verb 'analyze and suggest' and resource 'memories/rule candidates' are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates usefulness for discovering repeated preferences that could become formal rules, giving context for when to use it. However, it does not explicitly state when not to use it or compare to alternatives like match_rules, leaving room for improvement in guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description explains the host LLM usage and storage delegation, but omits side effects, error behavior, or reversibility. The pattern is described but not fully transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences, front-loaded with purpose, and efficiently conveys the pattern. Some redundancy exists but it remains clear.
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 no output schema and many siblings, the description lacks details on return values, error handling, and the exact role of the tool in the storage step. It is incomplete for an agent to use confidently.
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 the description adds minimal value beyond parameter descriptions. It does not elaborate on max_tokens semantics or namespace usage beyond defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it requests summarization and stores a session_summary memory. It explains the 'borrow host LLM' pattern and distinguishes from siblings by specifying no external LLM API key needed.
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 outlines the workflow but does not explicitly state when to use this tool vs. alternatives like classify_and_remember or declare_preference. It implies use for summarization but lacks exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the scope priority but omits important behavioral traits such as what happens on rule conflicts, the effect of the 'override' parameter, or any authentication/authorization requirements. The agent is left to infer that override exists from the schema, but the description does not explain it.
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 long, each sentence adds distinct information: what the tool does, what rules are for, and how scopes work with priority. No wasted words.
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 complexity (5 parameters, including override behavior, rule types, and scope priority), the description does not cover the behavioral interaction between rules (e.g., conflict resolution, effect of override). There is no output schema, so the agent does not know what the response contains. The description is incomplete for confident use in a rule engine context.
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 are documented. The description adds value by explaining the scope priority order and linking scope to use cases, but does not meaningfully augment the semantics of trigger, action, rule_type, or override. Baseline of 3 is appropriate as the description provides some but limited additional context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool adds a behavioral rule to the rule engine, distinguishing it from siblings like update_rule (modify) and delete_rule (remove). It also explains the scope priority, which helps differentiate from other tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use the tool (to add a rule) and explains the use cases for each scope (company, negotiated, personal) with priority. It indirectly implies that updating or deleting rules should be done with siblings, but does not explicitly state when not 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?
The description states it 'returns' data, implying a read operation, but with no annotations provided, it does not explicitly declare read-only or non-destructive behavior. It adds some context about the returned content but lacks details on auth requirements, performance characteristics, or potential side effects. The name itself already suggests a getter, so the description provides limited behavioral transparency beyond the name.
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 of 21 words, efficiently listing the schema components without redundancy. It is front-loaded with the main action and resource, making it quick to parse.
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?
Despite having no output schema, the description adequately conveys the scope (complete schema definition) and key contents (memory types, storage tiers, thresholds, mapping tables). For a simple retrieval tool with one parameter, this is sufficient to inform the agent about what to expect. It could be slightly more complete by noting that the response is a static definition, but overall well-rounded.
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%, as the single parameter 'format' has a description in the schema. The tool description does not add any further meaning or context about the parameter, so it meets the baseline expectation but does not exceed 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 uses the specific verb 'Return' and clearly identifies the resource as 'CarryMem's complete classification schema definition'. It enumerates the included components (7 memory types, 4 storage tiers, etc.), making the tool's purpose unambiguous and distinct from sibling tools focused on classification actions or rule management.
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 is provided on when to use this tool versus alternatives like classify_message or get_memory_profile. The description does not mention prerequisites, context, or situations where this tool is preferred, leaving the agent without direction for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full responsibility for behavioral disclosure. It implies a read-only operation ('Get') but does not explicitly state that it is non-destructive or whether it has side effects. The lack of explicit safety claims is a minor 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 consists of two concise sentences with no redundant words. It front-loads the core purpose and is easy to scan, achieving high efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool with two optional boolean parameters and no output schema, the description adequately conveys what the tool returns. It could be considered complete for this level of complexity, though mentioning the output structure (e.g., 'returns a profile object') would be slightly better.
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 have clear descriptions in the input schema, covering 100% of schema documentation. The tool description adds no additional meaning beyond restating that the profile includes memory statistics and rule summary. With high schema coverage, a 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 clearly states the tool's purpose: getting a complete view of the user's identity, listing specific components like memory statistics and rule summary. It uses a specific verb ('Get') and resource ('CarryMem identity'). However, it does not explicitly differentiate from the sibling tool 'get_memory_profile', which might have overlapping functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a usage hint ('Use this to understand what CarryMem knows about you'), which provides context. However, it lacks explicit guidance on when not to use this tool or alternatives, such as 'recall_memories' for specific memory retrieval.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavior. It implies read-only ('View'), but no mention of side effects, authentication, or freshness guarantees. Adequate but could be more 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?
Two sentences, no wasted words. First sentence states purpose and output fields, second gives usage context. 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?
No output schema, but description compensates by listing output fields ('triggers, actions, scope, type, override status'). For a simple read tool with two optional params, this is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear parameter descriptions. The description adds output field context but does not enhance parameter understanding beyond the schema, so baseline 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 tool views saved rules in a summary format, listing fields shown. It differentiates from siblings like add_rule, update_rule, and delete_rule, but the sibling 'list_rules' exists and the distinction is not fully clarified.
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 says 'Use this to review what CarryMem remembers about your preferences and behavioral rules,' providing a use case but not explicitly stating when not to use or alternatives like list_rules.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It explains the return structure (title, preview, tags, links) but does not disclose side effects, authorization needs, rate limits, or error behavior. It adds some behavioral context but not comprehensively.
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, efficient and front-loaded. First sentence states the core action, second states output. No redundant 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?
The description covers the tool's purpose and return structure despite lacking an output schema. Missing details on filter logic and adapter requirements, but for a search tool with few parameters the description is mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 67%, so the baseline is 3. The description adds context that the search is full-text and returns specific fields, but it does not elaborate on parameter behavior (e.g., how filters combine, default vs. explicit limit). It provides moderate added value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches a knowledge base using full-text search and lists what it returns (title, content preview, tags, wiki-links). It distinguishes from sibling tools like 'recall_memories' or 'recall_all' by specifying the 'knowledge base' and 'full-text search' verbs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions a prerequisite ('Requires knowledge adapter') but provides no guidance on when to use this tool versus alternatives like 'recall_memories' or 'recall_all'. There is no explicit 'when to use' or 'when not to use' 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?
No annotations are provided, so the description carries the full burden. It states the algorithm (bidirectional BFS) and return format, but does not disclose whether the tool is read-only or has side effects. Given the nature of path finding, it is likely read-only, but this is not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, consisting of three sentences that efficiently convey the tool's purpose, algorithm, output, prerequisites, and use case. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, the description adequately indicates the return format (list of entity texts). It could be improved by noting behavior when no path is found or when max_hops is exceeded, but overall it covers the essential aspects for a path-finding tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for each parameter. The description adds no additional semantic value beyond what the schema already provides, such as explaining the meaning of 'max_hops' or the format of entity texts.
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 finds the shortest path between two entities using bidirectional BFS. It specifies the resource (knowledge graph) and the operation (path finding). However, it does not explicitly differentiate from similar sibling tools like 'query_graph', which may also return paths.
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 mentions it is useful for understanding how concepts are connected and requires a storage adapter with graph capability. It provides some context but does not specify when to use this over alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It discloses that each result is an independent MemoryEntry, but lacks details on side effects, permissions, rate limits, or what 'classify' entails behaviorally.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at two sentences, with no wasted words. It immediately conveys the core function and result structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a batch operation (multiple messages, independent results), the description is adequate but incomplete. It does not mention limits on batch size, error handling, or any prerequisites. The absence of an output schema reduces completeness requirements somewhat, but more detail would be beneficial.
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 descriptions for message and context in the schema. The tool description adds no new parameter information beyond what is already in the schema, so it meets the baseline without providing extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool batches classify multiple messages, distinguishing it from single-message siblings like classify_message. The verb 'classify' and resource 'messages' are specific, and the output 'each returning an independent MemoryEntry' clarifies the return type.
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 name implies batch use, but no explicit guidance is given on when to use this tool versus alternatives such as classify_message for single messages or classify_and_remember for combined actions. No exclusions or context 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 discloses the three-step workflow and the dependency on storage adapter configuration. However, it does not explain the criteria for 'worth remembering' or behavior on failure, leaving gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the main purpose, followed by workflow and prerequisite. No redundant information, every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description covers the basic workflow and prerequisite but lacks details on classification criteria, return values, and differentiation from many sibling tools. Adequate but not comprehensive.
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 description adds no meaning beyond the schema. Both parameters have clear descriptions in the schema, meeting the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool combines classification and storage in one step, using specific verbs and resource. It distinguishes itself from siblings like classify_message (only classification) and forget_memory (storage removal).
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 combined classification and storage but does not explicitly state when to use it versus alternatives. The requirement of a storage adapter provides some context, but no exclusions or when-not-to guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and discloses key behaviors: declarations are stored with confidence=1.0 and source_layer='declaration', and they are classified by the engine. This provides transparency about how declarations are processed. It does not detail side effects like overwriting, but the core behavior is clear.
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: the first captures the core purpose, the second details technical storage specifics, and the third ties to the broader memory system. No superfluous words or redundancy. It is front-loaded and efficient.
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 (1 required parameter, no output schema, no annotations). The description explains what it does and how it works internally. However, it does not mention what the tool returns (e.g., confirmation or status) or any prerequisites. For a simple tool, it is mostly complete but could include return 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 already provides 100% coverage with a clear description and example for the 'message' parameter. The description adds context about classification and storage but does not add new semantic meaning beyond what the schema offers. Baseline 3 is appropriate as the schema does the heavy lifting.
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's purpose: letting users proactively tell the AI about themselves. It specifies the action and resource, and the mention of classification and storage distinguishes it from siblings like add_rule or forget_memory. However, it could explicitly differentiate from classify_message to enhance clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implicit usage context by contrasting active declaration with passive classification. It suggests using this tool when the user wants to explicitly state something. However, it lacks explicit guidance on when not to use it or mention alternatives, such as classify_and_remember for mixed cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states it returns applicable rules with scores but does not disclose any behavioral traits such as whether it is a read-only operation, performance implications, or authorization requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the main action, no extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (2 parameters, no output schema), the description is adequate but lacks details about the scoring mechanism or how results are ordered, which could be helpful.
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 description does not add additional meaning beyond what the input schema already provides for 'scene' and 'scopes'. 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?
Description clearly states the verb 'match', the resource 'rules', and the outcome 'return applicable rules with scores'. It distinguishes from sibling tools like list_rules by specifying matching against a scene/topic.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides a clear use case: 'before generating a response'. However, it does not mention when not to use this tool or suggest alternative tools like classify_message or recall_memories.
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 bears full responsibility for behavioral disclosure. It mentions updating and returning details but does not clarify whether unspecified fields are preserved or reset (partial update behavior), nor does it address permissions, side effects, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action, and contains no extraneous words. It is highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately states that it returns updated rule details. However, it lacks context on error handling, partial update semantics (field preservation vs. reset), and constraints like required permissions, which are not covered by annotations.
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 the baseline is 3. The description echoes the schema by naming some parameters (trigger, action, scope, type) but adds no additional meaning or usage context beyond what the schema already 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 verb 'Update' and the resource 'existing rule', listing specific attributes (trigger, action, scope, or type) that can be modified. This distinguishes update_rule from sibling tools like add_rule (create) and delete_rule (delete).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises using my_rules first to find the rule ID, providing a clear prerequisite. While it doesn't explicitly state when not to use this tool, the context of sibling tools implies alternatives for creation, deletion, and listing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It mentions returning a welcome message and asking questions but does not disclose side effects like whether it modifies user state or if it's idempotent. For a tool that initializes a profile, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two clear, front-loaded sentences with no extraneous information. Every word contributes to understanding the tool's purpose and usage.
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 simplicity of the tool (one optional parameter, no output schema), the description is fairly complete. It could mention that it's a one-time operation, but overall it provides adequate context for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter 'language'. The description adds no extra meaning beyond what the schema already provides, so it meets the baseline expectation.
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 indicates it's for first-time user onboarding, specifying it returns a welcome message and asks preference questions to initialize the profile. This distinguishes it from sibling tools that handle existing user operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states 'Call this when a new user starts their first conversation,' providing clear guidance on when to use. It does not mention when not to use or alternatives, but the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; the description does not disclose whether the action is reversible, idempotent, or what happens to ongoing consolidations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no superfluous information, achieving maximum conciseness.
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 no-parameter tool, the description covers the core function. Minor gap: no mention of side effects or reversibility.
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?
No parameters exist, so baseline 4 applies. The description does not need to add parameter detail.
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 'Stop' and identifies the resource as 'scheduled periodic memory consolidation', clearly distinguishing it from sibling tools like 'schedule_consolidation'.
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?
Implies usage to cancel a scheduled task but offers no explicit guidance on when to use versus alternatives like 'consolidate_memories' or prerequisites.
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. It reveals the retrieval priority (memory-first) and that it injects context, which is useful. However, it does not disclose other behavioral traits such as whether the operation is read-only, authentication requirements, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with only two sentences. The first sentence defines the core function and retrieval order, and the second provides usage guidance. No unnecessary information is included.
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 4 parameters and no output schema, the description covers the purpose and retrieval priority well. However, it could be more explicit about the return format (e.g., the type of output), but the tool name and context make the output fairly obvious.
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 the baseline is 3. The description does not add additional meaning beyond what the schema already provides for each parameter; it only summarizes behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool generates a system prompt with injected user memories and knowledge base context, specifying the retrieval priority. It distinguishes itself from sibling tools by focusing on system prompt generation rather than memory recall or management.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this to inject CarryMem context into any AI agent's system prompt,' providing clear guidance on when to use the tool. However, it does not mention when not to use it or present alternatives, leaving some room for improvement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description discloses source prioritization and configuration requirement, adding behavioral context beyond the input schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no waste, front-loaded with key behavior and prerequisite.
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 absent output schema and nested filters, description does not elaborate on response format or filter interaction, leaving some gaps despite adequate core purpose.
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 high (67%), and description adds no additional parameter meaning beyond what the schema already provides for query, filters, and limit.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states unified retrieval across two sources (memories and knowledge base) with priority order, distinguishing it from sibling tools recall_memories and recall_from_knowledge.
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?
Mentions prerequisite 'Requires at least one adapter configured' and priority behavior, but does not explicitly state when to use this vs individual recall tools or provide when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries full burden and excellently discloses behavior: it lists all return fields and even provides the exact formula for impact_score. It also mentions the requirement for graph capability. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loading the purpose and output details, then adding the prerequisite. Every sentence provides essential information with no waste.
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 output comprehensively given there is no output schema, and the single parameter is well-documented. However, it lacks information about error handling (e.g., memory not found, missing graph capability). For a simple tool, this is mostly 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 schema has 100% description coverage for the single parameter 'memory_id'. The description adds only the prerequisite context ('Requires storage adapter...') but does not elaborate on the parameter beyond what the schema already provides. Thus baseline 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 clearly states the tool computes the 'graph impact of a memory', specifying the exact metrics returned (entities, relations, cross-namespace flag, impact_score). This differentiates it from sibling tools like 'get_memory_profile' or 'query_graph'.
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 mentions the prerequisite 'Requires storage adapter with graph capability', but does not provide guidance on when to use this tool versus alternatives like 'get_memory_profile' or 'recall_memories'. No explicit when-not-to-use or alternative naming.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It discloses that the tool returns confirmation with deleted rule details, which is sufficient for a simple destructive action. Lacks mention of irreversibility, but that is implied by 'delete'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, zero waste. Each sentence earns its place: first states the action, second gives prerequisite and return info.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter delete tool with no output schema, the description completely covers the purpose, prerequisite, and return behavior. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description adds little beyond what the schema already provides. It repeats 'find it using my_rules' from the schema description, offering no new semantic detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Delete a rule by its ID', using a specific verb and resource. It clearly distinguishes the tool's action from siblings like add_rule or update_rule.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance to use my_rules first to find the rule ID, which is a helpful prerequisite. No need for when-not-to-use given the simplicity of a delete 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?
Describes behavior per priority level (P0 dedup+decay, P1 patterns+rule candidates, P2 semantic via LLM) and notes preferences are preserved. No annotations exist, so description carries burden; it is fairly transparent but could mention side effects or return value more explicitly.
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?
Four sentences, front-loaded with core action and sub-actions. No fluff; every sentence adds essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequately explains the consolidation process and levels given no output schema. Could improve by describing the format of the preview report or typical output, but overall complete for maintenance 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?
Schema coverage is 100%, baseline 3. Description adds value by explaining the purpose of dry_run ('preview changes') and clarifying run_p1/run_p2 behaviors beyond the schema's boolean defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the verb 'run' and resource 'memory consolidation', enumerating specific sub-actions (deduplicate, decay, clean up, pattern detection). Distinguishes from sibling tools like schedule_consolidation and stop_consolidation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly recommends periodic (daily) use and suggests using dry_run first. Lacks explicit when-not-to-use or alternatives but provides clear context for regular maintenance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, but description discloses scanning of Markdown files, extraction of YAML frontmatter and wiki-links, and building of FTS5 index. Provides behavioral detail beyond a simple 'index' statement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, no redundant words. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers core functionality and prerequisite. No output schema, but description implies index is built for later search. Could mention duration or scope, but sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters; schema coverage 100%. Baseline 4 applies. Description adds value by explaining the type of content indexed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the verb 'Index' and the resource 'Obsidian vault or knowledge base' with specific purpose 'for full-text search'. Distinct from sibling retrieval tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Mentions requirement of knowledge adapter (ObsidianAdapter) as prerequisite. Does not explicitly specify when to use or alternatives, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that the tool returns a structured summary, highlights, statistics, and a human-readable summary. It implies a read-only operation (no mention of modification). Could add explicit side-effect info, but overall adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences: states purpose, details output components, and adds a benefit statement. No wasted words, well-structured, and 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 tool's simplicity (0 params, no output schema), the description fully explains what it does and what the output contains. It covers the full scope of the tool's function.
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?
There are 0 parameters, and schema coverage is 100% (empty schema). The description does not need to add parameter info. Baseline for 0 params is 4, which 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: 'Get a structured summary of what the AI remembers about the user.' It specifies the resource (memory profile) and verb (get), and distinguishes it from siblings by detailing the output type (highlights, statistics, summary) which is different from raw memory queries.
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 mentions it 'Lets users see and audit what AI remembers,' implying an overview/audit use case. However, it does not explicitly state when not to use it or provide alternatives among the many sibling tools (e.g., recall_memories for specific memories).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description fully discloses behavior: it is a lightweight check that does not start HTTP services and returns specific health indicators. No contradictions with missing 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 effectively convey purpose, return values, and usage context with no wasted words. Front-loaded with the key action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless health check, the description covers purpose, return items, and usage context. Missing details like error handling or status codes, but overall adequate for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no parameters, and schema coverage is 100% (empty). The description adds value by listing return fields and stating it is lightweight, exceeding 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 clearly states the tool checks system health and lists specific return values (adapter health, audit logger stats, memory count, uptime), distinguishing it from sibling tools that deal with classification, rules, or memories.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises use from MCP clients to verify operational status and notes it does not start any HTTP service, providing clear context. No exclusions or alternatives mentioned, but the simplicity of the tool compensates.
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:

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

Score Badge

Copy to your README.md:

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

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/lulin70/carrymem'

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