CPersona

Official

by Cloto-dev

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: v2.5.5
Disambiguation4/5
Most tools have clearly distinct purposes, though some overlap exists (e.g., recall vs recall_with_context, check_health vs deep_check). Detailed descriptions mitigate ambiguity, but the sheer number of related operations may require careful reading.
Naming Consistency4/5
The majority follow a verb_noun pattern (list_memories, delete_memory, set_recall_precision), but a few deviate (persistence_status, store, recall). This is mostly consistent with only minor exceptions.
Tool Count2/5
With 29 tools, the count exceeds the recommended range for a typical server. While the domain is rich, this number feels heavy and may overwhelm agents, suggesting a need for consolidation.
Completeness4/5
The surface covers CRUD for memories, episodes, and profiles, plus import/export, health checks, and configuration. Minor gaps like a direct get-by-ID tool exist, but recall and list functions cover most needs.
Average 4.3/5 across 29 of 29 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 184 commits in the last 12 weeks
- Last stable release on August 21, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description aligns with readOnlyHint by stating 'Get', but adds no further behavioral details such as error handling for missing agents, return format, or scope of the profile.
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?
Single sentence, concise and front-loaded. Could include more detail without being overly long, but the brevity aids readability.
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 1-parameter tool with no output schema. However, lack of return value description may leave the agent uncertain about the output format.
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 'agent_id'. The tool description does not add any additional meaning beyond the schema, so baseline score applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get the current profile for an agent' clearly states the action (get) and resource (profile) with specifier 'for an agent'. It distinguishes from sibling 'update_profile' but is slightly redundant with the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives, no prerequisites or limitations mentioned. The only implicit guidance is from the readOnlyHint annotation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate mutation (readOnlyHint=false) and non-idempotency. The description adds context that the caller pre-computes data and that this is an archive operation. It does not explain the effect of multiple calls, overwriting behavior, or any side effects beyond archiving, but it is not contradictory.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, comprising two short sentences that convey the essential purpose and a key requirement. No unnecessary words or redundancy.
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 an output schema, the description should hint at what the tool returns (e.g., success status or episode ID). It does not. Additionally, it does not cover prerequisites like permissions or the effect of missing optional parameters. The description is too brief for the complexity of 7 parameters.
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 detailed descriptions for each parameter. The tool's description does not add per-parameter meaning, but the schema already provides adequate semantics. Baseline 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 action ('archive') and resource ('conversation episode'), and specifies that the caller pre-computes summary, keywords, and resolved status. It is specific enough to distinguish from sibling tools like 'delete_episode' or 'list_episodes', but does not explicitly contrast with them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that the caller must handle LLM processing before calling this tool, which is a usage guideline. However, it does not explicitly state when to use this tool versus alternatives, nor does it mention any prerequisites or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description describes an export operation, which is typically non-destructive. However, annotations set destructiveHint to true, implying the tool may have destructive side effects (e.g., file overwrite). The description does not disclose this, contradicting the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, straightforward sentence with no wasted words. It is front-loaded with the action and purpose.
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 mentions the data types exported (memories, episodes, profiles) and the format (JSONL), but does not address potential side effects like file overwriting despite the destructiveHint annotation. Given no output schema, more detail on the return value or behavior would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all three parameters (agent_id, output_path, include_embeddings) with descriptions. The tool description does not add additional 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 clearly states the tool exports memories, episodes, and profiles to a JSONL file for backup or portability. It uses a specific verb and resource, and distinguishes from siblings like import_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 provides context for when to use the tool (backup or portability) but does not explicitly state when not to use it or mention alternatives. Sibling list makes the purpose clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and readOnlyHint=false. The description adds that ownership is enforced when agent_id is provided, which is behavioral context beyond annotations. 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 a single, well-structured sentence with no wasted words. 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 description lacks details on return values, error handling (e.g., memory not found), or confirmation of deletion. Given no output schema, it should cover what to expect after invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema documents both parameters. The description reinforces the agent_id parameter's role in ownership enforcement, but adds no new semantics for memory_id beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it deletes a single memory by ID, using a specific verb and resource. It distinguishes from siblings like delete_episode or delete_agent_data by specifying 'memory'.
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 this tool is for deleting individual memories, but provides no explicit guidance on when to use it versus alternatives like delete_agent_data or lock_memory. The mention of ownership enforcement is helpful but does not cover exclusions.
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?
It discloses the sampling mechanism, the placement of the threshold above the null mean, the three statistical methods, and the absence of label usage, which goes well beyond the sparse annotations. It does not detail persistence or failure conditions, but the annotations already signal a non-read-only, non-idempotent operation.
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 purpose is front-loaded and the method explanations are technically dense, but they duplicate some of the schema's method description. The overall paragraph is efficient and well structured, with only minor redundancy preventing a 5.
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 5-parameter mutating tool with no output schema, the description covers methodology and method selection well but omits the expected return value or whether the calibrated threshold is persisted. Given that annotations and output schema are thin, these are meaningful gaps.
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%, so the baseline is 3, but the description adds meaning: it explains the zscore formula, says percentile is robust to anisotropic embedding models, and ties methods to null-pair populations. This helps an agent choose between methods beyond the schema's parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The opening sentence states a concrete action ('auto-calibrate') applied to a specific resource ('vector search threshold'), and the method breakdown makes the tool's scope obvious. This distinguishes it from sibling tools like set_recall_precision or get_recall_precision without needing schema inspection.
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 appropriate use through phrases like 'no labels used' and 'adapts to both embedding model and corpus characteristics', but it never explicitly says when to prefer this over manual threshold setters such as set_recall_precision. There is clear context, but no when-not-to-use or alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide destructiveHint and idempotentHint; description adds 'Used by kernel during agent deletion' but does not elaborate on behavioral aspects beyond what annotations convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no fluff, front-loaded with action and context. Every sentence serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple destructive operation with one parameter and no output schema, the description adequately covers purpose and usage context, though could mention irreversibility.
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 covers 100% of parameters; description does not add additional meaning beyond the schema's description of agent_id.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it deletes all data (memories, profiles, episodes) for a specific agent, distinguishing it from siblings like delete_episode and delete_memory.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly mentions 'Used by kernel during agent deletion', indicating when to use, but does not explicitly state when not to use or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description's addition of 'pending tasks, retry config' provides some context. However, it could be more transparent about the return format or any other behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence of 13 words. Every word is purposeful and concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, parameterless tool with readOnlyHint annotation, the description is fairly complete. It could benefit from specifying the output structure, but given no output schema, it's adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so baseline is 4. The description does not add parameter details, which is acceptable since there are none.
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 a specific verb 'Get' and resource 'background task queue status', and mentions what is included (pending tasks, retry config). This distinguishes it from sibling tools like check_health or list_episodes.
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 checking queue status but provides no explicit guidance on when to use it versus alternatives, nor when not to use it. No sibling comparisons mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already give idempotent, non-destructive, non-read-only hints. The description adds useful context: unlocking enables deletion/editing and ownership verification. It complements annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, no unnecessary words. Information is front-loaded with the main action first.
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 tool with 2 parameters and no output schema, the description covers purpose and a key condition (ownership). Could optionally mention response or error states, but overall adequate.
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 tool description does not add significant new meaning beyond what the schema already provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('unlock') and the resource ('memory'), and explains the purpose ('to allow deletion and editing'). It effectively distinguishes from siblings like lock_memory and delete_memory.
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?
Provides one usage condition ('Ownership enforced when agent_id provided') but does not explicitly state when to use this tool versus alternatives like lock_memory 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide destructiveHint=true and idempotentHint=true. The description adds value by disclosing ownership enforcement (agent_id) which is a behavioral constraint not captured in annotations. 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?
Two concise sentences front-loaded with the core action. No redundancy or superfluous 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?
For a simple delete-by-ID tool with detailed annotations and schema, the description is adequate. It covers the key behavioral nuance (ownership) but could mention deletion permanence or confirmation steps. Still complete enough for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter documented. The description reinforces the agent_id role ('ownership is enforced'), adding slight extra context beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'delete' and resource 'episode by ID'. It distinguishes from siblings like 'archive_episode' (non-destructive) and 'delete_agent_data' (bulk deletion). No tautology.
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 ownership enforcement when agent_id is provided, but does not explicitly state when to use this tool over alternatives like archive_episode or delete_agent_data. Minimal guidance on context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true. The description goes further by stating it never recalibrates or persists, and details the returned fields (beta, precision level, override flags). This adds behavioral context beyond the annotation, though it doesn't cover all edge cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph that front-loads the main purpose and then provides additional details. It is reasonably concise, though some sentences could be tightened. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple input (1 param, no output schema), the description thoroughly explains the return value and its relationship to the global default and override behavior. It is complete for a read-only tool of this complexity.
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 covers the single required parameter (agent_id) with a description. The tool description does not add meaning beyond that, but since schema coverage is 100%, a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads an agent's effective recall precision, identifies it as the read-back companion to set_recall_precision, and specifies it is read-only. This distinguishes it from its sibling and provides a specific verb-resource combination.
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 explains when to use this tool (as a read-back companion to set_recall_precision, for UI loading before editing) and implies it should be used before writing. However, it does not explicitly mention alternatives or when not to use it, though the sibling set tool is clearly the counterpart.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag mutability and idempotency, and the description adds concrete deduplication behavior: memories by msg_id/content and episodes by summary within a project/channel. This is genuinely useful for understanding re-import behavior, though it does not mention output format or any profile-specific dedupe rules.
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 compact sentences, with the primary action front-loaded and the idempotency behavior placed second. Every word contributes meaning; no filler or redundancy exists.
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 moderately sized import tool, the description plus schema cover the core use case, input path, preview mode, agent remapping, and idempotent behavior. Since there is no output schema, some return-value details are absent, but the tool is still well-enough described for an agent to select and invoke 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?
The schema descriptions cover 100% of the parameters, so the description does not need to restate them. The description provides helpful idempotency context but adds no additional parameter-level meaning beyond what the schema already documents.
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 starts with a specific verb ('Import'), names the resources ('memories, episodes, and profiles'), and identifies the input format ('JSONL'). This clearly distinguishes the tool from siblings like export_memories or list_memories, and the dedupe statement adds further scoping.
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 imported use case is clear: load memories/episodes/profiles from a JSONL file, possibly repeated safely due to idempotency. It does not explicitly name alternatives such as merge_memories or state when not to use the tool, but the stated scope and input format make the usage context reasonably obvious.
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?
Adds atomicity, one-shot nature, and dedup details beyond annotations (destructive hint, idempotent hint). Clarifies that 'move' mode deletes source data.
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, front-loaded sentences: core purpose first, then atomicity and strategy nuance. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, atomicity, and strategy detail. No output schema, but description doesn't need to explain returns. Missing error handling or prerequisites, but adequate for a merge 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%, but description adds specific dedup criteria (msg_id for memories, summary for episodes) for the strategy parameter, enhancing schema info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it merges memories, episodes, and profiles from one agent into another, and distinguishes from export→import by being atomic and file-less.
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?
Implied usage as an alternative to export+import, but no explicit when-to-use, when-not, or guidance on selecting between merge and the export/import siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate idempotentHint=true and not destructive. The description goes beyond annotations by detailing rejection conditions, ownership verification, sanitizer behavior (length cap, truncation flag, annotation stripping), and refusal of empty content. This provides significant behavioral transparency, though the success response is not fully described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no wasted words. The first sentence front-loads the core purpose, and the second efficiently packs important behavioral details. Every sentence earns its place.
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 100% schema coverage, no output schema, and annotations present, the description covers rejection logic, ownership, and sanitization. It partially describes the response (truncation flag). However, it omits success response fields and does not mention what happens on success, leaving a minor gap for a mutation 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%, but the description adds extra context: 'Rejects if memory is locked' relates to the operation on memory_id, 'Ownership enforced when agent_id provided' clarifies agent_id's role, and sanitizer details explain constraints on content. This adds meaning beyond the schema's brief descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Update memory content by ID,' which is a specific verb-resource pair. It clearly distinguishes from sibling tools like store, delete_memory, and lock_memory by focusing on an existing memory identified by ID.
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 context about when the tool will reject (memory locked) and ownership enforcement, but lacks explicit guidance on when to choose this over alternatives like store (for new memories) or delete_memory. No exclusionary language or alternative tool references are given.
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?
Even with readOnlyHint=true, the description goes far beyond that annotation to explain the honored content budget, newest-first ordering, row-degradation mechanics, preview cap, suffix fields, ref expansion behavior, and budget_chars presence. It also covers edge cases like all-agent listings and preview-cap-0 disabling trimming. This is exemplary behavioral disclosure — the agent is fully informed about response size limits, truncation, and associated fields without having to guess.
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 long and dense, but it front-loads the core purpose in the first sentence, then structures the rest around the bug-255 behavior and its consequences. The detail is necessary for a tool with no output schema, and the organization (budget → degradation → edge cases) makes it navigable. It could arguably be trimmed, but the density is justified by the complexity of the response contract.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, this description carries the full burden of explaining the response shape — and it does so thoroughly: rows, degradation conditions, truncation fields, ref expansion, budget_chars, and the scaling ceiling. It also covers the all-agents pairing nuance and the preview-cap edge case. The description is complete enough for an agent to correctly interpret and invoke the tool, including handling the 'ref' expansion via get_contents.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage for all three parameters (limit, agent_id, project_id), each with descriptive text — project_id's is especially detailed. The tool description adds zero parameter-level information; it focuses entirely on response behavior. Per the rubric, with schema coverage >80%, a baseline of 3 is appropriate, and no extra value is added here.
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 opens with a clear verb-object pair — 'List recent memories for an agent' — and adds the dashboard-display context, making the tool's primary function unmistakable. While it doesn't name sibling tools, the distinction from recall/store/get_contents is evident from 'list recent' versus retrieval/storage actions. The purpose is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states a clear use case: 'for dashboard display,' which implicitly signals this is for lightweight listing rather than full recall. It does not explicitly name alternatives or exclusionary conditions (e.g., 'use recall for full content'), but the dashboard-display context implies a preference for this tool over more memory-heavy operations. The guidance is adequate but could be stronger with an explicit 'use this when…' statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description complements annotations: it confirms mutation (consistent with readOnlyHint=false) and non-destructive (destructiveHint=false). It adds ownership enforcement detail not in annotations. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with no superfluous words. Front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with no output schema, the description covers the essential purpose and a key condition. It lacks details on return values or error cases, but the tool's simplicity may not require it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema covers both parameters with descriptions (100% coverage). The description adds value by clarifying the role of agent_id in ownership enforcement, which is not in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (lock), resource (memory), effect (prevent deletion and editing), and a key condition (ownership enforcement). It distinguishes from sibling tools like 'unlock_memory' and 'delete_memory'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (to prevent deletion/editing) and mentions ownership enforcement, but does not explicitly state when not to use or compare to alternatives beyond the sibling list context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare readOnlyHint=true. The description adds valuable behavioral detail: the state is process-wide and shared across sessions in streamable-HTTP deployments, which is beyond what annotations provide.
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 that front-load the core purpose and then add important context about scope. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description could explicitly state the response structure (e.g., `{paused, ttl_remaining}`), but it clearly conveys what is reported and the TTL unit. Adequate for a simple status tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters (coverage 100%), so the description need not add parameter details. The description focuses on output semantics, 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 reports whether persistence is paused and the TTL remaining in seconds. It specifies process-wide scope, distinguishing it from siblings like pause_persistence and resume_persistence.
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 explains the scope (process-wide) and notes that `paused: true` may be set by another session in streamable-HTTP deployments. While it does not explicitly state when to use vs alternatives, the context is clear for a status check tool.
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?
The description goes well beyond the readOnlyHint annotation by disclosing default preview-tier content, the 200k-character full_content budget behavior, match_reason signal branches, and gate_fallback semantics. This gives the agent an accurate model of the tool's runtime behavior and edge cases.
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 dense and front-loaded with the core purpose, and every sentence adds information. It is not short, but the length is justified by the tool's complexity; minor version/issue references add noise but do not undermine readability.
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?
Without an output schema, the description explains critical response behaviors: match_reason content and signal ordering, unscored rows, gate_fallback, and full_content_budget_chars. It also ties the result preview/ref flow to get_contents, making the tool usable for an agent.
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% with detailed parameter descriptions, so the baseline is 3. The description adds meaningful extra semantics for full_content by explaining the response-level budget and degradation to preview tier, which is absent from the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Recall relevant memories using multi-strategy search (vector + FTS5 + keyword)', giving a specific verb, resource, and method. This clearly distinguishes the tool from sibling tools like list_memories or store, and the preview-tier/get_contents relationship adds further operational 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 retrieval-focused first sentence implies when to use the tool, and get_contents is mentioned for expanding selected rows. However, there is no explicit guidance about when to choose recall over recall_with_context, list_memories, or other memory tools, nor any exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide idempotentHint, destructiveHint, readOnlyHint. Description adds key behavioral info: clears TTL, returns was_active flag, and process-wide effect. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no waste. First sentence states action and return value; second sentence adds critical scope detail. Well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers action, return value, and scope. Lacks details on error states or what happens if persistence already active, but sufficient for a simple tool with no parameters.
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 schema coverage is 100%. Description adds no param info but baseline is 4 for zero-param tools.
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 'Re-enable persistence' with the resource being persistence state. It distinguishes from sibling tools like pause_persistence and persistence_status by focusing on resuming.
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 explains when to use (when persistence is paused) and highlights the process-wide scope, guiding agent context. It lacks explicit when-not-to-use but is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare idempotentHint=true and destructiveHint=false, and the description aligns with this: setting precision is idempotent and not destructive. The description adds valuable behavior: effect is immediate and persisted without restart, and the gate is precomputed on the separation curve, meaning the change is live. It also clarifies the override-clearing side effect, which is important behavior. Minor, but it could have explicitly stated that no confirmation or output is returned, given no output schema, so a 4 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense and packed with essential information, but it is a single long paragraph. It front-loads the core purpose and immediately explains the main knob, but the second sentence is quite long and mixes multiple concepts (mapping, formula, override, default). It could be broken into shorter sentences for readability, but every sentence earns its place. A 4 is fair.
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 that this is a simple configuration tool with 3 parameters, 100% schema coverage, no output schema, and annotations covering idempotency/destructiveness, the description is complete. It explains what happens immediately, how the override works, when to use which mode, and the relationship to the global default. Nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the schema descriptions are already clear (e.g., beta raw override, precision enum, agent_id). The description adds mapping of the three named levels to specific beta values (2.0/1.0/0.5) and the formula, which goes beyond the schema, but the core parameter roles are already well-documented. So a 3 is fair.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb (set/recalibrate), a clear resource (agent's recall precision, 'knob 3'), and immediately defines the three levels plus the beta semantics. Even though the sibling set includes get_recall_precision and calibrate_threshold, this description's emphasis on per-agent precision versus per-recall arguments and its mention of 'recalibrates once' distinguishes it from the threshold-calibration sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly explains when to use the named level (strict/balanced/lenient maps to beta), when to use a raw beta override (beta > 0), and when to clear the override (empty precision with beta <= 0 returns to the global default). It also states that precision is a per-agent setting, not a per-recall argument, which implicitly distinguishes this tool from recall-related siblings. This is near-explicit 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?
The annotation readOnlyHint=true is complemented by a detailed exposition of response-size budget, degradation semantics, truncation markers, and conditional budget_chars. The description also discloses special-case behavior (literal '@auto' resolution, no warning). This is transparent about the tool's behavior beyond the schema.
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 technically dense but effective numerically; the leading sentence furnishes the purpose ('dashboard display') and the exotic details (budget, ref) are packed after. A slight con: it jumps into bug/history references (bug-255, v2.4.7) that might confuse a simple agent, but the structure is 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?
Without an output schema, the description compensates by explaining the response layout (summary/keywords truncation, budget_chars presence, ref expansion). It also cross-references get_contents and export_data for full data, so the agent knows how to recover details. The complexity of the tool is well covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All three parameters have schema descriptions, but the tool description adds significant semantic depth, particularly for project_id: explaining the '@auto' sentinel, resolution edge cases, and referring to list_memories for same semantics. This goes well beyond the generic schema description.
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?
States the verb 'list' with a specific resource ('archived episodes for an agent') and qualifies the scope ('for dashboard display'). It distinguishes itself from list_memories and mentions export_data for full keyword data. However, it doesn't explicitly name sibling alternatives for the list function; it clarifies what it is not for related 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 clear when-to-use context (dashboard display) and directs the agent to alternative tools for expansion (get_contents) and full data (export_data). Yet it still lacks a formal exclusion framework (e.g., 'use export_data when full keywords are needed') in the imperative; but the info about ref and keywords hint is present.
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?
Beyond the readOnlyHint annotation (false), the description adds crucial behavioral details: non-destructive (only channel column changes), idempotent, dry_run behavior, and unrecoverable bucket handling. This fully informs the agent of side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is detailed but each sentence conveys essential information. It is front-loaded with the core purpose and then elaborates on nuances. Some jargon ('knob2 v2 default flip prep') may reduce clarity for some agents.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (3 params, no output schema, many siblings), the description covers behavior in dry run vs. real run, idempotency, and unrecoverable handling. It could mention expected return format, but the description adequately informs the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides descriptions for all 3 parameters (100% coverage). The description adds extra context, such as the purpose of dry_run and globalize_unrecoverable, and explains the unrecoverable bucket, which enhances understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: migrating bridge-type memories to concrete channels, with specific details about the bridge type 'discord' and the session_id format. It distinguishes itself from sibling tools by describing a unique operation.
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 context on when to use the tool (e.g., for knob2 v2 flip prep) and explains behaviors like dry_run and globalize_unrecoverable. However, it does not explicitly contrast with sibling tools or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint=false, idempotentHint=true, destructiveHint=false), the description richly details behavior: all result branches ('stored', 'skipped', 'rejected'), dedup and TOCTOU seams, embedding semantics under EMBEDDING_MODE=none, persistence pause behavior, and legacy schema changes. This goes far beyond what the annotations alone convey and provides actionable operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but deliberately structured and front-loaded: purpose first, then the actionable result field, then enumerated branches with examples. Every sentence carries semantic weight; the version migration and TOCTOU notes earn their place given the tool's complexity.
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 complex write tool with no output schema, the description covers response branches, error semantics, idempotency behavior, persistence controls, and legacy compatibility. It also references check_health and pause_persistence, tying into sibling tools. The schema supplies parameter details, and the description supplies the runtime behavior needed to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The tool description adds meaningful behavior tied to parameters, such as empty content causing rejection, operating-context project_id refusal, and pause_persistence affecting writes. These enrich the schema without merely repeating it, though much of the per-parameter nuance already lives in the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource: 'Store a message in agent memory for future recall.' It further clarifies scope by stating the success result is 'a new row was written,' distinguishing this from update/merge/recall siblings. The purpose is unambiguous and not a tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for the write operation and guides the caller to branch on 'result' and 'persisted'. However, it does not explicitly state when to prefer this tool over siblings like update_memory or merge_memories, nor does it provide exclusions. Usage is implied rather than directly contrasted with alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false and destructiveHint=false, and the description adds value by disclosing the sanitizer, the 2000-character cap with constant name, and the truncated:true response flag, instructing the agent to branch on it and noting the remainder is discarded. This goes beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with dense but relevant information. Front-loads the main action, then details edge behavior. No wasted words, though the first sentence is long.
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 two-parameter update tool with no output schema, the description covers key behavior (sanitizer, truncation, flag). It could mention upsert or error conditions, but these are not strictly required given 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?
Schema coverage is 100%, so the schema already describes both parameters. The description adds context about the sanitizer and the truncated behavior, but mostly reiterates the cap and truncated flag already in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Save a pre-computed agent profile to the database' with a specific verb and resource, and differentiates from siblings by noting the profile's own ceiling and referencing store's sanitizer.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It implies usage by specifying 'pre-computed' profile and the cap behavior, but does not explicitly state when to use store vs update_profile or any exclusions. Context is clear though.
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?
Goes far beyond the readOnlyHint annotation by disclosing two independent bounds (20 refs and 40,000 chars), the deferred return field and budget_chars, the never-cut behavior, the special case of a single row exceeding the budget, and the ownership check via agent_id that results in missing. This level of behavioral detail is exceptional.
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 dense and every sentence provides meaningful detail about limits, edge cases, and the deferred mechanism. It is longer than average, but the complexity of the tool justifies the length; the version reference '2.5.4a2' adds specificity without being redundant.
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 multi-bound behavior, deferred refs, budget semantics, and the absence of an output schema, the description covers all critical runtime behavior, edge cases, and the ownership check result. The agent receives everything needed to invoke the tool correctly and interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and both refs and agent_id are already well-described in the schema. The description adds contextual behavior (deferred, missing) but does not add new parameter-level semantics, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Fetch full, untrimmed content for recall preview refs', which clearly specifies the action, resource, and scope. It also distinguishes this tool from the preview-tier recall flow by positioning it as the targeted expansion path, differentiating it from sibling tools like recall and recall_with_context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use the tool ('Use after a preview-tier recall to expand only the rows that matter') and names the alternative approach ('instead of opting the whole recall out with full_content=true'). Also gives operational guidance about re-fetching deferred refs in a second call.
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?
Beyond the readOnlyHint annotation, the description discloses automatic deduplication, chronological sorting, preview-tiering, external_context filtering and role-based merging, the context_filter_only response field, and gate_fallback low-confidence semantics. This is rich behavioral context that goes far beyond what annotations alone provide.
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 dense but well-structured, with the purpose front-loaded and subsequent sentences covering important behavioral details and edge cases. It is longer than a minimal description, but every sentence carries substantive information for a complex tool.
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 complexity and the absence of an output schema, the description explains key response signals (context_filter_only, gate_fallback), preview-tiering behavior, external_context role handling, and the relationship to recall's budget. This is sufficient for an agent to understand the tool's behavior and edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all 9 parameters, so the baseline is 3, but the description adds meaningful semantics for external_context (every entry's content filters recall, only user/assistant entries merge into messages) and full_content (shares recall's 200k-char response budget). This adds value beyond the schema's field descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Recall memories and merge with external conversation context' and explicitly says it 'Replaces separate recall + manual merge in the caller,' clearly distinguishing this tool from sibling tools like recall and merge_memories. The verb-resource pair is specific and the scope is immediately understandable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear usage context by stating that this tool replaces the separate recall + manual merge flow, and points to recall's full_content / get_contents for full-content needs. However, it does not explicitly state when to prefer plain recall over this tool or 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description thoroughly discloses behavior: fix parameter triggers repairs for anonymous_source and short_content; other checks are report-only even if fix is true. This adds context beyond the readOnlyHint annotation, which is false, and aligns with the described mutation when fix=true.
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 relatively concise for the complexity, with the purpose front-loaded in the first sentence. Some redundancy exists (e.g., listing checks twice), but it remains efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers tool behavior well, including fix vs. report-only and how to handle report-only issues via other tools. However, it lacks explicit mention of output format (e.g., returns a report/preview), which would make it fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all three parameters (100% coverage). Description adds behavioral details: fix behavior for specific checks, checks parameter options listed explicitly, and explains that empty means all checks. This supplements the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies a clear purpose: 'deep heuristic analysis of memory data quality'. It lists specific detected issues and distinguishes from sibling tools by detailing actionable checks and linking to other tools for non-repair actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit when-to-use guidance: explains that fix=true applies repairs to specific checks, while others are report-only with directions to use sibling tools (merge_memories, delete_memory, etc.) for those decisions. Also mentions checks parameter to select specific checks.
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?
The description not only aligns with the readOnlyHint annotation but adds significant context: the context is edited on the filesystem (~/.cpersona/operating-context.toml), never via MCP. This discloses the source of truth and mutation path, which annotations alone do not provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences, front-loaded with the core purpose, followed by mode details and behavioral note. No wasted words. Structure is logical: what, how, important note.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given one optional parameter, no output schema, and full annotations, the description covers all necessary aspects: return types (preview tier components, full section body), usage modes, and behavioral constraints (read-only, filesystem editing). It is sufficient for an AI agent to correctly invoke this 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% with a description for the 'section' parameter. The description adds value by explaining the default behavior (preview tier) and that the section is from 'doctrine_sections'. It clarifies the parameter's effect beyond the schema's own description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads the 'server-served operating context' with a specific version (v2.5.1). It identifies the resource and its nature as 'operator-owned doctrine'. This is specific and distinct from sibling tools like 'get_profile' or 'get_contents'.
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 the two modes: without arguments returns the preview tier, and with a 'section' argument returns the full body. It mentions read-only and that editing is done via filesystem, not MCP. While it doesn't contrast with siblings, it provides clear usage context.
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?
The description extensively discloses behavioral traits: the tool can auto-repair (mutating, not read-only, consistent with readOnlyHint=false), some repairs are lossy and irreversible with caps, repairs are bounded per run and require re-running if `remaining` > 0, and unknown check names are rejected. It also explains the change in status reporting (healthy boolean removed), which adds context beyond the basic annotation.
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 information-dense and structurally sound, but it is quite long and covers many details that could be split into clearer sections. It front-loads the core purpose and health check list, but the later parts on fixes and status evolution are verbose. While every sentence adds value, the length might reduce readability for an agent scanning quickly.
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 complexity (multiple checks, fix modes, cap limits, re-run conditions, status derivation), the description is thorough and covers edge cases like irreversible repairs and the pre-version status boolean. It does not have an output schema, so the description compensates by detailing return fields (`status`, `issues`, `severity_summary`, `remaining`, `checks_run`) and their meanings, making it complete for an agent to invoke and interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
While the schema describes each parameter briefly, the description adds significant meaning: `fix` is explained as auto-repair with lossy consequences, `checks` lists how to use it (subset, unknown rejection, `checks_run` echo), and `agent_id` is simply 'Agent ID' but the description implies agent-scoped behavior in the health checks. The description enriches understanding beyond the schema's basic descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the verb ('check') and resource ('memory database health'), enumerates the specific kinds of issues detected, and distinguishes it from sibling tools like deep_check by detailing the exact health checks performed. It goes beyond a generic purpose by naming concrete checks and outputs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use the tool, including details on using the `checks` parameter to run a subset and the behavior of `fix=true` for auto-repair. It also clarifies the difference from the removed `healthy` boolean and how to interpret results, which helps the agent decide when to invoke this tool versus alternatives.
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?
The description goes far beyond the annotations (readOnlyHint=false, idempotentHint=true, destructiveHint=false) by detailing the exact no-op response format (persisted: false, dry_run: true, reason), how specific tools behave differently (migrate_channel_axis, health checks), the process-wide scope, and the implications for multi-client deployments. It provides comprehensive 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is lengthy but well-structured with clear sections and formatting (bold, code). It front-loads the main action and provides detailed breakdowns. While some redundancy exists, every sentence earns its place given the complexity of the tool's behavior.
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 high complexity (affects many tools, different behaviors for different actions, process-wide scope, deployment variations), the description is extremely comprehensive. It covers all relevant aspects, including response format, scope, affected tools, and edge cases (migrate_channel_axis, health checks), leaving no significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter (ttl_seconds) with full coverage (description, default, min, max). The description adds context by specifying the default TTL (1800s), upper bound (86400s), and that the TTL remaining is included in the response reason. This adds value beyond the schema definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Pause write operations on this MCP server for an opt-in TTL window.' It explicitly names the resource (write operations on the MCP server) and provides extensive detail about which tools are affected and how they respond, distinguishing it from siblings like resume_persistence and persistence_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool: 'Use for benchmarking, AB testing, or ephemeral exploration where memory contamination must be avoided.' It also contrasts with other tools (e.g., cscheduler's pause_persistence) and explains the scope differences between streamable-HTTP and stdio deployments, providing clear when-to and when-not-to guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![CPersona MCP server](https://glama.ai/mcp/servers/Cloto-dev/CPersona/badges/card.svg)](https://glama.ai/mcp/servers/Cloto-dev/CPersona)

Score Badge

Copy to your README.md:

[![CPersona MCP server](https://glama.ai/mcp/servers/Cloto-dev/CPersona/badges/score.svg)](https://glama.ai/mcp/servers/Cloto-dev/CPersona)

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/Cloto-dev/CPersona'

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