Rememb

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

With no annotations, the description carries the full behavioral burden and does well: it discloses irreversibility, absence of recovery, and the confirm=true safety guard. The one gap is scope ambiguity — it says "ALL memory entries" while the schema exposes a `store` parameter, leaving unclear whether a non-global store could be wiped or preserved.

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 short sentences, each doing distinct work: what it does, that it is irreversible, the guard, and the alternative. The destructive warning is front-loaded before any routing guidance.

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 two-parameter destructive tool with no annotations and no output schema, the description covers the critical decision inputs: destructiveness, irreversibility, the required guard, and the alternative. Only the store-scope question is left unresolved, which is a minor but real omission for a bulk-delete 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?

Schema coverage is 100%, so both `store` and `confirm` are already documented, and the description's mention of confirm=true restates the schema. It adds no meaning about the `store` parameter's effect on deletion scope, which is the one place added semantics would have helped.

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 with scope: "Permanently delete ALL memory entries at once." It immediately distinguishes itself from the sibling rememb_delete by naming the bulk-vs-single distinction, so an agent can route correctly 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?

Explicitly names the alternative ("Use rememb_delete to remove a single entry by ID instead") and states the exclusion ("Only use this to fully reset the memory store"). Both the when and the when-not are given in plain language.

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 no annotations, the description carries the full burden. It usefully discloses that metadata (tags, access data) gets merged and that matching is exact-content based, but it doesn't state whether the operation is destructive, whether merged-away entries can be recovered (a rememb_restore sibling exists), or what the result looks like. Partial disclosure for a mutation tool.

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

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

Two tight sentences, zero redundancy, with the core action and its matching scope front-loaded ahead of the cautionary guidance.

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?

No output schema and no annotations, so the description must cover behavior. It covers scope and the review workflow but omits what happens on consolidation (which entry survives, whether duplicates are deleted or archived, reversibility). Adequate but with real gaps for a mutation 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?

Schema description coverage is 100% and both parameters are enums documented in the schema (store, section). The description adds no detail beyond that, which is the expected baseline when the schema does all the work.

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 names a specific verb+resource (consolidate duplicate entries) and specifies exactly what is merged (tags and access data). It is clearly distinct from siblings like rememb_edit or rememb_delete, though it doesn't explicitly contrast itself with 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?

It gives a clear applicability condition — 'exact normalized-content match only' — and an explicit exclusion plus alternative workflow: review near-duplicates with the agent before consolidating. It doesn't name a specific sibling tool to use for the near-duplicate review, but the 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 no annotations provided, the description carries the full burden and does well: it discloses that deletion is soft, that entries are hidden from reads/search by default, and that they remain restorable. It stops short of stating behavior for unknown IDs, partial batch failures, or idempotency of repeat deletes.

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 short sentences, front-loaded with the operation and its two modes, then the soft-delete consequence, then the sibling routing. Every sentence adds information; nothing is redundant.

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-parameter mutation tool with no annotations and no output schema, the description covers the essential semantics: soft vs permanent, visibility impact, and restore path. Edge-case behavior (nonexistent ID, mixed batch results, whether entry_id and entry_ids can be combined) is left 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 entry_id, entry_ids, and store are already documented in the schema. The description only restates the two deletion paths and adds no format, limits, or precedence rules for entry_id vs entry_ids — 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 ('Soft-delete') and resource ('memory entry'), and covers both single (entry_id) and batch (entry_ids[]) modes in the first sentence. It is clearly distinguishable from rememb_restore and rememb_clear, which it names 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?

Explicitly routes the agent: use rememb_restore to undo, use rememb_clear for permanent bulk deletion. That gives both the undo path and the alternative for the destructive-bulk case, leaving little to inference.

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 are absent, so the description must carry the burden; it does declare the operation safe and read-only, which is the key behavioral fact. However, it says nothing about what happens with invalid/unknown versions, whether from_version must be older, or error behavior when entry_id does not exist.

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

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

Two short sentences, front-loaded with the action and return format, plus a safety qualifier. No filler and nothing is buried.

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 names the output format ('unified diff') and safety profile, which is the core an agent needs; with no output schema, 'unified diff' covers the return shape. Still, for a tool with required version parameters and no annotations, edge cases and the version-ordering contract are left unstated.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with all four parameters documented, including enum and defaults, so the baseline is 3. The description adds only the relational constraint that both versions must belong to the same entry; nothing about ordering, store scoping, or valid ranges beyond what the schema already says.

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 (show a unified diff between two revisions of an entry) and names the return format. It implicitly distinguishes itself from rememb_get (full entry) and rememb_versions (version listing), though it never names those siblings 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?

Usage is implied by 'two revisions of the same entry', which suggests fetching a diff after inspecting versions, but there is no explicit when-to-use/when-not-to-use statement or reference to rememb_versions or rememb_get as alternatives.

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

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

No annotations exist, so the description must carry the behavioral load; it discloses the key partial-update contract (omitted fields unchanged), that the operation is non-destructive/not delete-and-recreate, and that batching exists. It does not cover batch atomicity (what happens if one updates[] item fails), store scoping, or what the call returns.

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 short sentences, front-loaded with the operation and the batch capability, then behavior, then sibling routing. No filler and nothing repeated from the schema.

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 6-parameter mutation tool with no annotations and no output schema, the description covers the mutation contract and alternatives well. Gaps remain around return values/confirmation, error behavior, and the entry_id-vs-updates[] selection rule, which an agent would have to infer.

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 entry_id, content, section, tags, store, and updates[]. The description adds only framing (single vs batch, omitted-fields-unchanged), and stays silent on edge cases the schema leaves implicit, such as whether entry_id and updates[] are mutually exclusive or whether one must be supplied.

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 (update) and resource (existing memory entry), plus the two invocation modes (single by ID, batch via updates[]). An agent can distinguish it from rememb_write/rememb_delete/rememb_restore without opening a 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?

Ends with explicit routing: use rememb_write to create, rememb_delete to permanently remove. It doesn't address other plausible overlaps (e.g. rememb_restore for reverting, or when to choose batch over repeated single calls), so it falls short of a full when/when-not mapping.

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 no annotations, the description carries the full burden; it does state 'Safe, read-only', which is the key safety trait. However it omits behavior for a missing/soft-deleted entry and how max_chars truncation affects 'full content', leaving meaningful gaps for a fetch tool.

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 short sentences, front-loaded with purpose, then safety, then usage. Every sentence earns its place with no filler.

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

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

For a single-record getter with fully documented parameters and no output schema, the description covers purpose, safety, and invocation ordering. Only soft-delete/not-found behavior and truncation semantics are left unstated.

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 store, entry_id, max_chars and include_deleted are already documented in the schema. The description adds no further parameter meaning, so the baseline of 3 applies.

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

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

Specific verb+resource: 'Fetch one memory entry by ID with full content'. It distinguishes itself from the search/list siblings by naming rememb_search and rememb_recent as predecessor steps, but does not clarify how it differs from the similarly named rememb_read or rememb_read_page.

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?

'Use after rememb_search or rememb_recent when you already know the entry ID' gives an explicit precondition and names the tools that produce the needed input. There are no explicit when-not cases (e.g., when to prefer rememb_read_page or rememb_read instead).

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?

No annotations are provided, so the description carries the full burden. It correctly declares the operation as 'Safe, read-only operation', but provides no additional behavioral details such as output format or potential side effects. Transparency is adequate but minimal.

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 extremely concise with two sentences, no wasted words. The key action and safety trait are front-loaded.

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

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

Given no parameters and no output schema, the description covers the essential purpose and safety. It could elaborate on what 'bundled rememb skills' are, but it is sufficiently complete for a simple list 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?

There are no parameters, so the baseline is 4. The description does not add parameter semantics, but none are needed.

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

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

The description clearly states the action 'List bundled rememb skills' and specifies the source 'from the installed package contents'. It distinguishes itself from sibling tools like rememb_delete or rememb_write which are mutations.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

The description implies usage by stating it's a safe, read-only list operation, but does not explicitly state when to use it over alternatives like rememb_use_skill. However, given its unique purpose among siblings, it is clear enough.

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 no annotations provided, the description carries the full behavioral burden. It explicitly states that the operation is 'Safe, read-only' and describes which stores are included, though it does not detail return format, auth requirements, or edge cases.

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

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

The description is a single, front-loaded sentence that states the action, scope, and safety profile without redundant wording. Every clause contributes useful information.

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

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

For a zero-parameter, read-only listing tool with no output schema, the description provides enough context to invoke it correctly: it identifies the resource, the process-scoped set of stores, and the safety property. Nothing critical is missing for this level of complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so parameter semantics are inherently simple and the baseline is 4. The description adds no parameter-level detail, which is appropriate because there are no parameters to explain.

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

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

The description uses a specific verb ('List') with a specific resource ('configured memory stores'), and it clarifies the scope as global plus project stores. This is sufficiently distinct from sibling tools such as rememb_get, rememb_search, and rememb_stats.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

The description implies usage by explaining what stores are listed and how project stores are supplied via --project, but it does not explicitly say when to use this tool versus alternatives like rememb_stats or rememb_versions. No exclusions or selection guidance are provided.

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 no annotations, the description carries the full burden and does cover the critical safety profile ('Safe, read-only') plus the fact that counts are returned. However, it omits ordering, pagination behavior beyond the limit param, and how include_deleted affects the counts — meaningful gaps for an unannotated tool.

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

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

Two short sentences with zero waste; the purpose and the 'read-only' assurance come before the routing advice. Nothing is padded.

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-required-parameter discovery tool this is close to sufficient: it says what is listed, that counts come back, that it is safe, and where it fits in the search flow. Only the shape of the returned tag objects is left implicit, which is a minor gap with no output schema available.

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%, including the store enum and the include_deleted semantics, so the baseline is 3. The description adds only the loose phrase 'in the store' and no syntax or format detail beyond the schema.

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

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

States a specific verb and resource ('List tags used in the store') and even characterizes the return content ('with usage counts'), which distinguishes it from siblings like rememb_list_stores and rememb_list_skills. An agent knows exactly what this returns 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?

Explicitly names the workflow position and the alternatives it feeds ('Use to discover filters before rememb_search or rememb_read_page'). It lacks an explicit when-not-to-use clause, but the use case is unambiguous for this store.

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?

No annotations are provided, so the description carries the full burden, and it does well: it declares read-only/side-effect-free behavior and states it returns full entry content. It omits pagination behavior and how include_deleted interacts with results, keeping it short of a 5.

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 short sentences with the core purpose front-loaded and no filler. Minor overlap between the opening verb phrase and the tool name, but nothing wasted.

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 no output schema and full schema coverage, the remaining burden is behavioral: safety and return shape are covered, and the large-read guidance is a useful extra. Only pagination/large-result handling and deleted-entry semantics are left implicit.

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 in the schema, including the section enum and the max_chars cap. The description only restates section filtering and adds no extra semantics such as max_chars interaction with truncation or store selection beyond 'global'.

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 ('Read') and resource ('memory entries') plus the primary scoping mechanism ('filter by section'). An agent can infer it is the collection-level reader rather than the single-item rememb_get, though no sibling is named 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?

Implies usage ('read all ... or filter by section') but gives no explicit when-to-use/when-not guidance versus rememb_get, rememb_search, or rememb_recent, which are the natural alternatives for this tool. The closing advice about summarizing after large reads is the only contextual 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?

With no annotations, the description carries the full burden; it does disclose that full entry content is returned and gives a useful working-context hint about summarizing per page. It is silent on ordering semantics, soft-deleted entries (include_deleted), and the max_chars truncation behavior, which matter for an agent interpreting results.

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

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

Two tight sentences, front-loaded with the core action and followed by the return/context-handling note. No filler, though the second clause is advisory rather than definitional.

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?

No output schema and no annotations, with 9 parameters, so the description should carry more weight than it does. It covers the return shape at a high level but leaves sort order, deletion inclusion, and multi-store behavior to the schema alone.

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 every parameter including store, sort_by, max_chars, and include_deleted is already documented. The description only echoes section/tag filtering and pagination, adding no syntax or precedence detail 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 ('Read a paginated slice of entries') plus the two filtering axes, so the agent knows exactly what the call yields. It does not differentiate itself from close siblings such as rememb_read, rememb_recent, or rememb_search, leaving the boundary ambiguous.

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?

Pagination and filtering imply the usage (walk a large entry set page by page), but the description never says when to prefer this over rememb_read, rememb_recent, or rememb_search, nor any preconditions. Guidance is inferable rather than stated.

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 no annotations provided, the description does carry the safety burden by declaring 'Safe, read-only', and it discloses the newest-first ordering. However, it says nothing about whether soft-deleted entries are excluded by default, how max_chars truncation behaves, or how results are paginated, leaving real behavioral gaps for a zero-annotation tool.

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 short sentences with the core behavior front-loaded and zero padding. Safety and usage each get one clause, so every sentence 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?

For a zero-required-param read tool with no output schema, the description covers purpose, safety, ordering, and a use case adequately. Minor gaps remain around deleted-entry defaults and truncation semantics, but nothing blocks a correct call.

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 (limit, store, section, max_chars, include_deleted) are already documented in the schema. The description adds only the ordering claim, not parameter meaning, 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+resource ('Return recently updated entries') plus the sort order ('newest first'), which cleanly separates it from rememb_read, rememb_search, and rememb_list_tags. It does not explicitly name any sibling, so the differentiation is inferential rather than stated.

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?

'Useful for catching up on what changed since the last session' implies a scenario, but there is no explicit when-not guidance and no routing to alternatives such as rememb_search for keyword lookup or rememb_read for a known entry. Usage is implied, not prescribed.

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 no annotations at all, the description carries the full burden, and it delivers the single most important behavioral fact: restores are non-destructive because they append a new head revision rather than rewriting history. It stops short of error conditions, permission requirements, or what happens when version points at a non-existent revision.

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

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

Two sentences, no filler. The core action and its two modes come first, and the non-destructive guarantee follows immediately — exactly the front-loading an agent needs.

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-parameter mutation tool with no annotations and no output schema, the description covers purpose, both modes, and the key safety property. It leaves gaps around failure behavior and what a restore returns, but nothing an agent needs to invoke 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 description coverage is 100%, and the schema already explains entry_id, store, and the optional version parameter, so the description need not duplicate it. The description restates the dual version behavior, which reinforces but adds no syntax or format detail 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?

The description names a specific verb and resource ('Restore a soft-deleted entry') and adds a second distinct mode ('restore a specific prior version as the new current head'), so an agent knows exactly what the tool does. It doesn't explicitly name a sibling such as rememb_versions or rememb_edit as the alternative for a non-restore path, which keeps it just short of a 5.

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?

Usage is implied rather than stated: restoring deleted entries or rolling back to a prior version. There is no explicit 'use this instead of rememb_edit when…' guidance, and no mention of what to do if the entry is not soft-deleted or the version does not exist.

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?

No annotations are provided, so the description carries the burden and does so partly: it declares 'Safe, read-only' and enumerates the returned fields (id, score, tags, date, excerpt). It does not mention result ordering, soft-deleted entry behavior, or the top_k default, leaving some behavioral detail to the schema.

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 short sentences, front-loaded with purpose and safety, then the return contract, then the alternative. Nothing wasted.

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 no output schema, the description usefully enumerates return fields, and it compensates for missing annotations by declaring read-only safety. Still silent on result ordering and pagination, which matters for a search tool with a top_k parameter.

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 every parameter is already documented in the schema; the description only glancingly implies excerpt sizing ('short excerpt'). No syntax, tokenization, or multi-word query semantics are added beyond the schema.

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

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

States a specific verb and resource ('Keyword and token search over memory entries') and distinguishes itself from the sibling rememb_get by noting the latter returns full bodies. An agent can pick this tool apart from rememb_recent or rememb_list_tags 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?

Explicitly routes to rememb_get when the full body is needed, which is a real alternative. However it gives no guidance on when to prefer rememb_recent, rememb_list_tags, or section vs tag filtering, so coverage is partial.

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?

No annotations exist, so the description carries the full behavioral burden; it does declare 'safe, read-only operation with no side effects' and enumerates the return fields, which is meaningful disclosure. It omits cost/performance, whether the store must already exist, and any pagination or truncation behavior for large stores.

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

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

Two sentences, front-loaded with the concrete metrics and followed by purpose. Minor redundancy between 'safe, read-only' and 'no side effects', but nothing wasteful or padded.

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-required-parameter stats tool with no output schema, the description names exactly which statistics come back and when to reach for it. Nothing an agent needs in order to call this 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?

Only one optional parameter and schema coverage is 100%, with the schema fully explaining 'global' vs project store ids. The description adds nothing about the store parameter (e.g. whether stats are scoped strictly to that store), 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?

Specific verb (return) plus resource (memory usage statistics) with the returned metrics enumerated: totals, size in KB, oldest/newest dates, per-section counts. That distinguishes it from list/read siblings such as rememb_list_stores or rememb_recent, though no sibling is named 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 two concrete use cases: overview of the user's memory store and deciding whether cleanup is needed. It does not state when not to use it or name an alternative (e.g. rememb_list_stores for enumerating stores or rememb_clear for cleanup), so routing is clear but not exhaustive.

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?

Explicitly declares 'Safe, read-only operation' in the absence of annotations, disclosing its non-destructive nature. Adds that it returns instructions, providing clear behavioral context.

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

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

Two sentences, no fluff. First sentence states purpose and behavior, second gives usage guidance. Every word adds value.

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 simple tool with one parameter and no output schema, the description is sufficiently complete. It could mention the return format of instructions, but not required.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. The description adds no new information beyond what the schema already provides (skill identifier or exact name).

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 the specific action 'load' on a 'bundled rememb skill' and distinguishes between identifier and exact name. It clearly differentiates from sibling tools like rememb_list_skills, which inspects skills.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

Provides explicit guidance to use 'rememb_list_skills first to inspect available skills', indicating when this tool should be used. Missing explicit exclusions but sufficient for the task.

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 no annotations provided, the description carries the behavioral burden and does disclose that the operation is safe and read-only. It also indicates that deleted revisions can be included, but it omits permissions, pagination, ordering, and response-shape details.

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

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

Two sentences, front-loaded with the core action and followed by the read-only safety note. There is no redundant or wasted text.

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 simple read-only history-listing tool with fully described parameters, the description covers what is returned conceptually: revisions, snapshots, and optionally deleted states. It could be more complete about ordering or pagination, but no output schema exists to carry that burden.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents entry_id, store, and include_deleted clearly. The description reinforces the deleted-state behavior but adds little parameter meaning beyond the schema.

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

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

The description states a specific verb and resource: list revisions for a given entry, including prior content snapshots and deleted states. It is clear enough to distinguish it from current-entry reads such as rememb_get, though it does not explicitly name alternatives like rememb_diff or rememb_restore.

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 does not explain when to choose this tool over siblings such as rememb_get, rememb_diff, or rememb_restore. The phrase 'when requested' describes the include_deleted parameter rather than offering tool-selection 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?

With no annotations, the description carries the full behavioral burden, and it does disclose one genuinely non-obvious trait: existing entries are never overwritten (append-only, no upsert). It says nothing about what a successful write returns (e.g. IDs needed for a later rememb_edit), whether writes are deduplicated, or any persistence/confirmation behavior.

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 short sentences, front-loaded with what it does, then the non-overwrite guarantee, then the alternative. Nothing is redundant or padded.

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 5-parameter mutation tool with zero annotation coverage and no output schema, the description is minimally sufficient but leaves real gaps: no return-value indication, no guidance on the content-vs-entries choice, and no explanation of how 'store' or 'section' defaults should be chosen despite the schema requiring nothing.

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, and the description adds only a thin gloss on the batch shape via 'or multiple entries in one call'. It does not address the more consequential ambiguity the schema leaves open: both 'content' and 'entries' are optional with no stated mutual exclusivity or precedence.

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 ('Save') plus resource ('memory entry') and explicitly covers both the single and batch form. It also names the sibling it is not (rememb_edit), so an agent can distinguish it from the update path without opening a 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 routing rule: use rememb_edit to update an existing entry by ID, which is exactly the decision this tool's callers face. It does not cover the other plausible boundary cases, such as when to send a batch via 'entries' versus repeated single calls, or when rememb_consolidate is the right tool instead.

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