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

Annotations only declare the generic safety profile (readOnlyHint=false, idempotentHint=false, destructiveHint=false). The description adds the substantive traits: the room is shared/cross-vendor (Claude/ChatGPT/Cursor), the default invite scope is read_write, and it returns an address to be reused as the `domain` argument elsewhere. It does not address name-collision behavior for a non-idempotent create, which leaves one gap.

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?

Front-loads the definition of the room before the usage trigger and the follow-on tools. It is a long sentence chain but each clause carries distinct information (scope, cross-platform reach, default invite scope, return value, next steps); minor tightening is possible but nothing is fat.

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?

An output schema exists, so line-by-line return documentation is unnecessary, yet the description still tells the agent what the address is for. Combined with the invite/read/write follow-on pointers, an agent has enough to create and then use a room; only edge cases (duplicate names, permissions to create) are unaddressed.

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 `name` (unique within account) and the optional `description`; the baseline is 3. The description adds no additional meaning about the two parameters themselves (the uniqueness rule it references is already 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?

States a specific verb+resource ('Create a SHARED memory room') and immediately distinguishes it from siblings by defining what a room is (a space other people's assistants can read/write). An agent can tell it apart from memory_list_rooms, memory_join_room, and memory_invite_to_room without opening any schema.

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?

Gives an explicit trigger condition and a concrete user-utterance example ('make a room for me and my teammate'), plus points to memory_invite_to_room as the way people join. It stops short of stating when NOT to create a room or how it differs for solo use, so it is clear context rather than full routing 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 only declare readOnlyHint=false and destructiveHint=false; the description goes well beyond them by explaining the actual effect (positive raises ranking across all the user's tools, negative lowers it so other memories out-rank it), the non-destructive boundary ('nothing is erased and nothing decays with time'), and the permission limitation. No statement conflicts with the annotation set.

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 carrying distinct load: purpose, effect model, and invocation rules. The purpose and ranking consequence are front-loaded before the edge cases, 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?

With an output schema present, return values need no explanation. The description covers the mutation effect, the value convention, the conditional domain argument, and the permission edge case, leaving nothing an agent needs in order to call it 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 coverage is 100%, so the schema already documents all three parameters; the baseline would be 3. The description adds situational meaning by tying memory_ids to 'the ids of those memories' just consumed and restricting domain to shared-room addresses read as xroom, which helps the agent supply them correctly in context.

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+resource ('Report whether memories returned by memory_read were actually helpful') and immediately frames the tool's role as a learning signal rather than a log, which cleanly separates it from siblings like memory_read and memory_write. An agent can identify this as the ranking-feedback tool without opening any schema.

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 gives explicit when-to-use conditions ('after an answer that relied on or rejected memories from memory_read'), the exact value convention for outcome (1 helpful, -1 wrong/stale), and a conditional rule for domain (shared-room reads only). It even names an exclusion: a read-only room member cannot rate the room's memories.

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 readOnly/idempotent/non-destructive, and the description reinforces 'Read-only.' Beyond that it discloses genuinely non-obvious behavior: the depth 2/3 weight floor of 0.05 applied at every hop, and the fact that a non-room domain value silently has no effect. It stops short of describing result ordering or truncation semantics.

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?

Front-loaded with purpose, then scope, then caveats, in roughly four dense sentences with no filler. It is information-rich but borders on restating schema detail, slightly reducing economy.

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?

An output schema exists so return shape need not be explained, and annotations cover the safety profile. The description fills the remaining gaps an agent needs: the shared-room domain exception, the cross-hop weight floor, and the non-error handling of unrecognized seeds.

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 all five parameters are already documented in the schema, including the depth/min_weight interaction and the domain address format. The description restates this at a high level rather than adding syntax or semantics the schema lacks, which is the expected baseline.

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 verb and resource ('Reads the association edges around given concepts') and enumerates what each edge carries (weight, outcome valence, co-activation count). It is distinguishable from the closer sibling memory_read, which is referenced by role ('explain why a read expanded to a concept').

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?

Gives two concrete use cases — inspecting what the store learned and explaining an expansion — which implicitly contrasts with memory_read. However, it never states when NOT to use this tool, e.g. when a flat top_k read is sufficient, so the routing is clear but incomplete.

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 only carry the generic mutation profile (readOnlyHint=false, idempotentHint=false), so the description must add the real behavior — and it does: invites are single-use by default, max_uses lets one invite admit several people, and it explains the out-of-band delivery flow (user forwards the message, recipient either opens the link or dictates the code to their own assistant). That is exactly the kind of non-obvious semantics annotations cannot express.

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 core action is front-loaded in the first sentence, followed by invite lifetime semantics and then the routing condition. Four sentences, each carrying distinct information, 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?

For a small mutation tool with an output schema (so return shape needn't be described) and full schema coverage, the description supplies the missing pieces: the invite artifact, its default single-use behavior, and the human-in-the-loop forwarding step. Nothing an agent needs to invoke it correctly is absent.

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 schema already documents all four parameters, setting a baseline of 3. The description still adds meaning about max_uses by framing the default as 'single-use' and the override as letting 'several people join with the same one,' which clarifies intent rather than restating the field. scope and expires_in_days are left to 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?

States a specific verb and resource ('Mint an invite for a room you own') plus the concrete deliverable ('ready-to-forward message'), which separates it cleanly from memory_join_room and memory_create_room. An agent can pick this tool without opening the schema.

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?

Gives an explicit trigger condition ('Use when the user asks to invite someone to a room they own') and connects it to memory_create_room for the just-created-room case. It does not state when not to use it, e.g. that the recipient side belongs to memory_join_room, so it stops short of a full when/when-not/alternatives treatment.

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 only carry readOnlyHint/idempotent/destructive flags; the description adds real behavioral context beyond them: the result yields the room's address used as `domain`, and it explains that memory_write succeeds only with read_write scope, is refused for read-only membership, and is reported as unknown when the server gives no scope. This is honest, non-contradictory disclosure that an agent could not infer from annotations alone.

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?

Purpose and trigger are front-loaded, and every sentence carries information. The final scope sentence is long and clause-heavy, but its content (write permission semantics) earns its place.

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 an output schema present, the description need not enumerate return fields, yet it still explains the key returned address and its role as the `domain` for memory_read/memory_write, plus the membership-scope outcomes. Nothing needed to invoke or chain this tool is missing.

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% and the single parameter is documented there, including the 'mnvr_...' format. The description repeats the same prefix hint but adds no syntax or validation detail beyond the schema, so the baseline 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?

States a specific verb and resource ('Join a shared memory room') plus the required credential ('invite code, starts with mnvr_'), which cleanly separates it from siblings like memory_create_room and memory_invite_to_room.

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?

Gives explicit trigger conditions ('use when the user pastes an invite code or says join room with code ...') and names the downstream tools (memory_read, memory_write) this enables. It stops short of naming an alternative tool or an explicit when-not-to-use case, so it is not a full 5.

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 mark the tool read-only and idempotent, and the description adds genuinely useful behavioral context: pages are complete within a scope, size-bounded pages can return fewer than `limit`, cursors are required to avoid dropped entries, and rooms are separate stores. No contradiction with the annotations.

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

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

Dense and front-loaded: the core action appears in the first sentence, and every caveat earns its place by either explaining a consequence or a required condition. Warnings such as size budgeting and room separation are actionable rather than 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?

The description covers everything needed to invoke correctly: when to use it, when to scope by domain, how paging works, and where room addresses come from memory_list_rooms. Since an output schema exists, the lack of return-format explanation is not a gap.

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?

Even with 100% schema coverage, the description adds meaning beyond the schema: `since` is framed as a novelty watermark, cursors continue listings without skips/duplicates, `limit` is a ceiling affected by page size, and `domain` unlocks shared rooms. The schema already documents syntax well, and the description reinforces behavior around 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 the exact behavior—lists the newest memories first—and immediately distinguishes itself from semantic search by contrasting 'what do I know about X' with 'what happened lately.' This also cleanly separates it 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?

Gives explicit use cases (resuming work, catching up on a shared room, reviewing recent activity), tells when to pass `since`, and when `domain` is mandatory. It even specifies the exclusion condition: an unscoped call never covers rooms, so an agent knows exactly when to supply the room address.

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, idempotentHint and destructiveHint=false, so safety is covered. The description adds genuinely new behavior: which rooms are returned, that the returned address feeds the `domain` argument on memory_read/memory_write, and that read-only membership causes writes to be refused. Return value shaping isn't described, but the key membership caveat is.

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?

One dense sentence that front-loads the core scope (owned + joined) and then the usage rationale. Every clause earns its place, though the em-dash interjection about read_write scope makes it slightly heavy for a list tool.

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?

An output schema exists, so return-format explanation is not required, yet the description still conveys the practically important bit of the output (the address for use as `domain`). For a zero-param, read-only list tool, nothing an agent needs is missing.

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 takes zero parameters, so the baseline is 4. The description's mention of the `domain` address is output-to-other-tools mapping rather than input semantics, but it adds useful cross-tool meaning without overloading the empty 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?

States a specific verb+resource (list shared memory rooms) and immediately scopes it to the two membership sources (OWNED + JOINED). Clearly differentiates from siblings like memory_create_room and memory_join_room by framing this as the discovery operation.

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 says when to use it ('RE-FIND a room in a new session') and when not to (instead of having to create or re-join it), giving concrete trigger phrasings. The alternative tools are implied by name and purpose.

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?

Goes well beyond the readOnly/idempotent annotations by disclosing that results are relevance-ranked (or newest-first via order_by), that each result carries an id, that memory persists across sessions and across other AI tools, and that corrections happen by rewriting rather than deleting. This is substantive operational context.

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

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

The content is front-loaded with purpose and use conditions, and each sentence carries information. It is fairly dense but a couple of the trailing sentences (feedback, correction) sit slightly awkwardly at the end rather than being tight to the core search purpose.

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 an output schema present and 100% schema coverage, the description need not explain return shapes, and it still supplies the cross-session/cross-tool persistence model and the correction workflow. Nothing an agent needs to select and call the tool correctly is missing.

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% and the schema already explains order_by, top_k caveats, domain scoping, etc. in depth. The description's mention of order_by: 'recency' and id-carrying results largely restates what the schema documents, so it does not add meaningful new parameter semantics.

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 verb+resource ('Search long-term memory') and immediately names the scope of retrievable content (preferences, decisions, project setup, people, earlier context). It also implicitly distinguishes itself from memory_list_recent by framing the operation as a relevance-ranked search rather than a brute listing.

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 it ('applies when an answer may depend on something from an earlier session or another tool') and when not to ('not needed for general world knowledge'). It also routes the agent to siblings: memory_feedback for recording usefulness, memory_write for correcting a stale memory rather than deleting.

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, destructiveHint=false and idempotentHint=true, so 'Read-only — changes nothing' is reinforcement rather than new information. However, the claim that the memory is shared across all connected AI tools is a genuinely useful scope disclosure not present in any structured field.

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?

Front-loaded with purpose, then scope, then usage, then safety — a sensible order. Three sentences with little waste, though the closing 'Read-only — changes nothing' repeats what the annotations already certify.

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 tool with an output schema and full annotation coverage, the description supplies everything an agent needs: what the call returns, whose data it reflects, and when it is worth calling. No 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?

The tool takes zero parameters, so per the rubric the baseline is 4. The description correctly adds background on what the shared store is, which is the only meaningful 'parameter-like' context available for a no-arg call.

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 verb and resource ('Get an overview of the stored memory') and enumerates exactly what the overview contains: total count, concept associations, domains, average quality scores. It is unambiguous within the sibling set, though it never names a sibling like memory_read or memory_list_recent to draw the boundary explicitly.

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?

Gives three concrete triggers: orienting yourself, confirming the exact domain name before writing, and answering 'what do you remember'. That is clear when-to-use guidance, but it offers no exclusion or explicit alternative (e.g. use memory_read when you need the raw contents).

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 only cover the safety profile (readOnlyHint=false, idempotentHint=false, destructiveHint=false); the description goes well beyond them. It discloses the novelty gate that refuses near-duplicate writes outside shared rooms, states that the result reports stored-vs-refused, and enumerates prohibited content classes (passwords, keys, payment data, MFA, IDs, health records). The refused-write behavior particularly explains why the call is not idempotent.

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?

Front-loaded with purpose, then when-to-use, prohibitions, runtime behavior, and content advice in a logical order. Slightly dense and a bit long for one paragraph, but every sentence carries distinct information 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?

An output schema exists, so return values need no explanation, and the description still covers purpose, usage boundaries, safety prohibitions, duplicate-refusal behavior, and cross-tool persistence. Nothing an agent needs in order to decide whether and how to call this tool is missing.

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 domain, content, and concepts are already well documented in the schema, including the byte-for-byte domain matching warning. The description's only parameter guidance, writing content as a self-contained statement, largely restates the schema's own wording. Baseline 3 is appropriate when structured fields carry the parameter detail.

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 first sentence gives a specific verb and resource (store a memory) plus a distinguishing scope: long-term persistence across sessions and across every connected AI tool. That scope cleanly separates it from memory_read, memory_list_recent, and memory_stats. An agent knows exactly what this tool produces without opening the schema.

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 explicit inclusion criteria (stated preferences, decisions, facts about people/roles/project setup, lessons learned) and an explicit exclusion (transient chatter that only matters this turn). It also names memory_stats and memory_list_rooms as sources for exact domain/room names, though that routing guidance lives in the schema rather than the description. Clear context and exclusions, but no direct pointer to the read side for retrieving what was written.

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 annotations (readOnlyHint, destructiveHint), the description adds a critical behavioral guarantee: 'the secret VALUE is never returned or shown to you, and no tool on this server returns it' and 'Only YOUR account's secrets are listed'. These privacy and scoping constraints are not derivable from annotations and are essential for correct use, making this a strong 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.

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

The description is front-loaded with the core purpose, immediately followed by the most critical constraint (value never returned), then a practical use case and account scoping. Every sentence serves a distinct purpose; even the seemingly repetitive privacy clauses add nuance (not returned, not shown, not available from any tool). It is efficient and highly informative.

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 has no parameters, an output schema exists, and the annotations cover safety properties, the description provides everything an agent needs: what the tool lists, privacy guarantees, and account scope. There is no missing information that would affect 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?

The tool has zero parameters, so the schema fully covers parameter semantics (100% coverage trivially). The baseline for 0 parameters is 4; the description adds no parameter-specific info, but none is needed, so a 4 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 tool 'List the secrets stored in your Mnemoverse Vault' with a specific verb and resource, and specifies the output is limited to 'ALIAS and purpose only'. It differentiates from the sibling memory_* tools by explicitly scoping to the vault and secrecy domain, so an agent can instantly recognize its function.

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 an explicit when-to-use case: 'Use this to check WHICH secrets the user has stored and under what alias' with a concrete example. It does not mention when not to use or alternative tools, but since the sibling tools are all in a different domain, the guidance is sufficient for the context.

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