loom

Server Quality Checklist

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

Latest release: v0.4.1
Disambiguation5/5
Every tool has a clearly distinct purpose, with detailed descriptions that differentiate even closely related operations like memory_propose vs memory_ratify and knowledge_merge vs knowledge_supersede. There is no ambiguity between tools.
Naming Consistency5/5
All tools use a consistent snake_case verb_noun pattern (e.g., knowledge_write, memory_archive). Even standalone verbs like recall and remember fit the pattern as primary actions. No mixing of conventions.
Tool Count2/5
With 31 tools, the server exceeds the recommended range for well-scoped servers. While the tools are organized into subsystems, the sheer number suggests potential over-engineering or unnecessary granularity.
Completeness5/5
The tool surface covers full lifecycle management for identity, episodic memory, and structured knowledge, including create, read, update, delete, archive, restore, merge, and auditing. No obvious gaps are present.
Average 4.3/5 across 31 of 31 tools scored. Lowest: 3.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 35 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under AGPL 3.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It describes the tool as retrieving memories but does not disclose how matching works, whether it is read-only, or any behavioral traits such as authentication, rate limits, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the core purpose, and contains no redundant information. Every sentence serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description leaves out important context: return format, pagination behavior, and the nature of 'matching'. For a retrieval tool with 4 parameters, more completeness is needed for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds no additional meaning beyond the schema's parameter descriptions, which are already clear. It simply restates the purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (retrieve memories) and resource (relevant to a query or topic). However, it does not distinguish the tool from similar siblings like find_similar or knowledge_recall, which also retrieve memories.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a usage hint ('Use this when you need context from past sessions') but lacks explicit when-not-to-use or comparisons with alternative tools, especially given the many memory-related siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully convey behavioral traits. It mentions persistence across sessions but does not disclose side effects (e.g., overwriting, expiration via TTL, or authentication needs). The description lacks detail on what happens after storage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loading the action and purpose. Every sentence carries weight with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters (including enums and nested objects) and no output schema, the description is minimal. It does not explain return values or post-invoke behavior, relying heavily on the schema. Adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The tool description adds no extra meaning beyond what the schema already provides for parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Store' and the resource 'an episodic memory that persists across sessions', distinguishing it from sibling tools like 'forget' or 'recall'. It also provides a concrete usage scenario ('when you learn something important...').
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use the tool ('when you learn something important...'), providing clear context. However, it does not mention when not to use it or compare it to alternatives like 'knowledge_write'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the read-only nature and outlines three analysis branches, which is helpful. However, with no annotations provided, it lacks details on permissions, rate limits, side effects, or output structure. The read-only claim is clear, but deeper behavioral traits are missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loading the core purpose and branching structure, then a practical pairing note. Every sentence adds value without redundancy. Highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's purpose and three branches, but lacks details on output format (no output schema) and specifics for the misfile audit branch. Given the complexity and 30 sibling tools, more context on return values and branch details 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?
All three parameters have schema descriptions (100% coverage), so the description adds little new detail. It does conceptually map parameters to branches (e.g., cold_days to cold pages), but this is implicit. 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 this is a 'Read-only health report for the knowledge store' with three specific branches: expansion candidates, cold pages, and misfile audit. It distinguishes itself from sibling tools like knowledge_write by pairing with it for acting on findings, making the purpose very specific and differentiated.
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 notes it is 'read-only' and suggests pairing with knowledge_write to act on findings, providing clear when-to-use guidance. However, it does not explicitly exclude other use cases or mention alternative tools for similar tasks (e.g., knowledge_recall for retrieval), leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It mentions listing with filters but does not describe pagination, ordering, or return structure. Adequate but missing some details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core purpose. Every word adds value. No redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose and use cases but does not explain output format, default behavior (e.g., limit default), or pagination. Adequate for a simple list tool but could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description echoes the schema's filter parameters without adding significant new meaning. Acceptable but not enhanced.
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 lists memories without semantic search, with optional project/category filters. It distinguishes itself from semantic search tools like 'recall' or 'find_similar'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides use cases (auditing, maintenance, discovery) and implies when not to use (when semantic search is needed). It doesn't explicitly name alternative tools but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the burden. It describes the return content (creed, memories, etc.) but does not disclose side effects, idempotency, permissions, or rate limits. It implies a read operation but lacks full behavioral detail.
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 sentences with no fluff, front-loaded with purpose, and includes an imperative callout. Every sentence is meaningful 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?
The description explains what the tool does, when to use it (first), and what it returns. Lacks output structure details but is otherwise complete given the tool's complexity and the presence of sibling tools for identity management.
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 each parameter having a description. The tool description adds context about the purpose but does not enhance parameter semantics beyond the schema. 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 tool loads persistent identity and returns creed, memories, preferences, and self-model. It distinguishes itself from sibling tools like 'update_identity' by emphasizing it should be called first.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs 'Call this tool FIRST before doing any other work', providing clear usage context. Does not mention alternatives or when not to use, but the 'first' directive is strong guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description fully carries the burden. Discloses clear behavioral traits: clears archive flag and tombstone note, restores visibility to multiple operations. Lacks details on permissions or error handling, but sufficient for simple mutation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero waste. Front-loaded with action and clear effects. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description explains return effect adequately. Covers what happens when restored. Could mention what happens if memory is not archived or if ref is invalid, but overall complete for a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, all parameters have descriptions. Description adds no additional meaning beyond schema. Does not explain which parameter combination is required (ref vs title+category) or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'Restore' and resource 'previously archived memory to active set'. Distinguishes from sibling tools like memory_archive (archive) and knowledge_restore (different resource). Provides specific actions: clears archive flag and tombstone, makes visible to recall/list/audit/find_similar.
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: use for restoring previously archived memories. No explicit when/when-not or alternatives. Could mention that it only works on archived memories and that the opposite is memory_archive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility for behavioral disclosure. It explains that replace-writes snapshot the displaced body into page_revisions (capped) and that restore snapshots first, making it non-destructive. It does not cover error handling, auth requirements, or rate limits but provides sufficient insight for safe usage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with three sentences that front-load the core purpose and efficiently explain all modes. No extraneous information; every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main functionality but lacks details on output format for listing (what metadata?) and reading (body format?). It also does not specify the result of a restore operation. Given no output schema, more detail would improve completeness.
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 parameters are documented. The description adds value by explaining the three usage modes, how parameters combine (e.g., restore requires revision_id), and the behavior of each combination. This goes beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is for 'Body-revision history for a knowledge page' and details three distinct modes: listing snapshots, reading a snapshot, and restoring. It effectively distinguishes from sibling tools by focusing on revision history and recovery.
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 each mode: slug alone for listing, slug+revision_id for reading, and adding restore:true for restoration. It also notes that restore is never destructive, providing guidance. However, it does not explicitly contrast with alternative tools or specify 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully bears the burden of disclosure. It reveals side effects: 'Clears the archive flag and tombstone note. The page becomes visible to knowledge_recall and knowledge_maintain again.' This provides useful behavioral context beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, direct, and front-loaded with purpose. Every sentence adds value with no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple restore tool with one required parameter and no output schema, the description is complete. It explains the action, what is cleared, and the effect on visibility, leaving no critical gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with a clear description for the only parameter (slug). The tool description does not add extra meaning beyond what the schema 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 tool's purpose: 'Restore a previously archived knowledge page back to active status.' The verb 'restore' and resource 'knowledge page' are specific, and it naturally distinguishes from siblings like knowledge_archive (archive) and knowledge_purge (delete).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when you need to unarchive a page) but does not explicitly state when not to use it or compare with alternatives like knowledge_recall for active pages. Usage context is clear but not comprehensive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It mentions updating content and metadata but does not specify side effects, authorization requirements, or whether the operation is idempotent. More detail would improve transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, each providing essential information without redundancy. It is concise and front-loaded, making it easy to read.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, and the description does not mention what the tool returns (e.g., success indicator, updated memory object). Given the complexity and number of parameters, the description could be more complete by indicating the return value.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so the schema already explains parameters well. The description adds value by clarifying how to find the memory and what operations are possible (replace content, update metadata, or both), which is beyond the raw schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool updates an existing memory, specifies how to find it (by ref or category+title), and what can be updated (content, metadata, or both). This distinguishes it from siblings like 'remember' (create) and 'forget' (delete).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides guidance on how to identify the memory to update (by ref or category+title), which is helpful. However, it does not explicitly state when not to use this tool or compare with other update-like siblings such as 'knowledge_merge' or 'memory_ratify'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description discloses key behaviors: generates specific files, does not overwrite without force, and returns setup instructions. There is slight ambiguity about the 'onboarding interview' process (assumed automatic), but overall it's transparent about side effects and conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences efficiently convey the purpose, generated artifacts, conditional behavior, and return value. No redundant words or fluff, earning a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main workflow and key behavior (no overwrite unless force). However, it does not detail the return format of 'setup instructions' or specify error handling for existing files without force. Given the absence of an output schema, slightly more detail could be useful, but it's sufficient for a bootstrap tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description adds no extra meaning beyond what the schema already provides for each parameter. The description mentions the files generated but does not elaborate on how parameters influence the output, which is fine given the schema completeness.
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 initializes a new loom identity from scratch, listing the specific files generated (IDENTITY.md, preferences.md, self-model.md) and the return of setup instructions. This distinguishes it from sibling tools like 'identity' (likely read) and 'update_identity' (modify).
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 it's for initial creation by saying 'from scratch' and specifies it won't overwrite existing files unless force is true, giving context on when to use the force parameter. It lacks explicit mention of alternatives or when not to use, but the context is clear enough for an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full weight. It discloses that the tool returns a third-person brief and includes the push-back mandate, and implies a read-only operation. However, it does not explicitly state side-effect safety or other behavioral constraints beyond what is implied.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at two sentences, front-loading the core purpose and key behaviors (third-person framing, push-back mandate). Every sentence adds critical information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's primary function, return content, and important contextual details (push-back mandate, optional addendums, environment overrides). With no output schema, it provides sufficient understanding, though it could be more explicit about output format and effects of all optional 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?
Schema coverage is 100%, so parameters are documented in the schema. The description adds value by explaining how each parameter integrates into the dossier loading process (e.g., role appends a role brief, model and client override environment variables). This goes 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?
Description clearly states the verb 'Load' and the specific resource 'Art's operating brief'. It distinguishes this tool from siblings by specifying it returns standards, taste, and constraints framed for non-Art agents, which is unique among the listed siblings.
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 tool's purpose: to provide Art's operating brief for worker bodies. It includes a specific behavioral mandate (push-back). However, it does not explicitly state when not to use it or mention alternatives among siblings, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description adds behavioral context like 'Self is always excluded when ref is given', but does not specify if the operation is read-only or has side effects. Acceptable but could be more thorough.
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, each adding value: purpose, usage context, and parameter distinction. No redundant or irrelevant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers main behavior and parameter usage well. No output schema, so return format is not described, but the complexity is moderate and the description is sufficient for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions; description adds context that ref and text are alternative anchors and that self is excluded for ref, going 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?
Description clearly states verb 'surface' and resource 'memories semantically near an existing ref or free-form text', distinguishing it from sibling tools like recall or memory_list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly recommends use 'during consolidation/dream workflows to find overlap and dedupe candidates', and distinguishes between ref and text anchors. Lacks explicit when-not usage compared to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that proposals are invisible until ratified, validation occurs at ratification time, and that drafts may be rough. This provides necessary behavioral context beyond just the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, no filler. The first sentence states the core purpose, second explains implications, third gives usage context. Very concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a proposal/draft tool, the description covers lifecycle (invisible until ratification), validation timing, and use case. No output schema is needed. It is sufficiently complete for an agent to understand the tool's role and behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description does not add extra semantic meaning to the parameters; it only contextualizes the tool's purpose. 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 tool stages a DRAFT memory in a capture-propose queue for later ratification. It distinguishes itself from authored memory by explaining proposals are invisible to recall, memory_list, etc. The verb 'stage' and resource 'DRAFT memory' are specific and differentiate it from sibling tools like memory_ratify.
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: 'when a background lane wants to suggest a write without committing it'. It implies the alternative is ratification via memory_ratify. While it doesn't explicitly list exclusions or alternative tools, the context is clear enough for an agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries burden. It discloses listing behavior when parameters omitted and immutability of IDENTITY.md. Lacks detail on destructive effects, auth requirements, or rate limits, but such might be implicit.
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 sentences, front-loaded with purpose, then targeting detail, then usage tip. Every sentence adds value with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters, no output schema, and no annotations, the description covers purpose, usage, and parameter behavior. Immutability note adds completeness. Could mention response format, but not essential.
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%; description adds context: 'Call without section/content to list' and 'Targets H2 sections', which clarifies parameter usage beyond 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?
Clearly states it updates self-model or preferences with section-level precision, distinguishing it from siblings like the generic 'update' tool. The verb 'update' and resource 'identity files' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance: call without section/content to list sections, and notes IDENTITY.md is immutable. Missing explicit when-not-to-use compared to alternatives, but context from sibling tools and description is sufficient.
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?
Discloses body replace vs append, citation dedup, provisional storage for conversation-only citations, and requirement for at least one citation. No annotations provided, so description carries full burden. Does not mention rate limits or auth, but covers key behaviors.
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?
Four sentences, front-loaded with core purpose. Each sentence adds specific behavioral info. Could slightly condense, but efficient overall.
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 7 parameters and no output schema, description covers upsert mechanics, mode, slug, citations, and epistemic gate. Missing return value or error handling, but sufficient for an agent to use 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% with detailed descriptions. Description adds value by explaining mode default, slug derivation, domain hierarchical nature, and the effect of all-conversation citations on storage. Enhances beyond 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?
Clear verb 'Upsert' and resource 'entity page by slug'. Distinguishes from siblings like knowledge_recall (retrieve) or knowledge_merge (merge). Specific about behavior on existing vs new slugs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when not to use: 'if it is about Jonathan or our work, store it in memory instead'. Describes epistemic gate for provisional storage. Could mention alternative tools, but the context is implied.
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?
With no annotations provided, the description fully carries the burden of behavioral disclosure. It details the write path (same as 'remember'), validation that can fail, and downstream effects: memory becomes recallable, proposal removed from queue. This transparency is thorough and accurate for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph of 4 sentences, each sentence adding unique value: core action, process details, failure behavior, and final consequence. It is front-loaded and efficiently communicates key information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool lacks an output schema, and the description does not state what the tool returns on success (e.g., the memory ID or confirmation). While it explains the effect ('memory becomes recallable'), the absence of return value information leaves a gap. Additionally, it could better contextualize the tool within the broader set of sibling tools, though it adequately explains its core role.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents each parameter. The description adds only a high-level reference to 'optional overrides' but does not provide new semantics beyond what 'Override the proposed...' already states. Thus, 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 tool ratifies a pending proposal into a real memory, using specific verbs like 'ratify', 'loads', 'applies overrides', and 'commits'. It distinguishes itself by mentioning 'proposal' and 'queue', and contrasts with 'remember', effectively differentiating it from sibling tools like memory_propose and memory_reject.
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: when a proposal should become canon. It explains that invalid proposals are refused with a typed reason and stay pending. However, it lacks explicit guidance on when not to use this tool or alternatives among siblings (e.g., memory_reject to discard, memory_propose to create a new proposal). This omission prevents a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses idempotency, default skip-exists, and overwrite behavior. Could mention return value or side effects, but current detail is sufficient for a scaffold tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler. First sentence defines action and location; second provides use case, idempotency, and overwrite flag. Every word 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?
For a simple initialization tool, the description covers purpose, usage trigger, and behavior. Missing return value description but output is a file creation; oversight is minor given no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions for both parameters. The description adds value by linking name to file path and explanation of overwrite, though it doesn't exhaustively detail name format constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Scaffold') and resource ('harness manifest'), specifies the output location pattern, and distinguishes from siblings like 'harness_describe' and 'identity' by stating it's for initializing a missing manifest.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to call ('when identity() reports a missing manifest') and documents idempotent behavior with overwrite option. Lacks explicit alternatives but context from sibling tools makes usage clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses key behaviors: preservation of citations/verification, supersessions pointer (unless leave_pointer=false), atomic batch operations with rollback, and collision rejection. Missing details on old slug accessibility after move and return value, but overall transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with bullet points for modes, front-loaded with the main action. It is slightly verbose but every sentence adds value. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description does not explain what the tool returns (e.g., success message, updated page info). It also omits potential restrictions on re-domain (e.g., destination domain existence) and reversibility. However, it covers modes, constraints, and alternatives adequately for typical use.
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 baseline is 3. The description adds significant value by explaining modes, parameter relationships (e.g., from_domain_prefix requires to_domain_prefix), constraints (collision -> use knowledge_merge), and atomic behavior, going well beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool re-keys or re-domains a knowledge page in place, preserving citations and verification history. It distinguishes three modes (single-page, batch by slug list, batch by domain prefix) and explicitly contrasts with knowledge_merge for collision scenarios.
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 each mode, including prerequisites (e.g., new_domain required for batch-by-slugs, from_domain_prefix requires to_domain_prefix) and alternatives (use knowledge_merge when new_slug collides). This helps the agent choose the correct tool and mode.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It states it is read-only, which is the key behavioral trait. It does not mention performance, size of return, or other potential effects, but for a read-only report, the disclosure is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two succinct sentences: first defines purpose, second provides usage guidance. No redundant words, highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Describes the output contents (totals, category breakdown, stale memories, etc.) and mentions defaults for parameters. Lacks output schema, but the description gives enough context for an agent to understand what the tool returns. Could mention the format but not critical.
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 each parameter having a description. The tool description does not add additional meaning beyond what the schema already provides (e.g., default values, thresholds). 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?
Description clearly states it produces a one-shot health report for the memory store, listing specific components (totals, category breakdown, stale memories, near-duplicate pairs, expired refs). It distinguishes itself from siblings like `forget` and `update` by being read-only and diagnostic.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Read-only — pair with `forget`/`update` to act on findings.' This tells the agent when to use this tool (to inspect) and when to use alternatives (for acting on findings), providing clear 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?
Discloses that the tool is destructive (removes) and offers a safe preview via dry_run. With no annotations, the description carries the burden and does so adequately, though it could mention permanence or auth requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences that are front-loaded and to the point. 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?
Covers the core functionality and safe usage pattern. Lacks details on return values or post-deletion state, but given the simplicity of the tool and lack of output schema, it is reasonably 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 100% of parameters and the description adds value by explaining the purpose of dry_run (preview without deleting) and the meaning of stale_days (days since last access).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the action (remove), the resource (expired memories), and the condition (TTL elapsed). The alternative dry_run mode is also mentioned, differentiating it from other tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides guidance on using dry_run for preview, but does not explicitly contrast with sibling tools like forget or knowledge_purge. However, the context is clear enough for typical use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description takes full responsibility, disclosing that the tool deletes the staging row and does not write memory. This is sufficient for a simple rejection, though it could mention irreversibility or error cases.
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 key action, 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?
For a simple tool with one parameter and no output schema, the description provides adequate context: purpose, usage, and behavioral effect. Slightly lacking in error examples but overall complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter 'id' is described in the schema as 'Proposal id (from memory_proposals)', and the description does not add further semantics beyond that. Given 100% schema coverage, 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 verb 'discard' and the specific resource 'pending proposal'. It distinguishes from siblings like memory_ratify by noting that no memory is written and the staging row is deleted.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use this for drafts that should not become canon', providing clear context and differentiation from committing actions like memory_ratify.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses the confirm parameter as a safety gate for bulk deletions, the dry-run preview for non-confirmed bulk requests, and that single-target deletions never need confirm. This provides adequate behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences that efficiently convey the tool's purpose, modes, and key parameter behavior. Every part adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema or annotations, the description covers all parameter usage patterns, the confirm safety gate, dry-run behavior, and single vs bulk distinction. It fully equips an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 value by explaining the confirm parameter's role, title_pattern as a glob pattern requiring a scope guard, and the grouping of parameters for single vs bulk deletion. This goes beyond basic schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool removes memories and distinguishes between single (by ref or category+title) and bulk (by category/project) deletion. It differentiates from sibling tools like memory_archive or memory_prune by specifying the deletion operation and its modes.
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 single vs bulk deletion and the requirement for confirm in bulk operations, including the dry-run behavior. However, it does not explicitly mention when not to use this tool or suggest alternatives among 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?
No annotations provided. Description discloses re-runnable behavior (overwrites manifest), target derivation, and suggested content scope. Lacks details on auth or side effects, but still informative.
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?
Front-loaded with core action, then usage condition and details. Slightly verbose but well organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description explains output location and body scope. Adequate for a write tool with two 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?
Schema coverage is 100%. Description adds value by noting frontmatter is stamped automatically for content parameter, and provides default for version. Adequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the action: 'write its manifest' at a specific path. Also distinguishes from siblings by focusing on the currently connected harness.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to call (when identity() reports an onboarding block for unknown runtime) and notes limitation: 'you can only describe yourself, not another harness'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It discloses that old_slug is archived with a tombstone pointing to new_slug, and that a supersession relationship is recorded. It does not contradict annotations. Could mention reversibility or permission requirements, but overall good.
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 sentences, front-loaded with the main action, followed by workflow and precondition. Every sentence adds value with no superfluous words.
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 no output schema, the description explains the effects: archiving, tombstone creation, and recording relationship. It also covers prerequisites and workflow. For a merge primitive with side effects, this is 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 coverage is 100% (all parameters described). The description adds meaning beyond the schema by clarifying roles: old_slug is the 'loser' and new_slug is 'canonical'. It also explains that note is optional and reinforces the purpose of each parameter.
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 marks a page as superseded, archives the old page, and records the relationship. It uses specific verbs and resources, distinguishing it from siblings like knowledge_merge and knowledge_write.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides the workflow: first write the canonical page with knowledge_write, then call knowledge_supersede. It also specifies the precondition that both pages must exist. However, it does not explicitly state when not to use this tool or list alternative tools for different scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description covers key behaviors: lists drafts, not actual memory, excluded from certain operations, and ordered newest first. It does not mention rate limits or permissions, but for a read-only list, this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences. The first sentence states the core purpose, and the second adds essential context and next steps. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description fully covers what the tool returns (list of proposals), ordering, the nature of the data, and links to follow-up actions. Given no parameters or output schema, it provides sufficient context for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, so the description does not need to add parameter details. The baseline for zero parameters is 4, and the description appropriately omits any parameter information.
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 lists all pending proposals from the capture-propose queue, ordered newest first. It distinguishes itself from sibling tools like memory_list and recall by specifying that these are drafts and not part of memory.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context about what the tool does and references related actions (ratify/reject). It implies usage for reviewing drafts but lacks explicit when/when-not guidance; however, the distinction from other memory tools is evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses that the tool sets verified_at and optionally freshness_anchor, and an optional note appends a dated section to the body (append-only). It also mentions rejection behaviors. However, it omits details like idempotency or authentication requirements, though these are minor.
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 four concise sentences, front-loading the core action ('Stamp a knowledge page as verified WITHOUT touching its body') and logically separating modes and constraints. Every sentence adds value, and there is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters, no output schema, and no annotations, the description covers the tool's behavior well: it explains modes, constraints, and rejection conditions. However, it does not explicitly describe the return value on success (e.g., confirmation or timestamps), which would add completeness 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%, so baseline is 3. The description adds significant meaning beyond the schema: it explains the two modes, mutual exclusivity of slug and slugs, the effect of note appending ('Never replaces the body'), and that freshness_anchor is preserved when omitted. This enriches parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Stamp a knowledge page as verified WITHOUT touching its body' and explicitly distinguishes it from sibling tools like knowledge_write by recommending 'use it (never knowledge_write) to record claims still hold'. It covers both single-page and batch modes, leaving no ambiguity about the resource or verb.
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 this tool versus alternatives ('never knowledge_write'), explains the two modes (single vs batch) with mutual exclusivity, and lists constraints such as rejection of archived pages and failure of batch on unknown slugs. This is comprehensive and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist; the description fully discloses the behavior: creates a tombstone, excludes archived memories from certain operations, and specifies recoverability via memory_restore. 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 sentences with no wasted words. Front-loaded with the verb and resource, then provides usage guidelines and behavioral details efficiently.
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?
Despite lacking output schema, the description covers the operation's purpose, constraints (exclusion from recall/list/audit/find_similar), recovery path, and usage context. No critical gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds context for 'note' as a tombstone note but does not elaborate on ref, title, or category beyond the schema. Adequate but does not significantly enhance parameter meaning.
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 action ('soft-retire a memory'), targets a clear resource ('memory'), and uses a verb ('archive') that distinguishes it from 'forget' and 'memory_restore'. It also clarifies the outcome: moved to archive tier with a tombstone.
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 this tool ('Use this instead of forget when the memory may need to be recovered or audited later') and contrasts with sibling tools like recall, list, audit, and find_similar, which exclude archived memories.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses key behavioral traits: archived pages are excluded from certain tools (knowledge_recall and knowledge_maintain), remain in the database, and are recoverable via knowledge_restore. This goes beyond a simple description and provides actionable transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: the first defines the action and effect, the second provides usage context and alternatives. Every sentence adds value, no filler. Front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (2 parameters, no output schema), the description is complete enough. It explains the effect, availability, and recovery. However, it doesn't detail the status change or any side effects, but the context of sibling tools makes it sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds context by referring to the 'note' as a 'tombstone note' and explaining the purpose of both parameters ('slug' as the page to archive, 'note' as why it's being retired), reinforcing the schema descriptions without adding significant new details.
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: 'Soft-retire a knowledge page: set its status to archived with an optional tombstone note.' It distinguishes itself from deletion and the sibling tool knowledge_supersede, providing a specific verb and resource.
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 advises when to use this tool ('Use this instead of deletion when the page may need to be audited or recovered') and when to prefer an alternative ('For deduplication merges, prefer knowledge_supersede'). This provides clear usage guidelines.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description fully covers irreversible deletion, citation cascade, confirm required, batch rejection for mixed archives, and that supersession pointers are preserved.
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 paragraph covering all necessary points without redundancy. It is front-loaded with action and guard, but slightly dense; could be split into more sentences for easier parsing.
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 two-parameter tool with no output schema and no annotations, the description completely covers preconditions, behavior, safety, side effects, and use cases. No 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%, but description adds meaning: explains the archive guard for slugs, mixed list behavior, and that confirm must be explicitly true as a safety gate. Slightly redundant with schema but adds useful context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it 'Hard-delete[s] one or more archived knowledge pages and cascade[s] their citations.' It uses a specific verb and resource, and distinguishes from siblings like knowledge_archive (archive first) and knowledge_restore.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use: 'clean up tombstoned cruft after merge/supersede workflows' and when not: 'not for retiring active pages.' It also provides a guard and advises calling knowledge_archive first.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description fully discloses behavioral traits: re-parenting, deduplication, MAX(verified_at), archiving losers with tombstone, loser bodies returned, and effects of each parameter like hard_delete_losers and append_loser_bodies.
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?
Front-loaded with core action, then details of behavior, then usage guidance. Every sentence adds value without redundancy. Efficient and well-structured.
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 5 parameters, no output schema, and high complexity, the description covers all essential aspects: what happens to source pages, return values (loser bodies), parameter effects, and distinguishes from siblings. No 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 baseline is 3. The description adds context beyond schema, such as deduplication logic and the curator workflow for append_loser_bodies, but the schema descriptions themselves are already fairly detailed.
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 'Consolidate 2+ knowledge pages into one canonical page' with specific verb and resource. It distinguishes from sibling tools knowledge_supersede and knowledge_write explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use: 'Use knowledge_write first if the target body needs updating before merging.' Also contrasts with knowledge_supersede, telling user to use merge when consolidating data from multiple pages.
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?
With no annotations, the description fully discloses behavior: archived pages are never surfaced, full detail stamps access/hit counts, output size-guarding causes overflow to index entries, and recall by slug to read full pages. Sort_by_verified behavior is also described.
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 dense paragraph but is front-loaded with the main purpose. Every sentence adds value, though it could be more structured (e.g., separate sentences for each tier). Still efficient and clear.
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 6 parameters, no output schema, and no annotations, the description covers all essential behavioral details, edge cases (size-guarding, defaults, slug precedence), and parameter interactions. It is complete for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all 6 parameters. The description adds meaning beyond schema by explaining interactions (slug precedence, query vs browse, detail defaults, size-guarding logic, sort_by_verified timestamp behavior). This compensates fully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches the knowledge store using LIKE matching and slug lookup. It distinguishes between query-based search and exact-slug fetch, and explains the two detail tiers, making the purpose specific and differentiating from siblings like 'recall' or 'find_similar'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on when to use slug over query ('Prefer slug over query when you know the page'), explains the default detail tier based on query presence, and describes the size-guarding behavior. This helps the agent choose correctly.
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:

[![loom MCP server](https://glama.ai/mcp/servers/sleepunit-agents/loom/badges/card.svg)](https://glama.ai/mcp/servers/sleepunit-agents/loom)

Score Badge

Copy to your README.md:

[![loom MCP server](https://glama.ai/mcp/servers/sleepunit-agents/loom/badges/score.svg)](https://glama.ai/mcp/servers/sleepunit-agents/loom)

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/sleepunit-agents/loom'

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