Ultra-fast (<2ms) persistent memory workspace with strict tenant isolation, cryptographic provenance, and cross-session synchronization for AI agents in Claude, Cursor, and custom agent fleets.
Scored across 8 tools
The memory tools (remember, search, forget, validate_memory) are distinct in action, and the github_readonly tools are clearly scoped to read-only GitHub operations. gateway_call is somewhat ambiguous as it could overlap with search/remember if the downstream server has similar tools, but its purpose as a proxy is distinct enough.
Memory tools use lowercase verbs (remember, search, forget, validate_memory) while GitHub tools use a dotted prefix (github_readonly.get_file_contents, github_readonly.pull_request_read). The naming is readable but mixes conventions: snake_case for validate_memory and get_file_contents, while pull_request_read uses a noun_verb pattern instead of verb_noun.
8 tools is a reasonable count for a memory server with GitHub integration. Each tool has a clear role, though the GitHub tools are only read-only and the gateway_call adds a generic proxy function that could be considered extra.
The memory lifecycle is covered (remember, search, forget, validate_memory), but there is no update/edit memory tool, and the GitHub tools are limited to read-only operations without any write capabilities. The gateway_call tool could fill gaps but depends on external servers.
Soft-delete a memory by memory_id or cascade-delete all memories from a source_id, cleaning up graph edges.
| Name | Required | Description | Default |
|---|---|---|---|
| memory_id | No | Specific unique memory ID to soft-delete | |
| source_id | No | Source ID to cascade-delete all associated memories from | |
| workspace | No | Workspace containing the target memory | default |
| Name | Required | Description |
|---|---|---|
| at | Yes | ISO 8601 deletion timestamp |
| id | No | Forgotten memory ID if deleted by ID |
| forgotten | No | True if the memory was found and deleted |
| source_id | No | Forgotten source ID if cascade deleted by source |
| tenant_id | Yes | Tenant identifier |
| workspace | Yes | Workspace name |
| api_version | Yes | API version of the memory server |
| forgotten_count | No | Number of cascade-deleted memories |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and readOnlyHint=false. The description adds meaningful behavioral context by specifying that deletion is a soft-delete rather than a hard delete, and that graph edges are cleaned up. This goes beyond the annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that front-loads the primary action and resource, then states both deletion modes and the side effect. Every phrase earns its place with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity, existing output schema, and annotations, the description is largely complete: it names the operation, the two invocation modes, and the graph cleanup side effect. The main gap is that it does not explicitly state that at least one of memory_id or source_id must be supplied, nor what happens if both are set.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents each parameter. The description maps memory_id to a single soft-delete and source_id to a cascade delete, but this largely restates the schema descriptions. It does not clarify whether exactly one of the two identifiers is required or how conflicts are resolved if both are provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: soft-delete a memory by memory_id, or cascade-delete all memories from a source_id. It also names the side effect of cleaning up graph edges, and it is easily distinguished from sibling tools like remember, search, and validate_memory.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use the tool and which mode to use: single memory deletion via memory_id versus cascade deletion via source_id. It does not explicitly mention alternatives or exclusion conditions, but the two usage modes are explicit enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Call one discovered tool on an enabled, owner-curated downstream MCP server.
| Name | Required | Description | Default |
|---|---|---|---|
| tool | Yes | Target tool name to invoke on the downstream server | |
| server | Yes | Downstream MCP server identifier (e.g. github_readonly) | |
| arguments | Yes | Input arguments dictionary passed to the downstream tool | |
| project_id | No | Optional project ID context for isolated execution |
| Name | Required | Description |
|---|---|---|
| result | No | Downstream tool execution result payload |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are neutral (readOnlyHint=false, idempotentHint=false, destructiveHint=false) and provide no safety profile. The description adds contextual governance details ('enabled', 'owner-curated', 'discovered') but does not disclose potential side effects, authentication requirements, or execution behavior beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no redundancy. It conveys the core purpose efficiently and front-loads the essential action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is minimal but the schema and output schema cover parameter details and return structure. However, for a generic gateway tool, an agent would benefit from more context about how discovered servers/tools are identified or how arguments are routed, which the description omits.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with all four parameters already described in the input schema. The description adds no additional parameter semantics, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Call') and resource ('one discovered tool on an enabled, owner-curated downstream MCP server'), which is clear and not a tautology. It distinguishes this tool as a generic gateway to downstream MCP servers, though it does not explicitly contrast it with sibling direct-access tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus the sibling tools such as github_readonly.get_file_contents or search. There is no mention of when a user should prefer the gateway over direct server tools, nor any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the contents of a file or directory from a GitHub repository
| Name | Required | Description | Default |
|---|---|---|---|
| ref | No | Accepts optional git refs such as `refs/tags/{tag}`, `refs/heads/{branch}` or `refs/pull/{pr_number}/head` | |
| sha | No | Accepts optional commit SHA. If specified, it will be used instead of ref | |
| path | No | Path to file/directory | / |
| repo | Yes | Repository name | |
| owner | Yes | Repository owner (username or organization) | |
| fields | No | Subset of fields to return for each entry when the path is a directory. If omitted, all fields are returned. Ignored when the path is a single file. Use this to reduce response size when listing directories and you only need specific fields, e.g. just 'name' and 'type'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are supplied, so the description carries the full burden of behavioral disclosure, yet it only states the operation without mentioning read-only semantics, error cases, default ref behavior, or response format. The 'github_readonly' prefix hints at safety, but the description itself adds no behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence states the complete purpose with no filler words. It is appropriately sized for a straightforward resource access operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The schema covers parameter semantics well, but the absence of annotations and an output schema leaves the description as the sole behavioral guide. It fails to mention return shape (e.g., whether file content is raw or encoded) or default ref semantics, which an agent would need for fully correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters are already fully documented in the input schema; the description contributes no additional meaning about owner, repo, path, ref, sha, or fields. A baseline 3 is appropriate since the description does not need to compensate for schema gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific action ('Get the contents') and a precise resource ('a file or directory from a GitHub repository'), which clearly distinguishes it from sibling tools that target user info or pull requests. The verb/resource combination leaves little ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit when-to-use guidance or comparison with alternatives such as github_readonly.get_me or github_readonly.pull_request_read. The intended use is only implied by the resource referenced, so an agent must infer when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get details of the authenticated GitHub user. Use this when a request is about the user's own profile for GitHub. Or when information is missing to build other tool calls.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. 'Get details' implies a read-only operation, and 'authenticated' signals an auth requirement. However, the description does not explicitly state that there are no side effects, nor does it describe what fields will be returned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the core purpose and followed by useful usage guidance. It contains no filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read-only tool, the description gives enough context for selection and invocation. However, there is no output schema and the description does not specify what 'details' includes, so an agent may not know what to expect in the response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters and 100% schema coverage, so there is nothing for the description to add about parameter semantics. The baseline for zero-parameter tools is 4, and the description correctly avoids inventing unnecessary parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Get details of the authenticated GitHub user.' This clearly distinguishes the tool from sibling tools like github_readonly.get_file_contents and github_readonly.pull_request_read, which focus on files and pull requests rather than the user's own profile.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool: when a request concerns the user's own GitHub profile, or when information is missing to construct other tool calls. It does not explicitly name alternatives or exclusion conditions, but the given context is sufficiently clear for this simple tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get information on a specific pull request in GitHub repository.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number for pagination (min 1) | |
| repo | Yes | Repository name | |
| after | No | Cursor for pagination, used only by the get_review_comments method. Pass the endCursor from the previous page's PageInfo to fetch the next page. | |
| owner | Yes | Repository owner | |
| method | Yes | Action to specify what pull request data needs to be retrieved from GitHub. Possible options: 1. get - Get details of a specific pull request. 2. get_diff - Get the diff of a pull request. 3. get_status - Get combined commit status of a head commit in a pull request. 4. get_files - Get the list of files changed in a pull request. Use with pagination parameters to control the number of results returned. 5. get_commits - Get the list of commits on a pull request. Use with pagination parameters to control the number of results returned. 6. get_review_comments - Get review threads on a pull request. Each thread contains logically grouped review comments made on the same code location during pull request reviews. Returns threads with metadata (isResolved, isOutdated, isCollapsed) and their associated comments. Use cursor-based pagination (perPage, after) to control results. 7. get_reviews - Get the reviews on a pull request. When asked for review comments, use get_review_comments method. Use with pagination parameters to control the number of results returned. 8. get_comments - Get comments on a pull request. Use this if user doesn't specifically want review comments. Use with pagination parameters to control the number of results returned. 9. get_check_runs - Get check runs for the head commit of a pull request. Check runs are the individual CI/CD jobs and checks that run on the PR. | |
| perPage | No | Results per page for pagination (min 1, max 100) | |
| pullNumber | Yes | Pull request number |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'Get information' without explicitly stating that the operation is read-only or has no side effects, though the tool name includes 'readonly'. It also does not disclose any rate limits, permissions, or the fact that the return varies significantly by method.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise and free of fluff. However, given the tool's complexity (7 parameters, 9 method variants), it is under-specified; a more structured description that summarizes the method options would be more effective without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with such a rich method enum and pagination options, the description is far too thin. It does not mention that different methods return different data types, how pagination works, or any expectations about the response. The schema fills some gaps, but the description alone leaves an agent without critical context to choose the right method.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage of parameter descriptions, including a detailed explanation of the method enum and pagination parameters. The description adds no extra parameter meaning beyond the schema, so it meets the baseline but does not exceed it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb-resource pair ('Get information on a specific pull request'), which is distinct from the sibling tools like get_file_contents or get_me. However, it does not hint at the method parameter's multiple sub-actions (get_diff, get_files, etc.), so the purpose is somewhat broad and not fully differentiated internally.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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, nor when not to use it. It does not mention sibling tools or the conditions that would make one method preferable over another. The method parameter descriptions inside the schema give some usage hints, but the tool description itself offers no such context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Store a durable memory with provenance and an auditable trust status.
| Name | Required | Description | Default |
|---|---|---|---|
| scope | No | Visibility and access scope (shared, private, or restricted) | shared |
| source | No | Origin type or author of the memory (e.g. owner, agent, user) | owner |
| content | Yes | Text content of the memory or fact to store | |
| fact_key | No | Canonical key to identify updates and detect conflicts on the same fact | |
| source_id | No | Identifier of the source document, file, or session | |
| workspace | No | Target workspace partitioning the memories | default |
| confidence | No | Confidence score between 0.0 and 1.0 | |
| source_hash | No | Cryptographic hash of the source content for freshness tracking | |
| source_revision | No | Version or revision tag of the source artifact |
| Name | Required | Description |
|---|---|---|
| id | Yes | Unique identifier of the stored memory |
| scope | Yes | Visibility scope (shared, private, or restricted) |
| status | Yes | Trust and verification status (verified, unverified) |
| source_id | No | Identifier of the origin document, file, or session |
| tenant_id | Yes | Tenant identifier |
| workspace | Yes | Target workspace containing the memory |
| created_at | Yes | ISO 8601 creation timestamp |
| project_id | No | Project identifier |
| api_version | Yes | API version of the memory server |
| source_hash | No | Cryptographic content hash of the source |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a write operation (readOnlyHint=false, idempotentHint=false, destructiveHint=false). The description adds 'durable' and 'auditable trust status', which imply persistence and provenance tracking, but it doesn't disclose details like whether the memory is immediately visible, how conflicts are handled, or what the output schema contains. It adds some context beyond annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that front-loads the core action ('store a durable memory') and adds two meaningful qualifiers. It earns its place without redundancy, though it could have added a bit more practical guidance without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 9 parameters, an output schema, and no explicit usage guidance, the description is adequate but not complete. The output schema likely explains return values, and annotations cover the safety profile, but the description doesn't clarify when to use this tool versus 'forget' or 'validate_memory', nor does it explain the provenance/trust model that the description promises. It's a minimum-viable definition.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 9 parameters. The description adds the concept of 'provenance' and 'auditable trust status', which loosely maps to source, source_id, source_hash, source_revision, and confidence, but it doesn't explicitly explain how those parameters relate to the described behavior. Baseline 3 is appropriate since the schema carries the parameter documentation burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('store') and resource ('durable memory') and adds two distinguishing attributes: provenance and auditable trust status. It is clear enough to differentiate from siblings like 'search' and 'forget', though it doesn't explicitly name them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is the tool for persisting memories, and sibling names like 'search' and 'forget' suggest alternatives, but there is no explicit when-to-use or when-not-to-use guidance. An agent can infer usage from the verb and resource, but the description doesn't state conditions for choosing this over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search memories and annotate provenance, stale and conflict status.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of memory results to return (1-50) | |
| query | Yes | Semantic or keyword query text to search across memories | |
| scope | No | Optional scope filter (e.g. shared, private) | |
| workspace | No | Workspace to search memories within | default |
| exclude_stale | No | Whether to filter out stale memories from results | |
| current_source_hash | No | Optional current source hash to detect stale memories |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds useful context beyond the readOnly and idempotent hints by stating that search results are annotated with provenance, stale, and conflict status. It doesn't cover pagination or default filtering, but the safety profile is already established by annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no filler or repetition. Every word contributes, and the core action and distinctive output characteristics are conveyed efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only search tool with a rich schema, output schema, and safety annotations, this description is largely sufficient for selection and invocation. It lacks explicit exclusions or elaboration of 'annotate,' but the structured fields carry much of the remaining burden.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters are already well documented. The description adds no parameter-level guidance, which meets the baseline but does not exceed it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a clear action and resource: 'Search memories' and adds that results carry provenance, stale, and conflict annotations. This differentiates it from write/validation siblings like remember, forget, and validate_memory, though the verb 'annotate' is slightly ambiguous and could be misread as a mutation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or alternative routing is provided. The use case is implied by the name and description—searching memories—but there is no guidance on when to prefer this over validate_memory or how workspace/scope affect selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate one source manifest hash and report stale/conflicting memories.
| Name | Required | Description | Default |
|---|---|---|---|
| scope | No | Optional scope filter | |
| source_id | No | Identifier of the source entity being validated | |
| workspace | No | Workspace to inspect memories within | default |
| current_source_hash | No | Fresh cryptographic hash of the current source content |
| Name | Required | Description |
|---|---|---|
| checked | Yes | Number of memories evaluated |
| source_id | Yes | Source identifier that was validated |
| stale_ids | No | List of memory IDs whose hash differs from current |
| tenant_id | Yes | Tenant identifier |
| workspace | Yes | Target workspace name |
| api_version | Yes | API version of the memory server |
| stale_count | Yes | Total count of stale memories |
| conflict_ids | No | List of memory IDs with fact conflicts |
| conflict_count | Yes | Total count of conflicting memories |
| current_source_hash | Yes | Current expected content hash |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the description adds the stale/conflicting reporting behavior but does not disclose additional operational traits such as scope handling, hash comparison details, or required permissions. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence communicates the action, scope, and result with no filler or repetition. Every word contributes.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a full input schema, explicit annotations, and an output schema present, the description provides the essential intent. It could mention what 'stale' or 'conflicting' means or how scope/workspace affect validation, but those are not critical gaps given the structured metadata.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description need not repeat parameter details. The phrase 'one source manifest hash' maps loosely to current_source_hash, but the description adds little interpretive value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses a specific verb ('Validate'), identifies the resource ('one source manifest hash'), and states the resulting output ('report stale/conflicting memories'). This clearly separates it from siblings like remember, forget, and search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to choose this tool over siblings, nor any exclusions or prerequisites. The purpose implies validation after source updates, but the description never states a use case or alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
