Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations indicate a write operation (readOnlyHint false) but the description adds valuable behavioral context: other people's assistants can read/write, the default scope is read_write, and the tool returns an address usable as a domain. This goes beyond what annotations alone provide, though it omits potential errors (e.g., if the room name already exists).

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 appropriately sized and front-loaded with the main purpose, then usage context, return value, and next step. Each sentence adds useful information, though the phrasing is slightly dense with multiple clauses.

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?

Although there is no output schema, the description explains what the tool returns and how to use it. It also covers cross-assistant sharing and the invitation workflow. It lacks discussion of failure cases or authorization requirements, but given the tool's simplicity and good annotations, it is largely complete.

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 already provides full parameter descriptions with 100% coverage, so the description does not need to add much. It does not repeat or enrich the parameter meaning beyond what's already in the schema, and the only extra info (returned address) is about output rather than parameters.

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 it creates a SHARED memory room, with a specific verb 'Create' and a resource ('memory room'). It distinguishes itself from sibling tools like memory_write and memory_invite_to_room by focusing on the room creation aspect.

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?

Explicitly states when to use the tool: 'Use when the user wants to share context or collaborate with someone else' and provides a concrete example. It also mentions the next step ('call memory_invite_to_room next') and how to use the returned address with memory_write/memory_read, offering clear context and alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description discloses important behavioral traits beyond the annotations: it explains the learning-signal mechanism ('positive feedback raises a memory's ranking... negative feedback lets it fade'), specifies scope ('across all of the user's tools'), and highlights the silent failure for shared domains. This adds significant context that the raw annotations (destructiveHint, openWorldHint) do not convey, and it does not contradict any annotation.

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 concise (three sentences) and well-structured: it opens with the core purpose, then explains the mechanism and timing, and finishes with an important caveat. Every sentence carries essential information with no filler or redundancy.

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 moderate complexity, the description covers all critical aspects: what it does, when to call it, the effect on memory ranking, the scope, and a failure mode. No output schema is present, so not describing return values is acceptable. The description is complete for an agent to invoke the tool correctly.

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 already fully describes both parameters with clear meanings and ranges (outcome from -1 to 1, atom_ids as array of strings). The description adds value by clarifying that atom_ids come from 'memory_read results' and by connecting the outcome values to the ranking effect ('positive feedback raises... negative feedback lets it fade'). While this is modest, it enhances the schema's information for a high-coverage case.

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 purpose: 'Report whether memories returned by memory_read were actually helpful.' It uses a specific verb ('report'), a specific resource ('memories'), and a clear context ('returned by memory_read'). This distinguishes it from sibling tools like memory_write (writing), memory_read (reading), and memory_delete (deleting).

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 explicit guidance on when to use the tool: 'Call it right after you act on (or reject) recalled memories.' It also clarifies what the tool is not ('not a log') and includes a caveat about when it won't work ('rating a memory that lives in a shared room silently does nothing'), effectively serving as a when-not-to-use warning. This is strong usage guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations indicate a write operation (readOnlyHint=false) and non-destructive (destructiveHint=false). The description adds behavioral context: the invite is one-time, produces a ready-to-forward message, and involves third-party sharing (messenger, link or code). No contradictions with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise with three sentences, each adding value: action, user flow, usage context. Front-loaded with the core verb and resource, no redundancy.

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 no output schema, the description adequately hints at return value ('ready-to-forward message'). The tool's complexity is low, and the description covers the essential workflow. Could be improved by explicitly stating the return format.

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 baseline is 3. The description does not add meaning beyond the schema; it mentions 'room you own' which aligns with room_id but provides no additional detail on scope or expires_in_days. Schema descriptions are adequate.

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 it mints a one-time invite for a room, with a specific verb 'mint' and resource 'invite'. It distinguishes from sibling tools like memory_create_room and memory_join_room by focusing on the invite creation action.

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 explicit guidance on when to use the tool: 'Use after memory_create_room, or whenever the user says invite <someone>.' While it doesn't list explicit exclusions, the context is clear and associates with specific user scenarios.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare idempotentHint=true, destructiveHint=false, and readOnlyHint=false. The description adds behavioral context: the returned address should be used as the domain for memory_write/memory_read. No contradictions. The description enhances understanding 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?

Three sentences, each serving a distinct purpose: stating the function, providing usage triggers, and outlining post-action steps. No unnecessary words or repetition.

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 simplicity (single parameter, no output schema), the description covers the necessary context: what the tool does, when to use it, and what to do with the result. Annotations cover safety traits. No gaps.

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 schema already documents the single parameter 'code' with full description and constraints (including the 'mnvr_' prefix). The description repeats this and adds usage context, but does not add meaningful new semantics beyond what the schema provides. Baseline 3 is appropriate.

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 action ('join') and the resource ('shared memory room'), with the target condition ('using an invite code'). It distinguishes from sibling tools like memory_create_room (create vs join) and memory_invite_to_room (invite others vs join).

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 provides usage triggers: 'when the user pastes an invite code or says something like join room with code ...'. It also gives post-join guidance. It does not explicitly state when not to use, but the positive use case is clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the readOnly/openWorld/idempotent annotations, the description reveals useful behaviors: ordering (newest first), the existence of an opaque cursor for paging, the completeness guarantee within one scope, and that room domains are separate stores not covered by an unscoped call. This adds significant context the annotations do not cover.

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?

Every sentence earns its place: the first states the core purpose, then a useful contrast with semantic search, followed by concrete usage hints for since/cursor, completeness, and domain requirements. It is compact (roughly 70 words) and front-loaded with the most important info.

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 complexity (6 params, no output schema), the description covers the key usage patterns: resuming work, catching up on rooms, using since/cursor, and domain scoping. It does not describe the return shape or fields, which would have been helpful since no output schema exists, but the context provided is largely sufficient for 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 coverage is 100%, so baseline is 3. The description adds meaning for `since` (last-seen time to get only new), `cursor` (page through older entries), and `domain` (required for shared rooms), elevating it above baseline. It does not comment on `limit`, `until`, or `exclude_author`, but those are already well-described in 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?

The description opens with a specific action and resource: 'List the NEWEST memories first'. It explicitly contrasts with semantic search ('this answers what happened lately') and clarifies no query is needed, distinguishing it clearly from sibling tools like memory_read and memory_list_rooms.

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?

It offers concrete use cases (resuming work, catching up on a shared room) and directly contrasts with semantic search. It also gives a hard rule: pass `domain` to cover rooms. However, it does not explicitly state when NOT to use this tool (e.g., for exact lookup vs memory_read), so it falls just short of perfect.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds meaningful context beyond annotations: the distinction between owned and joined rooms, and that returned addresses are meant to be passed as the 'domain' parameter. This is more than a minimal read operation, so a 4 is appropriate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with the action, includes an example, and every sentence adds value. No wasted words.

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 tool is a simple list operation with good annotations and no output schema. The description covers purpose, scope, the relationship to sibling tools, and a concrete use case, making it complete for the tool's complexity.

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 tool has zero parameters and the schema coverage is 100%, so the baseline is 4 per the rubric. The description references the 'domain' address output, which indirectly explains why no parameters are needed, but doesn't need to add anything 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?

The description clearly states a specific verb+resource: 'List the shared memory rooms you can use' and specifies scope (OWN + JOINED). It distinguishes from siblings by noting the rooms' addresses are for memory_write/memory_read and that this replaces create/re-join.

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?

Explicit use case is provided: 'Use this to RE-FIND a room in a new session' with an alternative explicitly named ('instead of having to create or re-join it'). This clearly guides when to use the tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context: memory is shared across sessions and tools, results are ranked by relevance or recency, and each result carries an id for feedback. It also clarifies that corrections are done via memory_write, not deletion. The only minor gap is not describing the exact return format, but given the annotations and the description's richness, a 4 is appropriate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured and front-loaded with the core purpose. It's a bit long but every sentence earns its place, covering usage guidance, behavioral notes, and parameter caveats. The use of bold for 'ALWAYS' and warnings like '⚠️' helps highlight key points. It's slightly verbose but not wasteful, so a 4 is appropriate.

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 complexity (7 parameters, shared memory, multiple siblings), the description is remarkably complete. It covers when to use, when not to, alternatives, parameter caveats, and behavioral traits. The output schema is absent, but the description mentions that results carry an id for feedback, which is sufficient. No critical information is missing for an agent to call this tool correctly.

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 parameters. The description adds value by explaining the top_k caveat (not a hard cap, can return more or fewer), the domain parameter's behavior (own domains vs shared rooms), and the exclude_author warning (not usable from here). This goes beyond the schema's basic descriptions, providing critical usage nuances. A 4 is justified because it adds meaningful semantics 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?

The description clearly states the tool's purpose: searching long-term memory for prior context, preferences, decisions, etc. It distinguishes itself from siblings by explicitly mentioning memory_list_recent and memory_feedback, and by noting that it searches own domains vs shared rooms. The verb 'search' and resource 'long-term memory' 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.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit guidance on when to use this tool: 'ALWAYS check here first when you're unsure whether you already know something' and when not to: 'no need to call it for general world knowledge you already hold.' It also names alternatives: memory_list_recent for complete bounded listings, memory_feedback for feedback, memory_write for corrections, and memory_list_rooms for room addresses. This is exemplary usage guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover readOnly, idempotent, non-destructive. The description adds important behavioral context: the memory is shared across all connected AI tools, and the tool confirms domain names before writing (a scoping warning). However, it doesn't disclose the return format or whether it might be slow, but the sharedness and read-only confirmation are valuable additions 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?

Three sentences, no filler. The first sentence front-loads the core functionality with specifics, the second adds the shared-memory context, and the third gives usage guidance. Every sentence carries weight.

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 zero parameters and a clear list of returned statistics, the description is nearly complete for an agent to call correctly. It lacks explicit mention of the output format (e.g., JSON shape), but the list of stats makes it inferable. The shared-memory note and read-only reassurance add confidentiality. Minor gap: it doesn't mention that this might return a lot of data or that it's a summary, but that's minor.

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 tool has zero parameters, so the description's job is to clarify what the result covers. The description enumerates exactly what statistics are returned (count, episodes vs prototypes, learned associations, domains, average quality). Since there are no parameters to document, this is a high baseline: it fully sets expectations for the output.

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 a specific verb ('Get an overview') and resource (stored memory: total count, episodes vs consolidated prototypes, learned associations, domains, average quality scores). It distinguishes from siblings by positioning itself as the orientation/overview tool, distinct from memory_list_recent or memory_read. The purpose is immediately clear and specific.

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 tells the agent when to use it: 'Use it to orient yourself, to confirm the exact domain name before writing to it, or when the user asks what you remember.' It also implicitly excludes it as a tool for reading specific memories (that would be memory_read) and for recent lists. This is clear, action-oriented guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations cover readOnlyHint=false, openWorldHint=true, etc., but the description adds crucial behavioral detail: 'an importance gate may filter low-value writes, so the result tells you whether the memory was stored or filtered.' It also sets content standards (self-contained statement) and security boundaries, going well beyond the structured metadata.

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 longer than typical but every sentence carries meaningful instruction: proactive triggers, prohibited content, behavior note, and content formatting. It is front-loaded with the core purpose and uses a clear 'Behavior:' section. Slightly verbose, but no wasted words.

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 write tool with no output schema, the description sufficiently covers return behavior ('result tells you whether the memory was stored or filtered') and usage constraints. It addresses cross-session/cross-tool persistence, importance filtering, and content quality—making the description complete for the tool's complexity.

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 all three parameters are described. The description adds semantic guidance on how to format `content` ('self-contained statement that still makes sense when recalled out of context'), which supplements the schema examples. This extra nuance improves parameter understanding beyond the schema alone.

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 a specific verb and resource: 'Store a long-term memory that persists across sessions AND across every AI tool.' It distinguishes from siblings by emphasizing cross-tool persistence and proactive recall, which sets it apart from memory_read or memory_list_recent.

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?

Explicit when-to-use guidance is provided: 'Call this PROACTIVELY the moment the user states a preference, makes a decision, or you learn a durable fact.' It also lists exclusions ('Never store passwords... skip transient chatter') and instructs not to wait to be asked, giving clear context for when to use this vs. other memory tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive. Description adds critical non-obvious behavior: 'the secret VALUE is never returned or shown to you, and no tool on this server returns it'. This system-wide guarantee goes well beyond annotations and prevents false expectations.

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?

Two sentences, front-loaded with the primary action ('List the secrets'), then immediately specifying critical constraints and usage. Every clause adds information; no filler or repetition.

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 parameterless, read-only list tool without output schema, the description fully covers purpose, return content (alias and purpose), non-return (value), account scoping, and a usage example. No meaningful gaps remain.

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?

Tool has 0 parameters, so schema coverage is 100% and there is nothing to document. Baseline for 0-param tools is 4. The description adds value by explaining the implicit scope of the list (your own account) and the output shape (alias and purpose), which compensates for lack of parameter meaning.

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 clearly states 'List the secrets stored in your Mnemoverse Vault' with specific verb and resource, and distinguishes from sibling memory_* tools by namespace (Vault vs memory). Adds clarity that it returns only aliases and purposes, not values, which fully defines the tool's scope.

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?

Provides an explicit use case: 'Use this to check WHICH secrets the user has stored and under what alias (e.g. the user says 'do I have a GitHub token saved?')'. It also clarifies scope ('Only YOUR account's secrets are listed'). Lacks explicit when-not-to-use or alternative tool mention, but no direct sibling exists, so clear context is sufficient.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.