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

Annotations cover the safety profile (readOnly=false, destructive=false, idempotent=false), so the description only needs to add context — and it does: it discloses the shared/cross-platform nature, the default read_write invite scope, and what is returned. It stops short of stating error behavior (e.g. duplicate-name rejection) or any permission/rate constraints, but the added context is substantial.

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, front-loaded with the core action and the usage trigger before the downstream instructions. The parentheticals (default scope, platform list, example phrase) are informative but make the middle slightly dense; nothing is redundant enough to remove outright.

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 an output schema exists, the description still names the key return value (the room's address) and explains how to feed it into memory_write/memory_read/memory_list_recent, which is the critical integration knowledge an agent needs. Nothing required to invoke and then use the result 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 both parameters are already documented in the schema. The description's mention of `domain` refers to other tools' parameters, not this tool's inputs, so it adds no meaning to `name` or `description` beyond the schema. 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 ('Create a SHARED memory room') and immediately qualifies the resource as a cross-assistant shared space, which cleanly separates it from siblings like memory_join_room and memory_list_rooms. An agent can identify the operation 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 ('Use when the user wants to share context or collaborate with someone else') with a concrete example utterance, and routes the complementary action to the named sibling memory_invite_to_room. The condition that selects this tool over its alternatives is stated rather than implied.

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?

Adds real context beyond annotations: positive feedback raises ranking, negative lowers it so others out-rank it, and nothing is erased or edited. However, it never mentions that repeated calls accumulate rather than being idempotent (idempotentHint=false), nor does it address whether feedback can be revised or overwritten.

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 and effect, then permissions. Slightly padded at the end: 'nothing is erased' and 'Saved text is not changed or deleted' are two near-identical reassurances that could collapse into one clause.

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 3-param mutation tool with full schema coverage and an output schema (so return values need no explanation), the description covers purpose, side effects, reversibility, domain requirement, and the permission gate. Nothing needed to call it 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 coverage is 100%, so the baseline is 3. The description restates the -1..1 outcome scale and the domain-for-shared-rooms rule, but both points are already spelled out in the property descriptions; it adds no format or edge-case detail the schema lacks.

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?

Opens with a specific verb+resource ('Rate memories returned by memory_read') and states the goal (improve future retrieval ranking). It is clearly distinguished from siblings like memory_write and memory_read, which store and fetch rather than score.

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 ties invocation to memories obtained from memory_read, states the domain-only condition for shared-room memories versus own memories, and names a hard exclusion: a read-only room member cannot rate the room's memories. That is when-to-use, when-not, and the gating prerequisite in one place.

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 the safety profile (readOnlyHint, idempotentHint, destructiveHint=false), but the description adds non-obvious behavior: the 0.05 weight floor auto-applied at depth 2/3 unless min_weight is passed, that a non-address domain value is silently a no-op, and that an unrecognised seed is not an error. These are genuine surprises an agent would otherwise hit, though the trailing 'Read-only' merely restates the 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?

Front-loaded with what the tool returns, then usage, then the domain caveat, then the depth/min_weight caveat — a sensible ordering with no filler sentences. The final 'Read-only.' is redundant against the annotations, the only wasted token.

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 explanation is unnecessary, and the annotations carry the safety profile. What remains — when to use it, the domain constraint, and the min_weight floor interaction — is fully covered, leaving nothing an agent needs 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 description coverage is 100%, so the baseline is 3, but the description adds cross-parameter semantics the schema states only locally: how depth and min_weight interact (0.05 floor at every hop including the first) and that domain must be a room address, unlike memory_read. It does not add anything for seeds or limit, which the schema already documents fully.

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). This clearly separates it from sibling memory_read, which retrieves memories rather than the link structure between 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?

Gives two concrete use cases: inspecting what a store has learned, and explaining why a read expanded to a concept — the latter implicitly points at memory_read as the upstream operation. It also scopes the domain parameter ('reads your own graph, or a shared room's when its address is passed'). No explicit when-not or named alternative tool, so it falls short of a 5.

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

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

Annotations only cover the safety flags (non-readonly, non-idempotent, non-destructive). The description adds substantial behavior beyond them: single-use default, max_uses for multi-recipient, the message flow (user forwards, recipient opens link or tells THEIR assistant the code). That workflow context is exactly what annotations cannot convey.

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?

Four tight sentences, front-loaded with the action and artifact. Each sentence carries distinct information (what it mints, the single-use default, the forwarding flow, the trigger) 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. The description supplies the trigger, defaults, and end-to-end workflow an agent needs; nothing material is missing for 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 all four parameters are already documented with defaults and ranges. The description only reinforces max_uses' single-use default, adding no syntax or format detail beyond the schema. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ('Mint an invite for a room') and immediately describes the concrete artifact produced (a ready-to-forward message). It is clearly distinguishable from siblings like memory_join_room or memory_create_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?

Explicitly says when to use it: 'when the user asks to invite someone to a room they own, including one just created with memory_create_room,' naming a sibling. It lacks an explicit when-not or an alternative for the recipient side, but the trigger context is unambiguous.

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?

With annotations declaring readOnlyHint=false, idempotentHint=true, destructiveHint=false and openWorldHint=false, the description still adds real content: the join returns a room address usable as `domain`, and write permission depends on membership scope, with read-only writes refused and unknown scopes reported as unknown rather than promised. This is unusually candid about permission outcomes, though it stops short of describing what happens on an invalid or expired code.

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 in the first two sentences, and every sentence carries information about downstream use. The closing scope sentence is dense and slightly convoluted, but it is not padding.

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 structure need not be re-explained, yet the description covers the one fact an agent needs to chain correctly (the address is the `domain` for reads) plus the write-permission conditionality. Complete for a single-parameter join tool.

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?

Only one parameter exists and schema coverage is 100%, so the schema already documents `code` and its 'mnvr_...' form. The description repeats the prefix convention without adding syntax, error behavior, or length/format nuance beyond the schema. 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 (join) and resource (shared memory room) plus the required input format 'mnvr_'. It is immediately distinguishable from siblings like memory_create_room and memory_invite_to_room, which are the adjacent operations in the same lifecycle.

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 ('use when the user pastes an invite code or says something like "join room with code ..."') and routes onward: the returned address is the `domain` for memory_read, and memory_write is conditional on scope. Alternatives and conditions are named rather than inferred.

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 the safety profile (readOnly, idempotent, non-destructive), and the description adds real behavioral context beyond them: completeness-within-a-scope, the size budget that can truncate a page below `limit`, the guarantee of no skips/duplicates across pages, and the `rooms_not_searched` signal on unscoped calls. It also discloses a limitation not visible elsewhere ('nothing is skipped there, unlike a semantic search').

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 opening sentence is well front-loaded and the paragraph advances from purpose to paging to scope. However, the size-budget/cursor mechanic is explained twice (once in prose, again in the `limit` description) and the paragraph is dense enough to be mildly repetitive.

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 6 optional parameters and an output schema present, the description supplies exactly what the schema cannot: which scope the call covers, why a page may be short, how to continue, and where the room-address list comes from. An agent has everything needed to call it correctly on the first try.

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 baseline is 3, but the description adds synthesis the schema cannot: `since` as a novelty watermark, `domain` as mandatory for room access, and the interaction between `limit` and the size budget that makes large limits wasteful in rooms. It largely restates the schema's per-parameter caveats rather than adding new semantics, which keeps it below a 5.

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 leads with a specific verb and ordering ('List the NEWEST memories first') and immediately contrasts itself with the sibling capability of semantic search ('what happened lately' vs 'what do I know about X'). An agent can pick between this and memory_read without opening either 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 names concrete use cases (resuming after a break, catching up on a room, reviewing recent saves), states when to pass `since` versus paging with the cursor, and gives an explicit MUST for the alternative store ('to catch up on a shared room you MUST pass its address as `domain`'). When-not guidance is present: unscoped calls never cover rooms.

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 supply readOnly/idempotent/non-destructive, so the bar is lower, yet the description adds real behavioral context: the returned address is the value to pass as `domain` on memory_read and memory_write, and write is refused for read-only memberships. That permission nuance is not derivable from the schema or 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?

Front-loaded and dense with useful content, but the middle clause nesting the `domain` usage for two other tools inside a dash-heavy sentence makes it harder to parse than a two-sentence split would be. Still, essentially every clause 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, return values need no explanation, and rich annotations cover the safety profile. The description fills the remaining gaps: usage scenario, cross-tool handoff via `domain`, and membership-based write refusal. Nothing needed to call it 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?

The tool takes zero parameters (schema coverage 100% trivially), so the baseline is 4. The description's mention of `domain` belongs to sibling tools, not this one, so there is no additional parameter meaning to add here.

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?

Specific verb + resource ('List the shared memory rooms') with scope made explicit: rooms you OWN plus rooms you've JOINED. It is unambiguously distinguishable from siblings memory_create_room and memory_join_room, which the description implicitly contrasts against.

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?

States the triggering scenario ('RE-FIND a room in a new session') with concrete user phrasings, and explicitly says to use this instead of creating or re-joining. Both the when and the not-this alternatives are named.

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 readOnly/idempotent/non-destructive annotations, it discloses that memory persists across sessions and across other AI tools, that results are ranked with an alternative newest-first ordering, that each result carries an id consumed by memory_feedback, and that stale entries are superseded by writing rather than deleting. That is genuine behavioral context an agent cannot get from 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?

Front-loaded with purpose and trigger, then workflow semantics; every sentence carries information. It is on the long side for a search tool, and the cross-tool enumeration (Claude, ChatGPT, Cursor, VS Code) is decorative rather than decision-relevant.

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?

Output schema exists, so return-shape explanation is unnecessary and the description correctly spends its words on when to call, the feedback loop, and correction semantics. The one behavior it omits is that a query without `domain` silently excludes shared rooms, which is a real usage trap, though the schema does cover it.

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% and the schema already documents query, domain, top_k caveats, since/until, diversity and exclude_author, so the baseline applies. The description only restates that order_by: 'recency' produces newest-first ordering, which the schema says too; it adds no parameter meaning the schema lacks.

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 (search) and resource (long-term memory) plus the content classes it covers (preferences, decisions, project setup, people, earlier context). It explicitly distinguishes itself from siblings, naming memory_list_recent for exhaustive listing and memory_write/memory_feedback for the other memory operations.

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 ('applies when an answer may depend on something from an earlier session or another tool') and an explicit exclusion ('not needed for general world knowledge'). It also routes to alternatives for adjacent jobs: memory_feedback to record usefulness, memory_write to correct a stale memory, memory_list_recent for a complete bound.

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/destructiveHint, so the "Read-only — changes nothing" clause is redundant. The genuinely additive fact is that the memory is shared across all AI tools connected to Mnemoverse, which is scope information not available in the structured fields.

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, front-loaded with the returned data, then sharing scope, then usage triggers — a sensible order with no filler. The final "Read-only — changes nothing" clause is redundant against the annotations and could be dropped.

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?

Zero parameters, an output schema (so returns need not be explained), and annotations covering the safety profile mean the description only needs context — which it supplies via the cross-tool sharing scope and usage triggers. Nothing an agent needs to call it 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?

The tool takes zero parameters, so the schema-baseline of 4 applies and there is nothing for the description to compensate for. No parameter semantics are needed or missing.

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?

Specific verb ("Get an overview") plus resource (stored memory), with the exact contents enumerated: total count, learned concept associations, domain list, average quality scores. This makes the aggregate nature clear against siblings like memory_read and memory_list_recent. However, no sibling is named or explicitly contrasted, so it stops short of full differentiation.

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 when-to-use triggers: orienting yourself, confirming the exact domain name before writing, and answering "what do you remember." These are actionable contexts. No when-not condition or named alternative (e.g., memory_list_recent for recency) is provided, so it isn't 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?

Goes well beyond the annotations by disclosing the novelty gate that can refuse near-duplicate writes outside shared rooms, noting that the result reports stored vs refused, specifying that domain matching is byte-exact so a stray space opens a separate permanent store, and listing forbidden content classes. This is exactly the kind of behavior an agent cannot infer from destructiveHint=false or idempotentHint=false.

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 purpose and durability scope, then usage criteria, then constraints, then behavior. Dense but each sentence earns its place, with only mild overlap between the closing sentence and the schema's own description of the content field.

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 three-parameter write tool with an output schema and annotations, the description covers the remaining gaps an agent needs: durability semantics, privacy boundaries, refusal behavior, and content authoring rules. Return structure is correctly left to the output schema while its outcome meaning is still summarized.

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 baseline is 3, and the description adds real meaning on top: content must be a self-contained statement that still makes sense when recalled out of context, which the schema only demonstrates by example. Domain semantics are mostly delegated to the schema, so it lands at 4 rather than 5.

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 (store) and resource (long-term memory) plus scope: persists across sessions and across every connected AI tool. This clearly separates it from siblings like memory_read, memory_list_recent, and memory_create_room, which read or set up rather than persist content.

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 inclusion criteria (stated preference, decision, fact, lesson learned) and exclusion criteria (transient chatter that only matters this turn does not belong here), plus a hard prohibition list. It stops short of naming sibling tools an agent should use instead for retrieval or routing, so it is strong but 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 declare readOnly/idempotent/non-destructive safely, but the description adds non-obvious behavior: values are never returned or displayed, no tool on the server can retrieve them, and only the calling account's secrets are listed. That is meaningful disclosure beyond the structured hints.

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 the core action and result shape, and the example is compact and useful. The value-is-never-returned point is restated twice ('never returned or shown to you' and 'no tool on this server returns it'), a mild redundancy that costs a point.

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 formatting needs no explanation, and the description still covers the one thing an agent most needs to know: what is and isn't in the response. No gaps for a zero-parameter list operation.

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 there is nothing for the description to disambiguate and the baseline of 4 applies. The description appropriately avoids inventing parameter guidance that doesn't exist.

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 (list secrets in the Mnemoverse Vault) plus the exact scope of the result (alias and purpose only). It also distinguishes itself from every sibling by asserting that no tool on this server returns the value, so memory_read can't be confused with it.

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 a clear when-to-use rule ('Use this to check WHICH secrets the user has stored and under what alias') and a concrete trigger example ('do I have a GitHub token saved?'). It does not name an explicit alternative tool or a when-not condition, but the value-retrieval case is already ruled out.

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