JauMemory MCP Server

Server Quality Checklist

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

Latest release: v0.5.1
Disambiguation2/5
There are multiple overlapping and confusing tools like 'search', 'fetch', and 'recall' where 'search' says it's discovery-only and redirects to 'recall', while 'fetch' returns route documentation. Tools like 'remember', 'recall', 'forget', 'update' suggest a CRUD line but are mixed with uncorrelated agents, skills, vault, and Berrry tools. Several tools have ambiguous boundaries (e.g., 'agent_error_learning' vs 'agent_reflection', or 'remember' vs 'analyze' vs 'consolidate').
Naming Consistency2/5
The naming is highly inconsistent. Some tools use snake_case (memory_stats, list_agents, create_agent), some use lowercase (remember, recall, forget), and some have redundant or inconsistent prefixes like 'agent_error_learning' vs 'agent_reflection' vs 'agent_memory'. There's also a 'berrry_' prefix for Berrry-specific tools mixed with others, and 'tool_' for registry tools. No consistent verb_noun pattern is maintained across the server.
Tool Count2/5
With 50 tools, the server is extremely heavy for what appears to be a memory server. The large number suggests it's trying to do too much—mixing memory management, agent orchestration, skill workflows, vault storage, and even an app deployment helper (berrry_*). This volume feels bloated rather than focused, and many tools could be removed or modularized into separate servers.
Completeness3/5
For the memory domain, core operations exist (remember, recall, forget, update, consolidate) but feel randomly extended with agent, skill, vault, and app deployment tools. The inclusion of 'berrry_create_tool' and 'berrry_register_tool' is a major scope creep that harms the server's focus. It's unclear if the agent and skill tools are complete—they reference many sub-actions (start, complete, list) but are bundled into single tools with actions, which hides gaps.
Average 3.7/5 across 50 of 50 tools scored. Lowest: 2.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 3 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosure, but it says nothing about behavioral traits such as whether this is a reversible operation, whether it requires certain permissions, what happens if the memory is already in the collection, or if the collection must exist. This is severely lacking 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, short sentence that is perfectly front-loaded and contains no extraneous words. Every word earns its place, delivering the core purpose succinctly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (2 required parameters, no output schema, no nested objects), the description is minimally adequate but fails to address obvious contextual gaps like error handling, side effects, or relationship to sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides full coverage (100%) with descriptions for both parameters: memory_id and collection_id. The description adds no additional meaning beyond what the schema already provides, earning the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('add'), the resource type ('memory'), and the target ('collection'), effectively distinguishing it from sibling tools like 'remove_from_collection' and 'create_collection'. The verb-resource combination is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'remove_from_collection', 'create_collection', or search tools. There is no mention of prerequisites, error conditions, or constraints (e.g., memory must exist, collection must exist, duplicate handling).
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 present, so the description bears full responsibility for behavioral disclosure. The description only indicates a mutation ('create') but fails to mention critical behavioral traits such as uniqueness constraints on 'name', idempotency, error conditions (e.g., duplicate name), required permissions, or return value. This is insufficient for an agent to safely invoke the tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise but overly brief. It lacks structure and fails to earn its place by omitting necessary details. A description this short should be packed with key information, but it only states the obvious.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (3 parameters, creation operation, no output schema, no annotations, and many sibling collection tools), the description is severely incomplete. It does not explain what happens on success, error states, or how this tool fits into the collection workflow. An agent would need to infer too much from the name alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no additional meaning beyond the schema's parameter descriptions. The phrase 'for organizing memories' provides slight context but does not enhance understanding of the parameters themselves.
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 ('create') and the resource ('collection') with a hint of purpose ('for organizing memories'). It is not a tautology and the verb+resource combination is specific. However, it does not distinguish this tool from sibling tools like 'add_to_collection' or 'update_collection', which operate on existing collections.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., list_collections, get_collection, add_to_collection). There are no prerequisites, conditions, or exclusions mentioned. The description is entirely silent on usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not state side effects (e.g., does it create a new run?), access requirements, or state transitions. The alias reference is helpful but insufficient for transparency.
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 very short (two sentences), front-loads the purpose, and includes an alias note. No redundancy; every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has only one parameter and a simple purpose, but the description lacks return behavior (e.g., status confirmation), state implications, and error handling notes. Given no output schema, the description should provide more context for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of the parameter (schedule_id) with a description. The tool description adds no extra semantics beyond what the schema provides, meeting the baseline for full coverage.
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 ('Re-trigger') and the resource ('failed or completed scheduled task'). The alias note distinguishes it from siblings like skill_schedule_cancel, skill_schedule, and skill_schedule_list, though skill_schedule_retrigger is explicitly a sibling, which dilutes but does not negate the clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., skill_schedule_retrigger or skill_schedule_cancel). There is no mention of prerequisites such as schedule existence or state eligibility beyond 'failed or completed'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It only says 'Update', which implies mutation, but does not disclose whether the operation is destructive, partial updates are allowed, if permissions are needed, or what the response is. The description is too minimal for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, consisting of one sentence. It is front-loaded with the key action. It could be more concise, but it is not overly verbose. However, the brevity may sacrifice completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters, no output schema, and no annotations, the description is insufficient. It does not explain what happens when only one parameter is provided, or if the update is incremental or replaces existing values. The tool is simple, but the description lacks 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?
Schema description coverage is 100%, so the schema already documents all parameters. The description lists 'name and/or description', adding minimal value beyond the schema. Baseline 3 is appropriate as the description does not add much meaning but does not mislead.
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 verb 'Update' and the resource 'collection details', specifying that it updates name and/or description. It distinguishes itself from sibling tools like 'delete_collection', 'create_collection', and 'add_to_collection' by focusing on mutation of existing collection metadata.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as 'update' (a more generic tool) or other collection-related tools. It does not mention prerequisites, such as requiring the collection to exist, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The description only states the high-level action but does not disclose side effects (e.g., whether it modifies memory, requires memory to exist beforehand, or has performance implications). For a tool that 'extracts insights,' users should know if it is read-only, what data is accessed, or if any thresholds apply.
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 very concise at six words, with no unnecessary verbiage. It is front-loaded with the action ('Analyze') and the domain ('memory patterns and insights'). However, the extreme brevity sacrifices clarity on behavioral and contextual details, which might have balanced conciseness with completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (one optional parameter, no output schema, no annotations), the description should compensate by explaining what the output looks like, how insights are presented, or prerequisites for analysis. For instance, does it return a list of patterns, a narrative, or structured data? The lack of output schema increases the need for descriptive completeness, which is not met.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with one parameter ('timeRange') fully documented via an enum. The description adds no additional meaning beyond the schema, as it does not explain how the parameter influences analysis or what 'extract insights' means for different time ranges. With full schema coverage, the baseline score is 3, but the description could add value by clarifying the parameter's impact.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb-resource pair ('Analyze memory patterns and extract insights') that clearly states the tool's function. It distinguishes from siblings like 'memory_stats' (which likely gathers statistics) and 'consolidate' (which likely compacts or reorganizes memory). However, it could be more specific about what kind of patterns or insights are extracted, such as trends, anomalies, or summaries.
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 does not provide explicit guidance on when to use this tool versus alternatives. While the sibling list shows multiple memory-related tools ('memory_stats', 'consolidate', 'recall', 'forget'), the description gives no context for choosing 'analyze' over them. The lack of guidance is mitigated by the tool's focused purpose, but users must infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits, but it only states the high-level action. It does not explain side effects (e.g., whether original memories are archived, as indicated in the dry_run and archive_originals parameters), whether the tool creates new records or modifies existing ones, or what 'insights' entails. The schema parameters hint at behavior, but the description fails to surface this critical context for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that directly states the tool's purpose with no extraneous words. It front-loads the core action. However, it could be improved by a second sentence covering critical behavioral context (e.g., 'Original memories are archived by default; use dry_run to preview') without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no output schema and the description does not explain return values (e.g., the format of 'insights'), the agent cannot predict what the tool returns. Additionally, there is no information about prerequisites, required memory state, or how the tool interacts with other memory operations. For a consolidation tool that may irreversibly group originals, this lack of completeness is a significant gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents all four parameters with clear descriptions (dry_run, min_group_size, archive_originals, similarity_threshold). The tool description adds no additional meaning beyond the schema—it only mentions 'semantic similarity' which is already implied by the similarity_threshold parameter. As per guidelines, baseline 3 is appropriate when the schema handles parameter documentation well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Consolidate') and resource ('similar memories'), with the outcome ('into insights') and method ('based on semantic similarity'). This distinguishes it from sibling tools like 'consolidate_collection' (which works on collections) and 'remember'/'recall'/'forget' (which operate on individual memories), giving the agent a precise understanding of what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. There is no mention of exclusions (e.g., 'use for individual memories, not collections'), no comparison with the similar sibling 'consolidate_collection', and no context about prerequisites or scenarios that favor this tool over 'analyze' or other memory-grouping approaches. The agent must infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully convey behavioral traits. It only states that an agent is created with optional fields, but omits critical details: what happens on success/error, whether names must be unique, how the 'id' auto-generation works, or any side effects. The pre-configured agents list adds migration context but not behavioral specifics.
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 a clear summary sentence followed by usage examples and a list of pre-configured agents. The examples are front-loaded and demonstrate parameter usage effectively. It could be slightly more concise by removing the pre-configured list if not essential, but overall it is not overly verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool with 6 parameters and no output schema, the description is incomplete. It does not explain what the tool returns after creation (e.g., the created agent object or ID), mention error conditions like duplicate names, or clarify the behavior of optional parameters like 'initialLearningRate'. The pre-configured agents list adds some context but does not cover functional 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?
Schema description coverage is 100%, so the baseline is 3. The description's usage examples show typical values for parameters like personalityTraits and specializations, marginally adding meaning beyond the schema. However, the schema descriptions are already quite clear, so the description does not significantly enhance 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 verb 'Create' and the resource 'agent', and specifies that it includes personality traits and specializations. This distinguishes it from siblings like 'list_agents' and 'update_agent_name' by explicitly focusing on creation. Multiple usage examples further reinforce the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any guidance on when to use this tool versus alternatives like 'update_agent_name' or when not to use it. The examples show usage but do not set context for when creation is appropriate. There is no mention of prerequisites or limitations.
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 disclose all behavioral traits. However, it only states it returns 'details of a specific collection including all its memories' without clarifying whether the operation is read-only, what 'memories' refers to, or any side effects. Contrast this with a readOnlyHint annotation that would alleviate the concern, but none exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that directly conveys the tool's purpose without extra words. It is perfectly front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one parameter, no output schema, and no annotations, the description is adequate for a simple read operation but lacks detail on the response format or what 'details' includes. It does mention 'memories', which is useful context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with one parameter (collection_id) described as 'UUID of the collection'. The tool description doesn't add any new meaning beyond what's in the schema, but high coverage means the schema carries the burden, earning a baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves details of a specific collection including its memories, using the verb 'Get' with a specific resource ('collection'). This distinguishes it from siblings like get_guide or list_collections, though some siblings (e.g., update_collection, delete_collection) share the collection focus, so it's not fully differentiated from all.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like list_collections (list all collections) or search (general search). It doesn't state prerequisites (e.g., collection must exist) or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 does not state that the operation is read-only, what the response contains, or any side effects. The minimal text lacks essential context about behavior beyond the action name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that states the core purpose and key features. It is appropriately sized for a simple listing tool, though it could be slightly expanded without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of an output schema and the presence of five parameters, the description does not provide enough context. It omits default behavior, pagination, ordering, response format, and the distinction between own and public skills even though an 'include_public' parameter exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description mentions filtering by 'type, category, and full-text search,' which maps to the schema parameters but adds no new meaning or context beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' and identifies the resource as 'your skills', clearly indicating the tool's purpose. It distinguishes from sibling tools like skill_create or skill_execute by focusing on listing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as skill_render, skill_schedule_list, or search. The description does not mention any exclusions or context for appropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It implies a read-only operation (listing) but does not confirm idempotency, disclose pagination behavior beyond what the schema states, or mention whether results are sorted by time or any other ordering. Without annotation context, the description leaves important behavioral aspects undocumented.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the tool's purpose and lists relevant statuses. Every word adds value with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the moderate complexity of a listing tool with four optional parameters and no output schema, the description adequately states the core purpose. However, it lacks guidance on result ordering, the meaning of offset vs. cursor-based pagination, and what fields are returned for each task. Without this, completeness is adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all four parameters. The description reinforces the 'status' parameter by listing example values (completed, failed, running, paused) but omits the 'cancelled' and 'paused_for_llm' options from the schema. It does not add any new meaning beyond the schema, meeting the baseline for full coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists skill execution logs (task history) and enumerates the statuses included (completed, failed, running, paused). This distinguishes it from sibling tools like 'skill_tasks_pending' (which likely only shows pending tasks) and 'skill_schedule_list' (which lists schedules, not execution logs).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives (e.g., skill_tasks_pending, skill_schedule_list). It does not explain the relationship between task history and pending tasks, nor does it mention prerequisites (e.g., skill must exist) or ordering considerations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It mentions that the tool wraps an HTTP API endpoint with optional credential injection, health monitoring, and schema validation, but does not disclose whether creation requires special permissions, what happens if a tool with the same name already exists, or if the operation is idempotent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that conveys the core purpose and optional features. It is front-loaded and avoids unnecessary elaboration.
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 17 parameters, no output schema, and no annotations, the description is insufficiently complete. It does not cover return values, error conditions, or prerequisites (e.g., required permissions or credential setup). The high parameter count demands more contextual guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all 17 parameters have descriptions in the schema. The tool description adds no new information about parameters beyond what the schema provides. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it registers a new tool in the tool registry and explains that a tool wraps an HTTP API endpoint with optional credential injection, health monitoring, and schema validation. This distinguishes it from siblings like tool_update and tool_list, though the verb 'register' could be more specific than 'create'.
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 this tool (to register a new tool), but provides no guidance on when not to use it or alternatives. Given the presence of similar sibling tools like tool_update and berrry_create_tool, explicit differentiation would improve this score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states that the tool consolidates memories into a summary or insight. It does not disclose whether the operation is destructive (e.g., deletes original memories), requires specific permissions, or modifies the collection state. The presence of a 'summarize_only' parameter in the schema implies mutation by default, but the description omits this crucial 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?
The description is a single sentence of 11 words with no superfluous content. It immediately states the action and the resource. It is front-loaded with the verb and noun, making it easy for an agent to parse quickly. Every word 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?
Despite the simplicity of the tool (3 parameters, none nested), the description lacks completeness. It does not explain the return value (no output schema exists), the effect of 'summarize_only' on behavior, or what happens to existing memories after consolidation. Given that consolidation may be a mutating operation, the absence of these details leaves the agent guessing about side effects and expected outcomes.
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 three parameters have descriptions in the JSON schema. The tool description adds no additional meaning beyond stating the overall operation. For example, the 'title' parameter is explained in the schema as 'Title for the consolidated memory (optional)', but the description does not clarify how or when the title is used. A baseline of 3 is appropriate since the schema already documents parameters adequately.
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: 'Consolidate all memories in a collection into a comprehensive summary or insight.' It uses a specific verb ('Consolidate') and resource ('memories in a collection'), and it differentiates from siblings like 'remember' (individual memory storage) and 'consolidate' (which may be more general or not collection-specific). The term 'comprehensive summary or insight' clarifies the output's nature.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. Siblings include 'consolidate', 'analyze', 'remember', and 'recall', but the description does not explain scenarios where consolidating a collection is preferable. There is no mention of prerequisites (e.g., collection must exist) or when to avoid using it (e.g., if individual memories are needed).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry full burden. Describes what the tool does but does not disclose side effects (e.g., whether removal is permanent, if collection or memory is deleted, permissions needed). Baseline score reflects minimal behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no redundant words. Appropriate length for a simple operation. Could be slightly more concise by removing article 'a', but still good.
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 low complexity (2 parameters, no nested objects, no output schema), the description is minimally complete. However, lacks info on what happens after removal (success, error cases, whether memory still exists elsewhere). An output schema or additional context would help.
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 baseline is 3. Description does not add any extra meaning beyond what the schema already provides for the two UUID parameters.
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?
Description uses specific verb+resource structure ('Remove a memory from a collection'). Clear purpose, but does not distinguish from sibling 'delete_collection' which also uses 'delete' action; however, the target ('collection') is different here. Lacks sibling differentiation but still clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives like 'delete_collection' or 'add_to_collection'. No context about prerequisites, typical use cases, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses three behavioral traits: runs steps in order, automatic credential injection, and automatic redaction of sensitive outputs. However, it omits important details such as whether execution is synchronous or asynchronous, expected latency, side effects (e.g., state mutations), or error behavior if a step fails. Adequate but not comprehensive.
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 short (two sentences), front-loads the core purpose in the first sentence, and adds two key behavioral traits in the second sentence. Every sentence adds value, but the brevity comes at the cost of missing important usage and behavioral context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 parameters, 1 required, nested objects, no output schema), the description provides a minimal understanding of what the tool does and key behaviors. However, it lacks information on return values, error handling, synchronization semantics, and prerequisites. It is sufficient for basic usage but incomplete for complex or first-time use.
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 5 parameters with brief descriptions. The tool description adds no extra parameter-level details beyond what is in the schema, such as how slug is resolved or how step_overrides interact with other parameters. Baseline of 3 is appropriate, as description does not compensate for missing depth.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb+resource structure ('Execute a skill workflow by slug') and clarifies the tool runs steps in order with credential injection. While it distinguishes itself from sibling tools like skill_schedule_cancel, skill_create, skill_list, and skill_render by focusing on execution, the lack of an explicit distinction from similar 'execute' tools (e.g., tool_call) slightly limits clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There is no mention of prerequisites (e.g., skill must exist, slug must be valid), exclusions, or when not to use it. Given 5 sibling tools with 'skill' prefixes, the agent needs clearer direction to avoid confusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavioral traits. It reveals that credentials are auto-injected from the vault and that auth headers must not be included, but omits further details like idempotency, error handling, rate limits, or whether the tool is destructive. This is insufficient for a tool that performs external HTTP calls.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise: two sentences with no wasted words. The first sentence clearly states the purpose, and the second covers critical behavioral constraints. Every sentence provides essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, nested objects, no output schema), the description is too sparse. It does not explain the execution flow, return format, error states, or how the tool interacts with external services. A user would need additional documentation 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?
The input schema has 100% description coverage, so the baseline is 3. The description adds no new parameter-level meaning; it only reinforces the 'extra_headers' restriction. The schema already documents each parameter adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Execute a registered tool by its slug'), specifying the identifier method and distinguishing it from sibling tools like skill_execute which operate on skills. The verb 'execute' and resource 'registered tool' are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides critical constraints about credentials and auth headers but offers no guidance on when to use this tool versus alternatives (e.g., skill_execute, toolkits). It does not explain prerequisites, such as requiring the tool to be registered, or when to avoid using this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states 'Delete', which is inherent from the tool name 'forget'. It does not reveal whether the deletion is permanent, requires authorization, or has cascading effects on related data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with zero wasted words. It is front-loaded and appropriately sized for a simple delete operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter, no output schema, and a straightforward purpose, the description is minimally adequate. However, it could be improved by clarifying what constitutes a 'memory' in this context (e.g., vs. 'collection' siblings) and noting any return value or side effects.
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 and already describes the single parameter 'memoryId' as 'Memory ID to delete'. The description adds no extra meaning beyond what the schema provides, so baseline 3 is appropriate as per criteria.
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 'Delete a specific memory' uses a clear verb ('Delete') and resource ('a specific memory'), directly conveying the tool's action. It distinguishes from siblings like 'remember' (store), 'recall' (retrieve), 'analyze', 'consolidate', and 'delete_collection' (which targets collections, not memories).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as 'update' (to modify a memory) or 'delete_collection'. There is no mention of prerequisites, exclusions, or context for invoking 'forget' over other memory-related tools.
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 convey behavioral traits. The word 'List' implies a read-only, non-destructive operation, which is adequate. However, no details are given about pagination, ordering, or whether the full set of collections is always returned. The description is minimal but not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. Every part earns its place: 'List all your collections' is direct and complete for a parameterless tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, so the description should explain what the output looks like. It only says 'List all your collections' without describing the return format (e.g., list of collection IDs, names, or objects). This leaves the agent uncertain about the result structure, making it incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so the schema provides zero information. The description compensates by explaining what the tool does (list collections). Since 0 parameters has a baseline of 4, and the description fulfills that role, the score is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and the resource ('all your collections'). It distinguishes from sibling tools like create_collection, delete_collection, and get_collection by focusing on listing all. However, it could be more specific about what 'collections' includes (e.g., names only or full metadata).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as get_collection (for a single collection) or search (for filtered results). The description lacks any when-to-use or when-not-to-use context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It mentions filtering modes but omits crucial details: whether results are paginated, what 'registered tools' means (user-specific? global?), if the tool has side effects, or if authentication is required. The description does not contradict any missing annotations, but it leaves significant behavioral gaps for a list/query operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that front-loads the core action ('List registered tools') and then enumerates filtering capabilities concisely. No extraneous content; every phrase adds value. A slight deduction because the list of filters could be more explicitly structured (e.g., colons or bullets) to aid scanning, but for a single sentence it is efficient.
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 5 parameters, no output schema, and zero annotations, the description carries a heavy burden. It covers only the high-level filtering functionality but does not describe return format, pagination behavior, default sorting, or whether the tool returns all tools or only those the agent has access to. For a discovery/query tool, this leaves important contextual gaps that the agent must guess.
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%, meaning each of the 5 parameters already has inline documentation. The description adds high-level context by grouping parameters into three filtering dimensions, but does not add new meaning or constraints beyond what the schema provides. The baseline of 3 is appropriate here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb-resource pair ('List registered tools') and immediately distinguishes itself by listing three distinct filtering dimensions (type, category, full-text search). This clarity is strong even among sibling tools like 'tool_create' and 'tool_call', making it easy for an agent to recognize this as a discovery/query tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly lists three filtering capabilities, which signals usage scenarios (e.g., when you need to find a tool by text or filter by type). However, there is no mention of when not to use this tool versus alternatives like 'toolkit_search', 'skill_list', or 'list_agents'—leaving the agent to infer those boundaries from names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden for behavioral transparency. It only states that the tool creates and retrieves reflections, without disclosing side effects, persistence guarantees, idempotency, authentication needs, or rate limits. The description does not go beyond the basic operation, leaving significant gaps for an agent to understand the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the purpose statement, followed by examples and reflection types. The examples are helpful but make the description longer than necessary. Structure is clear and logical, but could be more concise by trimming redundant example patterns. Still, it earns points for good organization.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 parameters, no output schema, no annotations), the description covers the actions and reflection types adequately. However, it fails to describe the return format (e.g., does 'list' return an array of reflections? Does 'create' return the created object?). With no output schema, these details are missing, making the description incomplete for an agent to fully understand the tool's 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 input schema already documents all parameters. The description adds value through examples showing valid parameter combinations (e.g., content with learning type, relatedAgents with collaboration). However, it does not elaborate on parameter semantics beyond what the schema provides, such as constraints on content length or format. Baseline is 3, and the examples only slightly enhance 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 purpose: 'Create and retrieve agent reflections for continuous improvement.' It specifies a verb (create/retrieve) and a resource (agent reflections). The examples and reflection types further clarify the scope, distinguishing it from sibling tools like 'remember' or 'agent_memory' which handle more generic memory.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides usage examples for both create and list actions, showing typical scenarios. However, it does not explicitly contrast with alternative tools (e.g., when to use 'agent_reflection' vs 'remember' or 'agent_error_learning'), nor does it specify when not to use this tool. The guidance is clear in context but lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description must fully disclose behavior. It mentions optional context and importance scoring but does not describe side effects (e.g., overwrites on duplicate?), permissions, or return value. No contradiction exists, but the description is incomplete 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, efficient sentence that covers the core purpose and hints at key optional parameters. No extraneous words; every part 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?
With 6 parameters, no output schema, and no annotations, the description is too sparse. It does not explain what happens on success/failure, the tool's role within the broader memory ecosystem (e.g., vs. 'consolidate'), or how returned data is structured. Minimal but adequate for a simple storage operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the description briefly references 'optional context and importance scoring', tying to the context and importance parameters. However, it does not elaborate on the shortcuts parameter's parsing behavior or how metadata is used, though the schema itself is detailed. Baseline is 3 due to high coverage; the additional mention nudges it to 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it stores a new memory and mentions optional context and importance scoring, which distinguishes it from siblings like 'recall' (retrieval) and 'forget' (deletion). The verb 'store' and noun 'memory' are specific, though it could better differentiate from 'agent_memory' or 'consolidate'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidelines on when to use this vs. alternatives like 'recall' or 'consolidate'. The description implies usage for storing new memories but does not state when not to use it, prerequisites, or alternatives among the many sibling tools.
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 has full responsibility for behavioral disclosure. It reveals two constraints (60s min interval, 20 active schedule max), but omits whether scheduling is destructive (e.g., overwrites existing schedule?), what auth is needed, or side effects. For a creation tool with no annotations, this is adequate but incomplete.
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 two sentences, concise, and front-loaded with the core purpose. However, it could be sharper by stating the action more precisely and omitting the constraint details (which are also in schema descriptions), but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (7 parameters, a mutation tool with no output schema), the description is somewhat sparse. It covers the scheduling constraint but lacks high-level context like what happens on success (returns schedule ID?), error conditions, or relationship to sibling tools like 'skill_schedule_cancel'. With no output schema, a brief note on return values 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?
Schema coverage is 100%, so baseline is 3. The description adds some parameter context (e.g., min interval and max active schedules), but the bulk of parameter meaning already comes from the schema's field descriptions. The description does not add significant new semantics beyond what is in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the purpose: 'Schedule a skill for recurring cron-based execution.' It uses a specific verb-resource pair ('schedule a skill') and distinguishes itself from siblings like 'skill_schedule_cancel' and 'skill_schedule_list' by defining the core scheduling action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some usage constraints (min interval, max active schedules) but does not explicitly state when to use this over siblings, nor does it mention any prerequisites or context (e.g., user must have an owned skill). The usage is implied but not explicitly guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the tool lists runs with filtering, but does not disclose whether it is read-only, what side effects might occur, how results are ordered, or any performance characteristics. The agent has insufficient information about expected behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words. It is front-loaded with the core action and immediate context. Every portion contributes to understanding the tool's 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?
For a list tool with no output schema, the agent would benefit from knowing what fields are returned, default sort order, and pagination behavior (beyond what the input schema says). The description omits these details, leaving the agent with incomplete context for downstream processing.
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%—each parameter already has a description in the input schema. The tool description adds the context that filtering is by 'skill or status', which aligns with the skill_id and status parameters, but does not add new meaning 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 verb 'List' and the resource 'scheduled skill runs', with optional filtering. This distinguishes it from sibling tools like skill_schedule (which creates schedules) and skill_schedule_cancel (which cancels). The purpose is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used for listing scheduled runs, but it provides no explicit guidance on when to use this versus alternatives such as skill_list (which lists skill definitions) or skill_schedule (which creates schedules). No prerequisites or exclusions are mentioned, so the agent must infer usage from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It mentions 'manual approval process' and a browser link, but fails to explain login state changes, whether the tool is idempotent, what happens if already logged in, or what credentials are stored. The browser action is noted but not how the returned link is handled.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: two clear sentences and an important note. The purpose is front-loaded in the first sentence, and all three sentences carry distinct, essential information. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description must explain what the tool returns. It implies a link is returned ('click the link provided') but never explicitly confirms the return value (e.g., URL or token), nor does it describe the authentication state outcome, timeouts, or error conditions. The agent lacks critical information to handle the response 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 for both 'email' and 'username'. The description adds value by emphasizing 'REAL' accounts and noting that the email must match a registered account, confirming the need for genuine credentials beyond what the schema alone states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool initiates the MCP authentication flow with 'Initiate MCP authentication flow.' However, it does not differentiate from the sibling tool 'mcp_authenticate' (likely a complement step), leaving ambiguity about where one ends and the other begins.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: real accounts only ('Provide your REAL JauMemory username and email', 'Test accounts will not work') and a required post-action ('You MUST click the link provided and approve in your browser'). It does not, however, provide explicit when-not-to-use guidance or alternative tools.
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 bears full responsibility. It discloses the key behavioral trait of partial update ('only provided fields are updated'). However, it does not cover other important behaviors such as idempotency, error handling (e.g., missing tool_id), permission requirements, or whether changes are reversible.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two short, front-loaded sentences. The first identifies the action and resource, the second explains the partial update behavior. Every word is purposeful; no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the tool having 18 parameters (including complex JSON strings) and no output schema, the description is limited to two sentences. It does not address validation of JSON fields, success/failure responses, or constraints (e.g., required permissions, rate limits). The detail in the schema compensates partly, but the description lacks completeness for a complex mutation operation.
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%, providing detailed descriptions for each parameter. The description adds significant semantic value by clarifying the partial update pattern ('All fields are optional — only provided fields are updated'), which is not evident from individual parameter descriptions. This helps the agent understand that omitted fields remain unchanged.
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 'Update an existing tool in the tool registry', specifying the verb (update) and resource (tool in the tool registry). This distinguishes it from sibling tools like tool_create (create), tool_list (list), and tool_call (call). However, it does not explicitly differentiate from the generic 'update' sibling, though the resource specification mitigates confusion.
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 this tool (to update a tool's fields, with partial updates supported). It lacks explicit guidance on when not to use it (e.g., for creating new tools use tool_create, or for deletion use a delete tool). No alternatives or prerequisites are mentioned, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It clarifies that memories are preserved, which adds value, but does not mention permissions, reversibility, or side effects. Adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with parenthetical clarification, no wasted words. Front-loaded with verb and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete tool with one parameter and no output schema, the description explains the key nuance (memories retained). No mention of errors or return value, but largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a detailed description for collection_id. Description does not add 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?
Description clearly states verb 'delete' and resource 'collection', and explicitly notes that memories are not deleted, distinguishing it from related operations like remove_from_collection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this vs alternatives such as update_collection or remove_from_collection. No prerequisites or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It correctly implies a create/mutation operation but doesn't disclose side effects like whether the skill is immediately active, whether duplicate names are allowed, or what happens to draft workflows.
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 very concise with two sentences, the first directly stating the action and the second providing context on what a skill involves. No wasted content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with 13 parameters, no output schema, and no annotations, the description is minimal. It explains the concept but doesn't cover practical usage patterns, prerequisites, or return behavior. Adequate but leaves gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds no additional parameter semantics beyond the schema, but the schema itself is well-documented for all 13 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 'Create a new skill workflow' and defines what a skill is ('chains multiple tools together with...'), effectively differentiating it from sibling tools like skill_list, skill_execute, and skill_render.
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 it (to create a skill workflow) but provides no explicit guidance on when not to use it versus alternatives like tool_create or the step-by-step skill_add_step mentioned in the schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility. It discloses that the secret is encrypted at rest and never returned, which is positive. However, it does not mention whether storing a credential with an existing name overwrites or errors, what authentication is required to store, or any rate limits. The transparency is adequate but incomplete.
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 clearly states the purpose, and the second provides a practical usage hint. Every sentence is meaningful, and there is no wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This tool has 10 parameters and no output schema or annotations. The description is brief and does not cover important context like what happens on success/failure, whether credentials are overwritten, required permissions, or return values. Given the complexity, more completeness is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds minor value by explaining that provider presets auto-configure auth headers, which the schema also mentions. No additional parameter semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Store a new API credential in the secure vault.' This is a specific verb (store) and resource (API credential), and it distinguishes the tool from siblings like vault_list (listing) and vault_rotate (rotating).
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 hints at usage by mentioning provider presets for auto-configuration, but does not explicitly guide when to use this tool versus alternatives like vault_rotate for updating existing credentials or vault_list for inspection. No when-not or exclusion criteria are given.
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 exist, so the description carries the full burden of behavioral disclosure. It only states the prerequisite actions but does not mention error handling, side effects (e.g., session creation), or what happens on invalid tokens. The description adds no detail beyond the obvious authentication flow, leaving the agent uninformed about failure modes or state changes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise, direct sentences. The first sentence states the action and key input; the second emphasizes the prerequisite. No superfluous words. Perfectly front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and low complexity (2 required string params), the description is mostly sufficient for a simple authentication step. However, it omits what the tool returns on success or failure (e.g., confirmation, session token). The agent might need to infer success from absence of error. A slightly more complete description would mention expected outcome.
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 reinforces the source of auth_token (from approval webpage) but does not add substantive meaning beyond what the schema already provides. It is adequate but not exceptional.
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 'Complete' and the resource 'MCP authentication'. It specifies the prerequisite actions (click link, approve, copy code), which distinguishes this tool from mcp_login (initiation) and mcp_logout (termination). The purpose is unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs when to use the tool: after the web approval step. It implies the context relative to mcp_login and mcp_logout. While it does not name alternative tools or explicitly state when not to use it, the guidance is clear enough for an agent to sequence correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses actions, collaboration types, and outcomes, but omits behavioral details such as whether list returns active or all collaborations, whether completion is irreversible, or if starting a collaboration requires both agents to exist. Side effects and persistence are not mentioned.
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 a brief intro, code examples, and tables for types/outcomes. It is front-loaded with the purpose. While thorough, it could be slightly shorter by reducing redundant example text, but it earns its length with clarity.
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 should explain return values. It does not describe what each action returns (e.g., collaboration ID for start, list of collaborations for list). Error conditions (e.g., invalid agentId) are also omitted. However, the parameter usage and conditional requirements are well covered.
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 significant value by grouping parameters by action (e.g., collaboratorId needed for 'start', collaborationId for 'complete'). It also enumerates collaboration types and outcomes, clarifying which enums are valid for which actions beyond the schema's plain 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 'Manage collaboration between agents' and provides specific actions (start, complete, list) with usage examples. This distinguishes it from sibling agent tools like agent_memory or create_agent, which focus on memory or creation rather than collaboration management.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through examples but does not explicitly state when to use this tool versus alternatives like agent_memory or agent_reflection. There are no 'when not to use' or exclusion criteria, leaving the agent to infer context from examples alone.
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 alone must disclose behavioral traits. It states the operation is a 'soft-delete' cancel, which implies the schedule is marked as inactive but not permanently removed. This is useful behavioral context, but the description does not mention whether cancellation is reversible, what happens to pending tasks, or any permission requirements. The scope of disclosure is adequate but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that captures the essential action and effect ('Cancel (soft-delete) a scheduled skill run'). Every word adds value, with no filler or redundancy. It is appropriately sized for a simple tool with one parameter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (1 parameter, no output schema, no nested objects), the description is nearly complete. It clarifies the soft-delete nature, which provides critical behavioral insight. The only minor gap is the lack of explicit mention of prerequisites (e.g., whether the schedule must exist), but the schema's required field and UUID constraint implicitly cover that. No major gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100% (one parameter with a clear description: 'UUID of the schedule to cancel'), so the baseline is 3. The description adds no additional parameter semantics beyond what the schema already provides, confirming a neutral score.
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-action combination ('Cancel (soft-delete)') and identifies the exact resource ('a scheduled skill run'). This clearly distinguishes it from sibling tools like 'skill_schedule' (which presumably creates schedules) and 'skill_schedule_list' (which lists them).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives. However, the tool name and context signals (single required parameter 'schedule_id') implicitly convey that it is used to cancel a schedule by its UUID. No exclusions or comparisons to sibling tools like 'skill_schedule_retrigger' are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility. It mentions 'Resets retry count and re-enables', which is a behavioral trait, but it does not disclose whether the operation is destructive, idempotent, or what happens if the schedule is already running. For a mutation tool with no annotations, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main purpose, and contains no unnecessary words. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (one required parameter, no output schema, no nesting), the description is mostly complete. It explains what the tool does, when to use it, and key behavioral effects. Missing details like expected return value or error handling, but these are minor 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?
With 100% schema description coverage, the schema already documents the single parameter (schedule_id). The description does not add any additional meaning beyond what the schema provides, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Re-trigger' and the specific resource 'failed or completed scheduled run'. It also adds 'Resets retry count and re-enables' which further clarifies the action. This distinguishes it from sibling tools like skill_schedule_cancel and skill_task_retrigger by focusing on schedules and the condition of failure/completion.
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: for a 'failed or completed scheduled run'. This provides clear context. However, it does not mention when not to use it or provide alternatives, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It explains what 'pending' means but does not explicitly state that the operation is read-only, safe to call repeatedly, or any side effects. The implied read behavior is reasonable but not confirmed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that conveys the core purpose immediately. Every word serves a purpose, with no redundancy or fluff.
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 list tool with two optional parameters and no output schema, the description adequately defines the tool's scope. It could optionally describe the return format (e.g., 'returns a list of task objects'), but the lack does not critically hinder understanding given the tool's low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no additional meaning beyond the schema for the two parameters; it does not explain how 'limit' or 'skill_id' relate to the concept of 'pending' tasks.
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 specific verb 'List' and clearly identifies the resource as 'pending/actionable skill tasks', further defining what that means (paused executions, recent failures). This distinguishes it from the sibling 'skill_tasks_list' which likely lists all tasks.
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 by specifying it lists only pending tasks, but it does not explicitly contrast with 'skill_tasks_list' or state when not to use it. No prerequisites or alternatives are mentioned, leaving some ambiguity for the 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?
Annotations are absent, so the description must carry the full burden. It discloses that credentials are redacted, which is a meaningful behavioral trait. However, it does not mention whether the operation is read-only, modifies any state, or requires authentication. With only a tool_id parameter, the agent cannot infer safety or side effects beyond the description's limited scope.
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 wasted words. The first sentence states the core purpose and output format; the second specifies content scope and a security behavior (redaction). It is front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has only one required parameter, no output schema, and no nested objects, so complexity is low. The description provides the core information (renders as markdown, shows endpoints/schemas/config, redacts credentials). It is sufficient for the agent to use the tool correctly. A small gap is lack of mention about return format structure, but given the straightforward nature, a 4 is reasonable.
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%, meaning the schema already documents the tool_id parameter thoroughly. The description adds marginal value, implying that the parameter identifies which tool to render, but it does not elaborate on format constraints or expected values. Baseline 3 is appropriate because schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ("Render") and resource ("tool as a human-readable markdown document") and distinguishes it from siblings. For example, tool_list lists tools, tool_create creates them, and tool_call calls them, but tool_render specifically produces a markdown view. The mention of "endpoints, schemas, and configuration" makes the output's content explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for obtaining a readable summary of a tool's definition, which is a relevant context. However, it does not provide explicit guidance on when to use this tool versus alternatives like tool_list or skill_render (which renders a skill) or when not to use it. No exclusions or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses critical behavioral traits: the old value is permanently replaced (irreversible), and the new value is write-only and never returned. With no annotations provided, this description effectively carries the full burden, though it could mention if any confirmations or rollbacks exist.
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 concise at two sentences, front-loading the main action. Every sentence adds value (action, old value fate, new value behavior). Slightly more context for agent selection could improve it, but no waste is present.
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 low complexity (2 required params, no output schema), the description is nearly complete. It explains what happens to the old and new values. However, with no annotations nor output schema, it could mention whether the rotation succeeds silently or returns a confirmation.
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 parameters (credential_id, new_value) are already documented with descriptions. The description adds 'Write-only: never returned in responses' for new_value, which reinforces schema info but doesn't add new meaning beyond the structured schema 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 uses a clear verb ('Rotate') and resource ('an existing credential'), explains the key action ('replace the secret value'), and distinguishes itself from siblings like vault_store and vault_list by specifying it operates on existing credentials.
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 rotating an existing credential) but offers no explicit guidance on when not to use it or mentions alternatives like vault_store for new credentials. No exclusions or context for selection among siblings is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry behavioral disclosure. It explains search modes and optional query behavior but does not mention read-only versus mutation side effects, authentication requirements, or rate limits. For a read-only search tool, the description is adequate but not exhaustive.
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, extremely efficient, and front-loaded with the core action and supported features. Every sentence earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description focuses on usage and filtering capabilities without detailing return format. However, for a search tool with 0 required parameters and nested objects, the description sufficiently covers behaviors like optional query and server mode selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description lists key parameters (mode, tags, limit, query, timeRange, minImportance) and their purpose, adding value beyond the schema by summarizing the feature set. It does not add extra syntax details for nested parameters like timeRange.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs 'Search and retrieve memories,' a specific verb-resource pair. It distinguishes the tool from siblings like 'search' and 'fetch' by specifying memory-specific search modes (keyword/semantic/hybrid) and specialized filters (tags, time, importance).
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 on when to use the tool (for memory search and retrieval) and highlights flexibility with optional query for filters-only searches. However, it does not explicitly exclude scenarios when a sibling like 'search' or 'fetch' would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It explicitly lists what results include (name, slug, type, category, usage count), and the schema shows supported filtering (query, limit, tools_only, skills_only, category_id). This gives agents a clear behavioral model beyond just 'search'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, with the first sentence stating the core purpose and the second listing the returned fields. No filler or repetition—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?
Given that there is no output schema, the description adequately explains what the result fields are (name, slug, type, category, usage count). The parameter schema is complete, and the complexity is low (no nested objects, enums). It is sufficiently complete for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage—all five parameters have descriptions. While the tool description does not add new parameter details beyond stating that it returns specific fields, the schema already provides sufficient meaning. 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 'Search across both tools and skills in a unified query,' specifying the verb (search), resource (tools and skills), and unique value (unified). It distinguishes itself from siblings like 'search' (likely more generic) by emphasizing the dual scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for searching tools and skills but does not explicitly state when to use this tool versus siblings like 'search', 'tool_list', or 'skill_list'. It lacks exclusion criteria or prerequisites, though the context is sufficient for basic understanding.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that values are always masked, which is a key behavioral trait. However, it does not cover authorization requirements, rate limits, or what happens if no credentials exist, leaving some gaps for a security-sensitive tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary purpose, and each sentence adds value. There is no redundancy or 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 the absence of an output schema and annotations, the description covers the core functionality, masking behavior, and filtering options. It does not mention pagination or ordering, but for a simple list tool this is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds 'Supports filtering by provider and type' but this largely mirrors the schema descriptions. No additional meaning or examples are provided beyond what the schema already states.
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 ('List') and resource ('your stored credentials'), clearly distinguishing the tool from siblings like vault_store and vault_rotate. The masking behavior and filtering capability are also mentioned, adding precision.
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 that the tool should be used to view credentials, which is clear given the sibling list. However, it does not explicitly state when not to use it or mention alternatives, leaving a minor gap in 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?
With no annotations provided, the description carries full burden for behavioral transparency. It successfully explains available actions (link/recall), memory categories, and usage contexts like project filtering. The lack of explanation about side effects (e.g., whether linking overwrites existing memories) or authorization requirements prevents a perfect score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with examples and category tables, making it scannable. However, at over 20 lines it is somewhat lengthy; some example repetition could be trimmed (e.g., the recall-with-query and recall-with-project examples could be combined). Every section earns its place, but the file size could be reduced.
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 has 7 parameters, no output schema, and provides examples covering the main actions, the description is fairly complete for an agent to invoke it correctly. The memory category table and usage examples cover the major operational patterns. However, missing information about return values (especially for recall action) and the absence of edge-case handling (e.g., empty results) slightly reduces 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 description coverage is 100%, so baseline is 3. The description adds significant value beyond the schema by providing memory categories with semantic meanings (task, learning, error, solution, reflection) and real-world usage examples demonstrating parameter combinations. The category descriptions clarify what each value represents, improving over the schema's terse 'Memory category like task, learning, error'.
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 defines the tool's dual purpose: linking memories to agents or recalling agent-specific memories. The verb+resource combination 'Link memories to agents or recall agent-specific memories' is specific and distinguishes it from general memory tools like 'remember' and 'recall' among 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 includes multiple usage examples demonstrating common patterns (link, recall, search, project-specific recall), which helps an agent understand when to use each action. However, it does not explicitly state when NOT to use this tool (e.g., when to prefer 'remember' or 'recall' tools), lowering the score from 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It correctly implies a read-only operation but does not mention pagination, performance characteristics, or the structure of the returned details. This is adequate for a simple list tool but lacks depth that an agent might need for safe invocation.
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 very concise: a one-line purpose, three usage examples, and a four-item status list. Every part is useful, and the most important information (purpose) is front-loaded. There is no wasted text.
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 tool with one optional parameter and no output schema, the description covers the purpose, parameter usage, and status meanings. It does not describe the return format, which would be helpful but is not strictly required since the tool simply 'list[s]' agents with 'details'. The description is largely complete for an agent to decide whether and how to use it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (the parameter has a description and enum), so the baseline is 3. The description adds value by providing concrete usage examples and listing each status with a brief meaning, which helps the agent understand how to use the filter effectively beyond the schema's minimal description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' with the resource 'all available agents', clearly stating what the tool does. It distinguishes from siblings like 'create_agent' and 'agent_memory' by focusing solely on listing, and the usage examples reinforce the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage examples for different status filters and lists all possible statuses with meanings, which guides the agent on how to use the tool. It does not explicitly state when not to use it or compare to alternatives, but the siblings do not include another list-agents tool, so the guidance is sufficient for practical 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 carries the full burden. It explains the local_only parameter's effect (clear local creds, no server-side revocation) and scope behavior. However, it does not disclose the irreversible nature of the logout or that re-authentication will be required afterward.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action, and every word adds value. No redundancy or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations. The description covers the two parameters and their behaviors well. However, it does not mention what the tool returns (e.g., success status) or any prerequisites (e.g., must be logged in). For a simple destructive action, this is slightly under-specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description restates the schema's parameter explanations without adding new meaning. It does not go beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb 'Logout and revoke' and the resource 'current MCP session'. It distinguishes from siblings like mcp_login and mcp_authenticate by specifying termination of the session. The scope variations are also explained.
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 guidance on when to use each scope value ('all', 'others', 'this') and notes the default behavior. However, it does not explicitly contrast with sibling tools or state when not to use this tool (e.g., already logged out).
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 the full burden. It discloses a key behavioral trait: credential redaction in the output. This is important for security transparency. However, it does not mention if the render is synchronous, the size limits, or what happens if the skill_id is invalid.
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 immediately adding unique value about credential handling. Every sentence earns its place with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has a single parameter, no output schema, and no annotations, the description is complete enough for a straightforward render operation. It covers the input, output format, and a key security behavior. One could argue for 5, but the lack of any mention of error cases or performance characteristics slightly reduces 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 description coverage is 100% for the single parameter (skill_id: UUID of the skill to render). The description adds context on what the parameter is for (which skill to render) but does not add extra semantics beyond the schema. A baseline of 3 is appropriate, and the non-redundant credential redaction mention earns a +1.
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 renders a skill as a human-readable markdown document, adding value over the name by specifying the output format (markdown) and key behavior (redacting credentials). This clearly distinguishes it from sibling tools like tool_render or skill_create.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is for generating human-readable documentation of a skill, but does not provide explicit guidance on when to use this versus alternatives (e.g., tool_render for individual tools, skill_list for listing). It also does not mention prerequisites like the skill needing to exist.
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 the full burden for behavioral disclosure. It states the tool is a read-only fetch ('Fetch JauMemory usage docs') and that it requires no authentication. While it does not mention idempotency, rate limits, or potential side effects, these are minimally relevant for a documentation retrieval tool, and the description gives enough transparency about its safe, public nature.
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 tightly written in three sentences. The first sentence immediately states the core purpose. The second enumerates all invocation modes efficiently. The third provides usage guidance. No word or clause is wasted, and the structure is front-loaded and scannable.
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 that there is no output schema and the tool has three optional parameters, the description adequately explains each parameter and the default behavior. However, it does not describe the return format (e.g., 'returns markdown guide text'), which would help the agent handle the result. For a simple documentation tool, this is a minor gap, keeping it at the baseline of adequacy.
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%, setting a baseline of 3. The description adds significant value by explaining the behavior with no arguments (returns topic index), providing concrete examples for each parameter (e.g., 'concepts/shortcuts' for topic, coding-assistant for persona), and clarifying that search is a keyword finder. This goes well beyond the schema's terse 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 'Fetch JauMemory usage docs' as a specific verb+resource. It distinguishes itself from siblings like search and fetch by being the tool for documentation retrieval, and provides distinct modes (index, specific guide, persona chunk, keyword search) that separate it from data-access tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use the tool: when you don't know how a JauMemory tool works, for cross-session coordination, or user 'how do I' questions. It also notes 'No authentication required — same public posture as search and fetch.' It does not provide explicit when-not-to-use or alternatives, but the positive guidance is clear and contextual.
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 clearly describes the 2-strike protocol and response types (first_occurrence, solution_found, previous_attempts_failed, new_problem), which explains behavioral outcomes. However, it does not disclose whether the tool is destructive, requires authentication, or has rate limits, which would elevate this further.
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 clear sections (Usage Examples, 2-Strike Protocol, Response Types) and is front-loaded with the core purpose. It is appropriately sized for a complex tool with 10 parameters, though the usage examples could be slightly condensed without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 10 parameters, no output schema, and no annotations, the description provides comprehensive guidance: it explains all three actions with concrete examples, the protocol flow, and possible response types. This fully compensates for missing annotations and output schema, making the tool's behavior predictable for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage with descriptions for all 10 parameters, including enum constraints for 'action'. The description adds value by showing parameter usage in context via code examples, but this is supplemental rather than essential given schema completeness. 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 enables agents to learn from errors using a 2-strike protocol. It provides specific verb-resource combinations (report, solve, fail) and distinguishes error learning from sibling tools like memory_stats, list_agents, or search which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides usage examples for each action (report, solve, fail) and clearly outlines the 2-strike protocol with numbered steps. It also describes when each response type occurs, giving agents guidance on interpreting results. There are no sibling tools that overlap in function, so no need for exclusion notes.
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 fully bears the burden of behavioral disclosure. It transparently explains that tags and shortcuts are strictly additive, metadata deep-merges last, and tags cannot be removed via the tags field—only through metadata or a delete/recreate workflow. The mention of v2 future plans adds additional context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph that efficiently front-loads the purpose and then details behavioral semantics. While every sentence is valuable, the structure could be improved (e.g., bullet points for additive vs. replace behavior). It is slightly dense but not overly verbose.
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 assumes knowledge of the 'remember' tool's shape and does not specify return values or prerequisites (e.g., that the memory must exist). Given the absence of an output schema, the tool would benefit from describing what the response contains or confirming the update. It is adequate but has clear gaps.
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 description coverage is 100%, but the description adds significant value beyond the schema: it explains that 'every field is optional and unset fields are left untouched', describes the additive semantics for tags/shortcuts, and clarifies the deep-merge behavior of metadata. This extra context is crucial for correct invocation.
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 'Update an existing memory' and explains that it accepts the same shape as 'remember' but with all fields optional. This directly conveys the verb (update) and resource (memory), effectively distinguishing it from sibling tools 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 implicitly defines when to use the tool (to modify an existing memory) and notes the additive behavior for tags/shortcuts and how to work around tag removal. However, it does not explicitly state when not to use it (e.g., if full replacement is needed) or compare against alternatives like 'delete + recreate', leaving a slight gap in guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It explains the naming convention and reassignment purpose but does not disclose side effects (e.g., whether old name is preserved, if updates are reversible, or if there are any restrictions on changing names frequently). This is adequate but leaves some questions unanswered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear heading, code examples, and bullet-point format requirements. Every sentence is purposeful and concise. 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?
Given the low complexity (2 params, all required, simple types), schema coverage is 100%, and no output schema is needed, the description fully covers what the agent needs to know: how to format the name and the purpose. It is complete for this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. However, the description adds significant value by providing the exact naming format ('Long Name:shortname'), examples, and character length guidance, which the schema (with just a description string) lacks. This extra detail justifies a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update an agent's name') and specifies the resource ('agent'). It distinguishes itself from siblings like 'create_agent' or 'update' by focusing on renaming with a specific convention and providing examples that show it is about reassigning roles, not generic updates.
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 usage examples and detailed format requirements, including what the newName must contain ('Long Name:shortname') and character length for short names. It also explains the purpose ('reassigned to different roles'), which helps the agent decide when to use this tool instead of 'create_agent' or 'update'.
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 behavioral traits: creation+registration, credential requirement, visibility tier restrictions with 403 error and upgrade hint, file size limits, mutual exclusivity of inputs, and post-creation API usage. It also clarifies the API's lack of prompt-based generation. Thorough and honest.
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 clear sections (INPUT MODES, VISIBILITY, REQUIRES, AFTER CREATE). It is front-loaded with the main purpose. While somewhat lengthy for a tool description, every sentence adds necessary information and there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (multi-step creation, credential handling, tier restrictions, error responses, post-creation usage), the description covers all aspects comprehensively. It explains return value (slug) implicitly and addresses edge cases like visibility 403 and rollback. No output schema exists, but the description provides sufficient guidance.
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 meaningful context beyond schema fields: highlights mutual exclusivity of files_json and remix_from, specifies that index.html is required within files_json, explains visibility defaults and tier requirements, and notes the auth_path default. This adds significant value over the schema alone.
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 'Create a new Berrry app AND register it as a JauMemory tool in one step.' This is a specific verb+resource+outcome that clearly defines the tool's purpose and distinguishes it from potential sibling tools like berrry_register_tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: mutually exclusive input modes, visibility tier requirements, credential prerequisites, and post-creation steps. It also explains when to generate files in the assistant vs. using the API. However, it does not explicitly compare to sibling tools or state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden. It discloses return fields (memory count, type distribution, top 20 tags, importance distribution, keyword frequency) and supports wildcards in queries. It does not state performance implications or error handling, but the detailed return structure provides good transparency for a statistical tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a compact introductory sentence followed by labeled usage examples and a clear return list. The examples are repetitive in structure but vary in filter combinations, which is helpful for an agent. Minor redundancy exists (e.g., 'memory_stats' repeated many times), but overall it's efficient for the information density.
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 compensates fully by listing all return fields (count, type distribution, top 20 tags, importance distribution, keyword frequency). The four examples cover all parameter types (no params, query-only, timeRange, combined params, tags). This is complete for a stats tool with optional filtering.
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 75% (3 of 4 parameters have descriptions). The description adds value by showing concrete usage patterns for combining parameters (e.g., query + minImportance, tags only), which the schema alone does not convey. The 'query' parameter's wildcard support is mentioned in both schema and description, but the examples clarify behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves memory statistics with optional filtering. It distinguishes itself from siblings like 'remember' and 'recall' by focusing on aggregation stats rather than individual memories, and from 'search' by providing structured distributions rather than raw results.
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 includes five usage examples showing when to use different filter combinations (e.g., query, timeRange, tags), implicitly guiding the agent on when to apply each parameter. While no explicit 'when not to use' is given, the examples clearly demonstrate the tool's scope for aggregated statistics, differentiating it from retrieval-oriented 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 are provided, so the description carries full burden of behavioral disclosure. It clearly states it works 'regardless of authentication state', which is a critical behavioral trait. It also implies the tool is read-only and non-destructive ('Discovery-only'). However, it doesn't detail rate limits or pagination behavior for the catalog, which would enhance transparency further.
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 fluff. Front-loaded with the core purpose, immediately followed by usage guidance and prerequisites. Every sentence adds unique 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?
Given no output schema, the description adequately explains return contents ('id, title, url'). The tool is simple (1 param, no enums, no nested objects) and the description covers the key behavioral aspect (authentication-agnostic). The only minor gap is absence of details on result ordering or maximum results, but the simplicity keeps completeness high.
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 goes beyond the schema by stating the tool returns 'id, title, url' and that the query searches for 'JauMemory tools or capabilities', providing context on the scope of the search. It could further clarify the format of the query parameter (e.g., free text vs. structured), but already adds value above the schema alone.
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 ('Returns'), the resource ('JauMemory tool catalog'), and the specific fields returned ('id, title, url'). It distinguishes from siblings by explicitly naming 'recall' as the alternative for memory access, and clarifies the scope is 'discovery-only' regardless of authentication.
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 tells when to use this tool ('discovery-only') and when not to (use 'recall' for memory access after login). It also specifies the exact prerequisite steps ('mcpLogin + mcpAuthenticate') for the alternative, providing clear guidance against confusion with sibling tools like 'recall' or 'fetch'.
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 clearly states the tool is read-only ('Discovery-only'), reveals what it does NOT do ('Does NOT look up memory by UUID'), and mentions the domain of lookup ('route documentation'). It could be improved by stating if there are any side effects or auth requirements beyond the implicit login prerequisite mentioned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each earning its place: first sentence declares purpose/type, second clarifies what it does NOT do, third provides alternative usage path. No redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 required param, no nested objects, no output schema), the description is complete. It explains the tool's purpose, scope, limitations, and relationship to sibling tools. No output schema means description needn't explain return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with one parameter ('id') described as 'Tool ID to fetch documentation for'. The description adds context by clarifying the 'id' is a 'Tool ID' (not UUID for memory) and that the output is 'route documentation'. This adds semantic value beyond the schema, though the schema already had adequate coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Returns route documentation for a tool by name' with a clear verb ('Returns'), resource ('route documentation for a tool'), and scope (by name). It also distinguishes itself from sibling tools like `recall`, which is for memory access, and correctly positions itself as a discovery-only introspection tool.
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 usage guidance: it says when to use this tool ('Discovery-only'), when NOT to use it ('Does NOT look up memory by UUID'), and directs the agent to an alternative (`recall`) with a prerequisite ('after completing mcpLogin + mcpAuthenticate'). This fully addresses when-to-use vs not-to-use.
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 being provided, the description fully discloses behavioral traits: it does NOT deploy, it verifies via the NOMCP files endpoint before finalizing, and rolls back the tool entry on failure. This covers safety, failure modes, and required credentials, all beyond what annotations would typically provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with five focused sentences. It front-loads the core purpose and the critical caveat ('Does NOT deploy'), then logically proceeds to requirements, usage guidance, and post-registration steps. Every sentence earns its place with no 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?
For a tool with no output schema, the description explains the registration process, verification, rollback, and post-use instructions. It implicitly indicates the return value (a slug) by telling the agent to use tool_call with it, but could explicitly state that the tool returns a slug for clarity. Otherwise, it is well-rounded for the tool's complexity.
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 value by explaining the subdomain parameter format (e.g., 'json-validator') and that 'name' defaults to the subdomain. It also clarifies the auth_path enums and that nomcp_credential_id must be a UUID. This adds meaningful context beyond the schema definitions.
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 registers an existing Berrry app as a JauMemory tool, using the verb 'register' and specifying the resource. It explicitly differentiates from the sibling 'berrry_create_tool' by noting that this tool does not deploy and is for apps already created via the web UI or other paths.
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 when-to-use guidance: 'USE THIS WHEN: you already created the app via the Berrry web UI...' and contrasts with 'berrry_create_tool' for deploying fresh files. It also notes the prerequisite of storing a vault credential and gives post-registration instructions for tool_call and NOMCP file management.
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:

[![JauMemory-mcp-server MCP server](https://glama.ai/mcp/servers/jefedeoro/JauMemory-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/jefedeoro/JauMemory-mcp-server)

Score Badge

Copy to your README.md:

[![JauMemory-mcp-server MCP server](https://glama.ai/mcp/servers/jefedeoro/JauMemory-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/jefedeoro/JauMemory-mcp-server)

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/jefedeoro/JauMemory-mcp-server'

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