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

Annotations only say it is a non-destructive, non-readonly create; the description adds substantive behavior an agent could not infer: write access depends on membership scope (read_write), members see history saved before they joined, and joining does not leak private account memory. It also discloses that the result is a room address used as a `domain` handle elsewhere.

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 sharing/permission model is front-loaded and the operational follow-through (invite, domain, list) comes after. It is slightly dense and has one overlapping clause ("across the AI tools members connect to Mnemoverse") that could be trimmed without loss.

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?

Only two simple parameters, full schema coverage, an output schema that covers return values, and annotations covering the safety profile. The description still adds the sharing model, membership scope, privacy boundary, and downstream handle usage — the decision-relevant context is 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?

Schema coverage is 100% and both parameters are documented in-schema, so the baseline is 3. The description goes beyond that by explaining the semantic role of the returned address (`domain` on memory_write/memory_read), which is the non-obvious part of using this tool's output as input elsewhere; it adds nothing about the optional `description` parameter.

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 verb+resource ("Create a SHARED memory room") and immediately contrasts it with private memory ("OTHER people's assistants can read", "joining does not expose their private account memory"). This makes it distinguishable from siblings like memory_join_room and memory_list_rooms without opening their schemas.

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 states the triggering condition explicitly ("Use when the user wants to share context or collaborate with someone else") with a concrete example utterance. It also points to the follow-on tools: memory_invite_to_room for membership and memory_write/memory_read/memory_list_recent for using the returned 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?

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?

Goes well beyond readOnlyHint/idempotentHint by describing ranking behavior, the id-bearing result shape, the feedback loop, that corrections are additive and never delete or hide the prior memory, that near-duplicate writes are refused, and that no deletion tool exists. These are exactly the non-obvious traits an agent needs before calling.

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 usage come first, with behavioral caveats after — good front-loading and no filler sentences. It runs five dense sentences and the deletion/REST-API detail is adjacent rather than essential to invoking this tool, keeping it just short of a 5.

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 annotations, a full output schema and 100% schema coverage, the description only needs to supply routing and behavioral context — which it does, including the cross-session persistence model and the write/delete lifecycle that no structured field expresses.

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 per-parameter descriptions are unusually detailed (including caveats on top_k and exclude_author), so the schema already carries the load. The prose adds only the order_by relevance/recency contrast, which is a restatement. 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?

A precise verb+resource ("Search long-term memory") plus an enumerated scope (preferences, past decisions, project setup, people, earlier context). It is distinguishable from memory_list_recent, memory_graph and memory_list_rooms via explicit cross-references later in the text.

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 trigger condition ("when an answer may depend on something from an earlier session or another tool") and the exclusion ("not needed for general world knowledge"). It also routes away to siblings: memory_list_recent for exactly-bounded listings, memory_list_rooms for room addresses, memory_feedback afterwards, memory_write for corrections.

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?

Annotations already declare this is a mutating, non-idempotent, non-destructive write. The description adds substantial behavioral context beyond that: the novelty gate outside shared rooms, the possibility of refusal, and the fact that the result reports whether the memory was stored or refused. This is exactly the kind of condition 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?

The description is front-loaded with the core purpose and then layers in usage, safety exclusions, and novelty-gate behavior in a logical order. It is somewhat dense, but every sentence carries real information and none is filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given that an output schema exists and annotations cover the safety profile, the description supplies what structured fields cannot: persistence semantics, acceptable content categories, prohibited data, and the novelty-gate refusal behavior. An agent has enough to decide whether and how 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 schema already documents `domain`, `content`, and `concepts` thoroughly, including byte-for-byte domain matching and room addresses. The description reinforces the self-contained-content requirement but largely restates what the schema already says, so it sits at the 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?

The description states a specific verb and resource ('Store a long-term memory') and scopes it precisely: persistence across sessions and across every connected AI tool. It is clearly distinguishable from sibling tools like memory_read or memory_list_recent, which retrieve rather than store.

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 explicitly names when to use the tool ('durable information: a stated preference, a decision, a fact about people, roles or project setup, a lesson learned') and when not to ('transient chatter that only matters this turn does not belong here'). The prohibition list for sensitive data adds a hard exclusion boundary that leaves little room for misuse.

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.