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

No annotations are provided, so the description carries the full behavioral burden. It does not disclose whether entries persist, are deduplicated, are indexed for recall, require a pre-existing library, or what happens on conflict — all relevant for a memory write 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?

The phrase is a single front-loaded clause with zero waste, which is good structurally. But it is so terse that it tips into under-specification rather than efficient conciseness.

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 annotations, no output schema, and two required parameters whose relationship (library + content) is unstated, the description is too thin for a write tool in a large sibling set. An agent needs at least the library prerequisite and the intended scope of "memory entry" 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 library, content, and source, making 3 the baseline. The description adds no extra meaning, such as format or constraints on the required library or content fields.

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 verb and resource ("Add a memory entry"), which is enough to know it creates a memory. However, it gives no differentiation from the many sibling write tools such as mind_fact_add, mind_create, mind_vault_store, mind_learn, or mind_ingest, so an agent cannot tell which add-path this is.

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?

There is no when-to-use guidance, no mention of prerequisites, and no named alternative among the crowded add/store siblings. The agent is left to guess whether this is the right insertion tool.

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

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

With no annotations, the description carries the burden and does well: it discloses the injection behavior, per-action semantics (set overwrites, get/list read, remove deletes), and hard resource limits (4KB/block, 32 blocks). It does not state what happens on overwrite of a missing block or whether remove is recoverable, which is the remaining gap 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?

Front-loads what the tool is and the ALWAYS-injected constraint, then actions, then limits, then the sibling alternative. Dense but every clause adds an operational fact; only the parenthetical example list is mildly expendable.

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 no annotations and no output schema, the description covers purpose, action semantics, capacity limits, and alternatives. Only edge-case behavior (overwrite of a nonexistent block, reversibility of remove) remains undocumented.

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 a documented enum, so the baseline is 3, but the description adds semantics the schema lacks — that 'set' overwrites existing content and that 'list' needs no name — plus the storage cap that bounds what content may be passed.

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?

Names the specific resource (pinned core-memory blocks: persona/user/current-project) and its defining behavior (ALWAYS injected at top of session context, not ranked retrieval). This distinguishes it clearly from retrieval siblings like mind_search and mind_recall.

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

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

Explicit when-to-use ('stable, always-relevant facts the agent must not have to search for') paired with an explicit when-not and named alternative ('put searchable knowledge in mind_add instead'). No inference required to route between the two tools.

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

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

No annotations are provided, so the description carries the full burden. It does disclose useful behavior: newest-first ordering, no relevance ranking, and that metadata filters rather than query matching drive results. However, it says nothing about pagination behavior, whether 'limit' is the only paging mechanism, authentication/permission requirements, or what the response contains.

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, all front-loaded with the most discriminating information (no query, inventory not ranking) first. No filler, no restatement of the tool name.

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 read-oriented browse tool with full param coverage, the description covers scope, ordering, and filter semantics. The remaining gap is return shape/paging, which matters since there is no output schema, but it is minor for an inventory 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%, so every parameter is documented in the schema itself, including the archived enum semantics and inclusive/exclusive date bounds. The description adds only 'Same filters as mind_search', which cross-references rather than elaborating. Baseline 3 is correct.

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 ('Browse/list memories by metadata') and immediately distinguishes the operation from its nearest sibling: 'WITHOUT a search query: inventory, not ranking'. The contrast with mind_search (named explicitly) lets an agent pick this tool 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?

Gives three concrete trigger questions ('what did agent X write recently', 'everything from this source', 'all memories since a date') plus the discriminating condition (inventory vs ranking) and points to mind_search for shared filter semantics. This goes beyond implied usage to explicit when-to-use.

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 the critical trait: the tool is always dry-run on the MCP surface and will never mutate memory. It does not discuss cost on large libraries or how scope affects the counts, so it stops just short of full coverage.

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 tight sentences, front-loaded with what is counted, then the safety/dry-run guarantee, then the invocation trigger. No redundancy and every sentence carries 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?

No output schema exists, and the description partially compensates by naming the three count categories returned. For a single optional-parameter read tool this is nearly sufficient; only the exact shape/threshold definition of 'cold' is left unspecified.

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 is one optional parameter with 100% schema description coverage ('Scope to one library (omit for all)'), so the schema already carries the semantics. The description adds no further meaning about argument form or default scoping, matching the baseline for high-coverage single-parameter tools.

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?

Names a specific verb (preview) and enumerates exactly what is measured: counts of exact duplicates, near-duplicates, and cold (old + unused) entries. It also positions itself against the CLI `mgimind consolidate` path, so an agent can tell this apart from a destructive consolidation tool without opening the schema.

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

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

Gives explicit trigger conditions ('Use this when the user asks how much duplicate memory do I have?') and a sequencing cue ('before suggesting they run the CLI command'), plus an explicit exclusion – destructive consolidation lives on the CLI with `--apply`. Nothing about when to reach for this vs. alternatives is left 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?

No annotations are provided, so the description carries the full behavioral burden and it is essentially silent. It does not say whether the call is read-only, what the briefing contains or how large it is, whether it writes anything, or what happens if no prior session data exists.

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

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

A single short sentence with no filler, and the trigger ('session start') is front-loaded alongside the action. It is efficient, though its brevity comes at the cost of content rather than being a virtue of trimming redundancy.

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

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

With no output schema and no annotations, the description is the only source of information, and it leaves the return value completely undefined. An agent cannot tell what 'compact context briefing' actually delivers or how it differs from mind_session_start before committing to the 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?

The tool takes zero parameters, which is the baseline-4 case: there are no parameter semantics to explain and nothing in the schema or description needs reconciling.

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 ('Generate') and a specific resource ('compact context briefing for session start'), which is more than a restatement of the name. However, it does not distinguish itself from closely related siblings such as mind_session_start, mind_recall, or mind_stats, leaving the agent to guess which one produces session context.

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 phrase 'for session start' implies the trigger condition, so usage is inferable at a high level. There is no explicit when-to-use guidance, no when-not-to-use, and no pointer to alternatives among the many sibling tools that could also supply session context.

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, and it discloses the most important trait an agent needs: this tool is deprecated and removed in v2.0. That is genuine lifecycle/safety context beyond the schema. It does not say whether calling it now errors or still creates a library, which is the one remaining behavioral gap.

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

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

A single compact sentence-set with the deprecation warning front-loaded, the replacement named, and the removal version given. Nothing is wasted and the most decision-relevant information comes first.

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 one-parameter, never-to-be-called tombstone tool, the agent needs only to know not to use it and what to use instead, both of which are supplied. There is no output schema and no annotations, and the description is sufficient for correct selection behavior.

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 0% for the single required 'name' parameter. The description implies the parameter is the library name via 'Create a new library', which is minimal compensation, but adds no format, uniqueness, or naming constraints. With only one parameter this is adequate but thin.

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 both the operation ('Create a new library') and its lifecycle status ('DEPRECATED ... Removed in v2.0'), and points at the sibling mind_library as the replacement. An agent can immediately tell what this tool did and that it should not be selected. It stops short of a 5 because the actionable purpose is really 'do not call this', with the original function only parenthetically noted.

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

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

It gives explicit routing guidance: use mind_library(action="create") instead, and names the version in which this tool disappears. This is clear when-not-to-use instruction, though it does not say whether the tool still functions in the current version (i.e., whether it is a hard failure or a soft warning).

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, but it does add real behavioral context: the tool is deprecated and removed in v2.0, so calls may fail or be unavailable. It does not disclose whether the deletion is permanent or recoverable (a mind_restore sibling exists) or what permissions are needed.

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?

A single tight sentence with the migration directive front-loaded and the tool's function following. Every clause earns its place; 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 deprecated two-parameter tool with fully documented schema and no output schema, the description covers what the agent needs: the replacement path and removal status. It is slightly ambiguous about whether the tool still functions in the current version.

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% for both parameters (id as Memory UUID, library as Library name). The description only echoes the 'by ID' notion and adds no format or sourcing detail beyond the schema, so the baseline 3 applies.

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

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

The parenthetical states a specific verb and resource: 'Delete a specific memory by ID'. It also routes the agent away from itself via the mind_library(action="delete") pointer, so an agent can distinguish it from siblings. The purpose is relegated to parentheses behind the deprecation banner, which slightly weakens front-loading.

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 replacement (mind_library(action="delete")) and the condition that makes this tool unusable ('Removed in v2.0'). The agent is told both what to use instead and why, leaving nothing 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?

With no annotations, the description carries the full behavioral burden, and it does not meet it. 'Check' implies a read-only inspection, yet the schema exposes a 'fix' flag that presumably mutates or repairs state; the description never discloses that this tool can change data, nor what would be changed or whether it is reversible.

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 words with no waste and the verb is front-loaded, so it is structurally fine. The problem is under-specification rather than verbosity — it is concise to the point of being uninformative.

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 tool with no annotations, no output schema, and an undocumented mutating parameter, the description should explain what is checked, what the result means, and what fix does. None of that is present, so an agent cannot invoke it confidently.

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 0% and the description says nothing about the single 'fix' parameter, whose boolean semantics are the most consequential part of the call. The description adds zero meaning beyond the schema, and the schema itself explains nothing, leaving a mutation switch entirely undocumented.

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 gives a verb ('Check') and a resource ('system health'), so the intent is broadly readable, but 'system' is undefined and it does not differentiate itself from siblings like mind_stats or mind_quarantine_list, which also inspect state. An agent cannot tell from the text what is actually being diagnosed.

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?

There is no when-to-use guidance, no mention of when to run this versus mind_stats, and no statement of prerequisites or cost. The existence of a repair mode is never hinted at, so the agent has no basis for choosing between a diagnostic and a corrective call.

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 disclosure burden. It conveys that files are written and which formats are available, but says nothing about overwriting existing files, what 'all data' includes (secrets, vault contents?), permissions needed, or whether the default directory is created. For a filesystem-writing operation this is a significant gap.

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

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

A single short sentence with the verb and the format/destination constraint front-loaded. 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 two-parameter export tool with no annotations and no output schema, the description is minimally viable: it names the artifact types but leaves the write behavior, scope boundaries, and failure modes unexplained.

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 fields already document their accepted values and defaults. The description restates the format options and adds nothing about the output directory or path semantics, so 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 ('Export') and resource ('all data') plus the output artifacts (JSON or Markdown files). An agent can tell this apart from mind_import by direction, though the description never names that sibling or any other.

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?

No when-to-use or when-not guidance. Nothing distinguishes this from mind_vault_store, mind_import, or mind_consolidate, all of which move data in or out of the store, so the agent must infer backup/portability intent on its own.

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 it does add real context: invalidate is a soft-delete, not a hard delete, and is scoped to superseded single-valued facts. However it is silent on side effects of add (whether inserting a single-valued fact supersedes prior ones), permissions, and error behavior, leaving material mutation semantics undisclosed.

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?

A single dense sentence that front-loads the data model, then enumerates the actions with tight parentheticals, and closes with the consolidation note. No filler sentences; every clause carries 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 7-parameter multiplexed tool with no output schema, the description covers the data model, all three action modes, and the soft-delete nature of invalidate, which is what an agent needs to select a mode. It stops short of describing what each action returns or any limits on query results, which would round out the picture.

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 slightly exceeds it by giving the semantics of the `action` enum values rather than just labeling the field. The deeper parameter meaning (as_of time-travel, history supersession chain) lives in the schema, so no additional credit is warranted there.

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

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

States the resource concretely ('Knowledge-graph facts (subject -> predicate -> object)') and decomposes the multiplexed tool into its three actions with a verb each (add/insert, query/list, invalidate/soft-delete). It also names the three legacy tools it replaces, so an agent can map intent to this tool 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?

Each action carries a when-to-use cue: add for inserts, query for 'list facts about a subject', and invalidate specifically 'when a single-valued fact has been superseded'. That is solid routing guidance, but there is no explicit when-not guidance or comparison against the non-fact siblings (mind_recall, mind_search) that may also surface facts.

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, so the description carries the full burden. It does disclose valuable lifecycle context (deprecated, removed in v2.0), but it never says whether calls still succeed, error, or no-op before removal — the key behavioral question for a deprecated endpoint. Additional context beyond the deprecation notice is absent.

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?

A single front-loaded sentence with zero waste: deprecation, replacement, and removal timeline come first, with the actual function noted briefly at the end.

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 deprecated stub with no output schema, the description gives the agent everything actionable: don't call it, call mind_fact instead. The only shortfall is not stating the runtime behavior of the deprecated call itself.

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?

Three required parameters (subject, predicate, object) with 0% schema description coverage and no enum or format hints. The description adds no meaning about what values these should take or how they relate to the knowledge graph, so it fails to compensate for the coverage gap.

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 parenthetical states a specific verb+resource (add a knowledge graph fact), so the tool's function is identifiable despite the deprecation banner dominating the string. It also implicitly distinguishes itself from siblings by naming mind_fact as the replacement.

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 tells the agent not to use this tool and gives the exact alternative call (mind_fact(action="add")), plus the removal version. There is no ambiguity about when (never) or what to use 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 behavioral burden. It usefully discloses that this is a 'soft-delete' (vs. hard delete) and its intended semantic purpose (superseding a changed single-valued fact), which adds real context beyond the name. However, it omits permissions, reversibility details, and side-effect scope for the mutation.

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 efficient: deprecation and replacement come first, purpose follows. Slightly redundant with the nested parentheses around the purpose clause, but no wasted sentences.

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 deprecated single-param tool with no output schema, the essential information an agent needs — that it is deprecated and what to call instead — is fully present. Only minor behavioral detail (permissions, reversibility) is absent.

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

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

Schema description coverage is 100% and the sole 'id' parameter is documented in the schema ('Fact ID from mind_fact_query'). The description adds no syntax or format detail beyond that, so the baseline 3 applies when the schema does the heavy lifting.

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

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

The description states a specific verb+resource ('Soft-delete a fact by ID') and immediately front-loads a deprecation notice pointing to the replacement sibling 'mind_fact(action="invalidate")'. An agent can distinguish this from mind_fact, mind_fact_add and mind_fact_query without opening any schema.

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

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

Explicit routing guidance: it names the exact replacement call and states this tool is 'Removed in v2.0'. The when-not-to-use condition and the concrete alternative are both spelled out, leaving nothing 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?

With no annotations, the description carries the full burden, and it does disclose the dominant behavioral fact: the tool is deprecated and removed in v2.0, so calls may fail. It does not describe return behavior or error semantics, but for a deprecated stub the critical trait is surfaced.

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 the deprecation warning and replacement call front-loaded before the purpose gloss. Nothing is 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?

For a one-parameter, annotation-free deprecated stub with no output schema, the description supplies what an agent actually needs: do not call this, call mind_fact(action="query") instead. Only the subject parameter's expected shape 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 0% and the single 'subject' parameter has no schema description. The description only restates 'a subject' without adding format, validation, or example semantics, so it does not compensate for the coverage gap.

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 parenthetical '(Query facts about a subject)' states a specific verb+resource, and the deprecation notice names the sibling (mind_fact) that supersedes it. An agent can tell what this tool would do and that it is superseded 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?

It explicitly gives the when-not (DEPRECATED, removed in v2.0) and the alternative with the exact call form: mind_fact(action="query"). This is the strongest possible routing guidance, leaving nothing 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?

With no annotations, the description carries the full behavioral burden, and it discloses only the sort order. It says nothing about the scope of 'additions', the default cap (schema shows default 10 but that is not in the text), the return shape, or any pagination/permission 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?

At four words it is front-loaded and waste-free, but it is terse to the point of under-specification rather than genuinely efficient. There is no filler, yet the single sentence also carries no useful detail.

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 listing tool this is thin: with no output schema and no annotations, the description should clarify what is listed, in what direction, and how many by default. None of that is present, leaving the agent unsure what 'additions' refers to.

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 0% for the single 'limit' parameter, which has a default of 10 but no documentation anywhere. The description never mentions limiting or result counts, so it fails to compensate for the coverage gap.

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 phrase 'Show recent additions chronologically' names a verb (show) and a resource (recent additions) with an ordering qualifier, so the basic action is inferable. However, 'additions' is undefined (additions to what collection?), and it does not distinguish itself from plausible siblings like mind_list, mind_browse, or mind_recall_all, which likely also enumerate stored items.

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?

There is no guidance on when to use this tool versus the many listing/recall siblings, no prerequisites, and no exclusions. The agent is left to infer that 'recent additions' means a recent-items listing, which is only weakly 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?

No annotations are provided, so the description carries the full burden. It says nothing about what importing does to existing data (overwrite, dedupe, append), what permissions or vault access are required, whether the operation is idempotent, or what happens on partial failure — all material for a write operation into a knowledge base.

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?

A single short sentence with the core action front-loaded and no filler. It is efficient, though its brevity is partly under-specification rather than disciplined concision.

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

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

For a write-style import tool with no annotations, no output schema, and a knowledge-base target, the description omits result behavior, conflict handling, and target-library semantics. The schema covers inputs but nothing compensates for the missing behavioral context.

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 path, source, and library are already documented in the schema with defaults. The description adds nothing about parameter semantics beyond the schema (e.g., accepted source values or how the target library is created). Baseline 3 applies when the schema does 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 states a specific verb and resource: importing markdown files from a directory, with examples of the source ecosystem (Obsidian). An agent can tell this is a bulk file-ingestion tool rather than a query or mutation of individual items. It does not, however, distinguish itself from near-siblings like mind_ingest, mind_learn, or mind_vault_store, which likely also bring external content into the 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?

No guidance on when to use this versus mind_ingest, mind_learn, or mind_vault_store, and no stated preconditions (directory must exist, files must be markdown, whether re-imports are safe). The only contextual hint is the Obsidian parenthetical, which is an example source, not a usage rule.

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 usefully discloses that each candidate is secret-scrubbed and near-dup-checked before writing, implying a write operation and some safety processing. However, it omits permissions, idempotency, reversibility, and what a successful write returns, leaving significant behavioral gaps.

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 tight sentences with no filler, front-loading the primary use case before the fallback and safety note. Every sentence carries unique 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 three-parameter tool with no output schema and no annotations, the description covers the main mode-selection and safety behavior well. It is still silent on return values and what happens if both raw and candidates are omitted, leaving minor gaps for an agent trying to interpret results.

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. The description adds priority semantics ('PRIMARY' candidates, 'BACKSTOP' raw) that are not in the schema, helping an agent decide which parameter to populate first. The library parameter's detailed usage guidance lives entirely in the schema, not the description.

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 (ingest) and resource (memory), and distinguishes two operating modes (PRIMARY/BACKSTOP). However, it does not differentiate from sibling tools like mind_add or mind_learn that also write memory, so an agent must infer which to pick.

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 tells when to use candidates vs raw ('PRIMARY: pass candidates... BACKSTOP: omit candidates...'), giving clear context for parameter selection. It stops short of naming alternative sibling tools or when not to use this tool at all.

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 meaningful work: it discloses that records are stored unverified by default, surfaced with low weight until confirmed, and explains the truth-signal semantics. It omits return shape, dedup/merge behavior, and permission needs, 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 dense sentences, front-loaded with the purpose before the storage/semantics details. Every sentence earns its place. Slightly terse around the usage condition but nothing is 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?

For a five-parameter mutation tool with no annotations and no output schema, the description covers the highest-value behavior (default unverified state, low recall weight, verified gating). It stops short of describing what the call returns or how repeated lessons interact, leaving minor gaps.

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

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

Schema coverage is 100%, so the input schema already documents all five parameters, making 3 the baseline. The description adds slight value by elaborating the verified condition ('test green / exit 0') beyond the schema wording, but does not clarify error normalization or context semantics further.

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: 'Record a procedural-memory lesson (error -> fix)'. The error->fix framing gives a concrete shape of what gets stored. It does not explicitly differentiate from sibling write tools like mind_add, mind_skill, or mind_procedure_outcome, so it falls 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?

Provides conditional guidance for the verified flag ('Pass verified=true ONLY with a deterministic signal'), which is real usage instruction. However, it never says when to prefer mind_learn over related siblings (mind_skill, mind_procedure_outcome, mind_add) or when not to use it, so usage is largely 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?

No annotations are provided, so the description carries the full behavioral burden. It usefully flags delete as destructive, but says nothing about permissions, reversibility, or what 'counts' in list represents, leaving mutation semantics thin for a tool with zero annotation coverage.

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 resource name, then a compact per-action breakdown that reads cleanly. Dense but no sentence is wasted; slightly telegram-style but appropriate for a dispatcher.

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-action dispatcher with full schema coverage and no output schema, the description covers what each action does and its relationship to siblings. Only the destructive/permission nuance for delete is under-explained.

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%, with id/name/library each documenting which action requires them, so the schema does the heavy lifting. The description adds only high-level action-to-parameter flavor beyond that, which is the expected baseline.

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

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

States the resource ('library namespaces') and enumerates each action with its specific effect: create a named library, list all with counts, delete a memory by id. It explicitly names the siblings it supercedes (mind_create / mind_list / mind_delete), so an agent can place it precisely without opening 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?

The action breakdown and the 'Replaces mind_create / mind_list / mind_delete' note tell the agent when to reach for this tool over the older single-purpose siblings. No explicit 'when-not' or prerequisite guidance, but the routing context is clear.

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

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

With no annotations provided, the description carries the burden but discloses the lifecycle state (deprecated, removed in v2.0) and the successor call, which is the key behavioral fact. It doesn't cover return format or auth, but for a deprecated read-style listing tool the lifecycle warning is the relevant disclosure.

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

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

Front-loads the actionable warning (DEPRECATED + replacement) before the parenthetical description of what it did. No wasted words.

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

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

For a deprecated, zero-param tool with no output schema, the entry gives the agent everything needed: what it did, that it is deprecated, the replacement call, and the removal version. Only a note on whether it still functions in the current version is arguably 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?

Zero parameters, so there is nothing to document; baseline 4 applies. The description correctly adds no parameter noise.

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 parenthetical '(List all libraries)' states a specific verb and resource, so the agent knows what the tool did. However, the deprecated/replacement framing leads, and it doesn't explicitly differentiate scope against siblings like mind_library beyond naming the replacement.

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 tells the agent not to use this tool and to use mind_library(action="list") instead, plus states the removal version. The when-not-to-use and the alternative are both named with no inference required.

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 discloses idempotency on (memory_id, signal_type, source), downstream external_signal_score effects, and procedure counter bumps. However, it omits permissions, error behavior, and the exact response shape, so it is rich but not fully complete.

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 purpose and usage, then moves into idempotency and side effects, which is a sensible structure. It is somewhat dense with internal references such as '§3 Mechanism 2 doubt-window guardrail' and a version prefix, but most sentences carry actionable 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 mutation-style tool with no annotations and no output schema, the description covers purpose, when to use it, idempotency, scoring impact, and procedure integration. It still leaves gaps around return values and error conditions, but it is largely complete 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 the baseline is 3. The description adds meaning beyond the schema by defining the idempotency key as (memory_id, signal_type, source), explaining that memory_id may target any memory or a procedure, and instructing the caller to pass the procedure id returned by mind_learn.

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: 'Record a typed external-signal outcome on any memory (not only procedures).' It explicitly distinguishes this tool from procedure-specific alternatives and enumerates the signal types, so an agent can identify scope and route correctly.

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

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

It gives explicit triggers: 'Use this when a test passed/failed, code compiled, a user explicitly confirmed/denied a fact, or a citing memory referenced this one.' It also names the condition for avoiding a separate mind_procedure_outcome call when the target is a procedure and the signal is test_passed or code_compiled.

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 disclosure burden and does well: it explains that Multi predicates never conflict, that Single/TemporalSingle raise a conflict_pending event on a second distinct object, and that unregistered predicates default to Multi. It omits whether register overwrites existing registrations or what get/list return, but the core behavioral semantics are clearly stated.

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 purpose then the behavioral consequence that justifies it. The 'v1.4:' prefix is minor version noise that could be dropped, but overall there is little waste.

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 tool with full schema coverage and no output schema, the description supplies the one thing the schema cannot: the semantic effect of each cardinality on downstream conflict detection and the default behavior. Return values of get/list are left unstated, but that is a minor gap.

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

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

Schema coverage is 100%, so the three parameters are already documented and the baseline is 3. The description adds genuine meaning beyond the raw enum by explaining what each cardinality value actually does to conflict detection, which is the semantic payload the caller needs.

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 pair ('register and inspect') plus the resource ('predicate cardinality'), and the verbs map cleanly onto the action enum (register/get/list). An agent can distinguish it from siblings like mind_fact since it governs predicate metadata rather than asserting facts. It lacks an explicit sibling comparison, but the purpose is unambiguous.

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

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

The description frames usage indirectly by explaining that cardinality dictates how mind_fact(action="add") detects conflicts, which tells an agent why it might register. However, it never states when to register vs get vs list, nor when to leave the Multi default in place, so the routing guidance is implied rather than explicit.

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 disclose a real side effect: worked=false increments a fail count and demotes the procedure, and the stated rationale (self-correction instead of ossification) explains why. It omits what worked=true does, idempotency, and whether an unknown id errors.

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 with the action front-loaded and the rationale second; every clause earns its place and 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 2-parameter mutation with no output schema and no annotations, the description covers the key behavioral consequence, but it leaves gaps on the success path (what worked=true changes) and failure/error behavior.

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 would be 3, but the description adds meaning beyond the schema by explaining the consequence of the worked flag's values (demotion on false), which is not encoded in the parameter description.

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 (record) and resource (whether a recalled procedure worked when reused), which is more precise than the bare tool name. It does not, however, distinguish itself from the nearby sibling mind_outcome, which an agent must disambiguate on its own.

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: the agent can infer this is called after mind_recall and a reuse attempt, but there is no explicit when-to-use, when-not, or named alternative (e.g. mind_outcome) to route between.

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 disclose key behaviors: the plain-UTF-8/no-markup requirement with the agent responsible for stripping markup upstream, the mandatory-provenance rule, and (via schema) the mind_add fallback. It could go further on persistence semantics (overwrite vs append, idempotency), so not a full 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?

Four front-loaded sentences with essentially zero waste: purpose first, format constraint second, usage rule third. Tight, though the format constraint slightly overlaps with the schema's snippet description.

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 9-param write tool with no annotations and no output schema, the description covers the critical constraints (provenance, session-origin, plain text) and the schema covers the rest. Return/persistence semantics are the only modest gap.

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

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

Schema coverage is 100%, so all nine parameters are already documented, including regexes, allowlists, and the failure message on empty search_tool_used. The description adds only the plain-UTF-8 framing already echoed in the snippet field, so 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 (Persist) and resource (externally-sourced snippet) with its distinguishing feature: the mandatory provenance citation. It clearly separates itself from the sibling mind_add by requiring provenance rather than memory-sourced data.

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

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

Explicitly states when to call (ONLY when the snippet was just produced by a code-search or doc-search MCP in the same session) and when not to (do NOT fill provenance fields from memory). The schema reinforces the routing to mind_add when provenance is unknown, so the agent has an alternative path.

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 delivers: it states expire 'only ever touches quarantined points, never live memory, and stays recoverable from the audit log', and that list is newest-first while show returns full content plus gate reason. It stops short of describing return shape or limits beyond the schema defaults, so not a full 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?

Front-loads the overall purpose, then breaks out each action in a tight parenthetical series with zero filler. Dense but well-ordered, 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?

No output schema and no annotations, yet the description covers the action set, id requirements per action, ordering, scoping, recoverability, and the safety boundary against live memory. 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 coverage is 100%, so baseline is 3, but the description adds real meaning to the action enum the schema only labels 'What to do' – defining list vs show vs promote vs expire behavior and when id is needed. It exceeds the baseline without fully re-specifying every param.

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 set (inspect, promote, expire) and a precise resource (entries the relevance gate filtered into the quarantine layer). It even names the three siblings it replaces (mind_quarantine_list / _show / _promote), so an agent can route to it without opening any schema.

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

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

Explicitly maps each action to its intent: promote when 'the gate was too strict', expire when 'the gate was right', list for newest-first browsing with an optional library filter. The alternative-condition reasoning leaves nothing 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?

With no annotations, the description carries the disclosure burden and does well: it explains that results are deliberately excluded from mind_search, that the layer comes from the v0.11 relevance gate, and that ordering is newest first. It does not cover permissions or pagination/truncation behavior, which would round out the mutation-free read profile.

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 deprecation and replacement instruction is correctly front-loaded, and the parenthetical packs scope, exclusion-from-search, trigger, and ordering efficiently. The nested parenthetical is dense but every clause carries information 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?

No output schema and no annotations, so the description must stand alone, and it adequately explains what the tool returns and how results are ordered. The main omission is what happens if the deprecated tool is called after removal, and limit's effect on the result set.

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 50%: 'library' is documented but 'limit' has only a default, no description. The description adds no parameter-level detail beyond implying recency ordering, so it neither compensates for the gap nor goes beyond the schema. Baseline 3 for partial coverage.

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 parenthetical states a specific verb+resource ('List entries the v0.11 relevance gate filtered into the quarantine layer') and differentiates it from siblings by noting these are not surfaced by mind_search by design. The front-loaded DEPRECATED/removal notice, however, is the dominant message, so the actual purpose is secondary rather than the opening statement.

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 the replacement explicitly (mind_quarantine(action="list")) and gives a concrete trigger for using this tool (when you suspect a fact was filtered, e.g., the user keeps repeating low-signal content). The guidance is slightly self-contradictory, though: it tells the agent the tool is removed in v2.0 and to use another tool, then also tells it when to use this one.

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 behavioral burden. It does disclose the effect (entry becomes live/ordinary) and the crucial lifecycle fact that the tool is removed in v2.0, but says nothing about reversibility, permissions, or behavior when the id is missing or already promoted. Useful context, but incomplete for a mutation tool with zero annotation coverage.

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 deprecation and replacement are front-loaded, which is the right priority for an agent deciding whether to call it. The nested parenthetical is slightly awkward but the whole thing is short and every clause (deprecation, effect, alternative path) 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 single-parameter, deprecated tool with no output schema, the description supplies what an agent needs: what it does, when to use it, and that it should migrate to the replacement. Missing only edge-case behavior, which is minor given the deprecation.

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 0% for the single 'id' parameter, so the description must compensate. 'by id' implies the identifier refers to a quarantined entry but adds no format, source, or lookup guidance beyond that bare hint. Minimal compensation for the coverage gap.

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: 'Explicitly promote a quarantined entry to ordinary memory by id.' An agent immediately knows this moves an entry out of quarantine into normal memory, distinct from siblings like mind_quarantine_list or mind_restore. The deprecation banner is front-loaded rather than obscuring the purpose.

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 replacement (mind_quarantine(action="promote")), states removal in v2.0, and contrasts the manual path against the automatic one (re-asserting via mind_ingest). It even gives the selecting condition: 'use this when you know the entry should be live without re-ingesting.' This is textbook when/when-not/alternative 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 one meaningful edge behavior — returning "not in quarantine" for regular memory ids — but says nothing about permissions, output shape, or whether the read is safe/idempotent, so coverage is partial.

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 deprecation warning is front-loaded where an agent will see it first, followed by the functional description in parentheses. Nearly every sentence earns its place; the parenthetical behavioral note is slightly buried but useful.

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 deprecated one-parameter read tool with no output schema, the description covers lifecycle status, replacement, purpose, and one return edge case. Nothing essential is missing for an agent deciding whether to call or avoid 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 0% for the single required `id` parameter. The description hints the id can be either a quarantine entry id or a regular memory id (via the "not in quarantine" behavior), which adds some meaning, but does not specify the expected id format.

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 — "Show a single quarantined entry with its full content and the gate reason" — which is far more than the name alone conveys. It also makes the lifecycle status unambiguous (deprecated, removed in v2.0), though it does not explicitly contrast with the single-entry vs. list sibling (mind_quarantine_list).

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

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

It gives explicit when-not-to-use guidance ("DEPRECATED") and names the exact replacement call, mind_quarantine(action="show"), plus the removal version. An agent needs no inference to know this tool should not be selected for new work.

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 does disclose the non-obvious ranking logic: verified/proven fixes are boosted, repeatedly-failing ones demoted, and strongly-matching unverified ones still surface. That materially helps an agent interpret and trust ordering. It still omits read-only status and the shape of a returned 'playbook'.

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, purpose front-loaded before the ranking detail, with no filler. The second sentence is slightly dense but every clause describes a distinct ranking behavior that 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 3-parameter recall tool with no output schema and no annotations, the description explains purpose and ranking but never describes what a returned playbook contains or the response shape. Adequate but with a clear gap given structured data cannot fill 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 description coverage is 100%, so error (lexical), context (semantic), and limit (default 3) are already fully documented. The description adds the 'and/or' combinatorics — that either or both matching inputs may be supplied — but little else beyond what the schema provides, so the baseline 3 holds.

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 ('Recall error->fix playbooks') with additional scope ('for an error and/or a task context'). An agent can tell what the tool returns without opening the schema. It does not, however, explicitly distinguish itself from the sibling mind_recall_all, which is the natural alternative an agent would weigh.

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 phrase 'for an error and/or a task context' implies the situation in which to reach for it, but there is no explicit when-to-use, when-not-to-use, or named alternative (e.g. mind_recall_all, mind_search). Usage 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, the description carries the full behavioral burden; it usefully discloses result ordering (current facts, then semantic memories, then error->fix procedures), which is real behavior beyond the schema. It says nothing about read-only safety, permissions, pagination, or result size limits, leaving notable gaps for a no-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 zero filler; scope and the core differentiator ('one call instead of three') are front-loaded. Every clause carries 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?

No output schema exists, and the description partially compensates by describing the ordering of returned silos, which is the key thing an agent needs to interpret results. It is nearly complete for a two-parameter recall tool, missing only return-shape and safety details.

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 ('query' and 'limit') are already documented there, so the description only adds the framing 'for one query' and the notion of per-silo limiting. No format, syntax, or default behavior is added beyond the schema, making baseline 3 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 (recall) and resource (all memory types: facts + memories + procedures), and explicitly frames itself as the union of three searches, which distinguishes it from siblings like mind_recall and mind_search. An agent can tell 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?

The phrase 'One call instead of three separate searches' clearly signals when to prefer this tool over narrower search calls. However, it never names the actual alternative tools (mind_search, mind_recall, mind_fact_query) or states any when-not condition, so routing is implied rather than explicit.

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 meaningful traits: archiving is reversible, memories are hidden rather than deleted, and the effect is returning to search. It does not cover failure modes (invalid/non-archived id), side effects, or permissions, which keeps it below 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?

Two sentences, no filler, with the core action and the id-scoping front-loaded and the archiving relationship following as supporting context. 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?

For a single-parameter, annotation-free tool with no output schema, the description supplies enough to call it correctly and understand its effect on search. It is slightly incomplete on return behavior and error handling, but the essential context is present.

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

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

Schema description coverage is 100% and the single 'id' parameter is already documented as 'Memory id of an archived entry'. The description reinforces 'by id' but adds no syntax, format, or constraint beyond what the schema supplies, 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 (restore) on a specific resource (an ARCHIVED, soft-forgotten memory) addressed by id, and frames the operation precisely as the undo of archiving. An agent can immediately distinguish it from sibling mind_delete (permanent removal) and mind_consolidate (the archiving operation itself).

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 usage to the archiving operation ('Archiving (consolidate --archive-cold) reversibly hides...; this is the undo'), giving a clear condition that selects this tool over alternatives. It does not state exclusions (e.g. what to do when the id was hard-deleted rather than archived), so it stops 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?

No annotations are provided, so the description carries the full behavioral burden, and it discloses almost nothing beyond the search mode. It says nothing about result ordering (the reranker behavior that is central to this tool), pagination, result format, or cost/latency characteristics of a semantic search over a tiered store.

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?

A single front-loaded sentence with zero filler, naming the core operation first and the optional modifiers second. It is efficient, though arguably too terse given the tool's 11 parameters.

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 an 11-parameter retrieval tool with no annotations and no output schema, one sentence is not enough. Nothing explains how tier, rerank, rerank_top_k, or the library vs libraries distinction should be chosen, and with dozens of sibling tools the agent has no routing context.

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

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

Schema description coverage is 100%, so the schema already documents all 11 parameters in detail. The description only restates the filter categories (author, source, date window, multiple libraries) and adds no syntax, defaults, or interaction rules beyond what the schema provides, so 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 ("Semantic search across memories") plus the filter categories it supports, so the agent knows the retrieval mode. However, it never distinguishes itself from close siblings like mind_recall, mind_recall_all, mind_fact_query, or mind_should_search, so the agent must infer which one applies.

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?

There is no when-to-use guidance and no alternatives named. With ~40 sibling memory tools including several other recall/search entry points, the description gives the agent no basis for choosing mind_search over mind_recall or mind_should_search.

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 disclose per-action semantics plus that the end summary must be hand-written, free-form, and under 200 words. However it omits edge behavior: calling start when a session is already active, what last returns when no prior session exists, persistence/ordering guarantees, and whether end is irreversible.

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 tight sentences, front-loaded with the resource, then the enum breakdown, then the migration note. Every clause earns its place and 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?

There is no output schema, so the description must convey returns, and it only partially does ('last — read the previous session's summary'); what start and end return, and any error signaling, are unstated. Adequate for the happy path but incomplete for a lifecycle tool with a required enum action.

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. The description adds only marginal meaning beyond the schema (it restates what each action does and that agent should be consistent across start/end), with no extra constraints such as summary being ignored for actions other than end.

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 resource (the agent's session record across runs) and enumerates the three lifecycle operations with a parenthetical gloss for each. It also explicitly says it supersedes mind_session_start/_last/_end, letting an agent distinguish it from named siblings without opening 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?

Each action is scoped: start opens a session, last reads the prior session's summary, end closes the active one. That is clear routing guidance for the enum, and the 'Replaces...' clause tells the agent not to reach for the old split tools. No explicit exclusion or prerequisite (e.g. what happens if start is called while one is open) is given.

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. It usefully discloses deprecation and removal-in-v2.0 status, which is real behavioral context beyond the schema. However, it does not say what actually happens when invoked (error, no-op, silent success), which matters for a deprecated mutation-style 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?

Extremely tight, with the most decision-critical information (DEPRECATED and the replacement) front-loaded. Slightly fragmented across two parenthetical thoughts, but every token 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 simple two-parameter tool with no output schema, the description covers what it does and that it should not be used. Given the deprecation, the only meaningful gap is runtime behavior on invocation, which is minor for a deprecated endpoint.

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% – both 'agent' (default 'unknown', references mind_session_start) and 'summary' are documented in the schema itself. The description adds no parameter syntax or meaning beyond that, 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?

The parenthetical '(End the active session for an agent)' states a specific verb and resource, so an agent knows exactly what the tool does. It also names the replacement tool (mind_session), differentiating it from siblings like mind_session_start. The purpose is clear but subordinated to the deprecation notice, keeping 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?

It explicitly states the alternative (mind_session(action="end")) and the condition that makes this tool unusable ('Removed in v2.0'). This is unambiguous routing away from the tool, which is exactly the guidance an agent needs for a deprecated endpoint.

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 behavioral burden. It clearly discloses deprecation and removal in v2.0, which is the most critical trait for tool selection. It does not state whether the operation is read-only or what happens if called, but for a deprecated stub the key behavioral disclosure is present.

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, front-loading the most important information (DEPRECATED) and including only the essential replacement instruction and a brief purpose note. No sentence is 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?

For a simple, deprecated tool with a fully documented single parameter and no output schema, the description provides sufficient context: what it does, that it should not be used, and what to use instead. It does not explain the contents of a 'session summary', but that is not necessary for the agent's decision.

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

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

Schema description coverage is 100%, and the single parameter ('agent') is already documented in the schema as 'Only consider this agent's sessions'. 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?

The description states the resource and action ('Get last session summary') and explicitly distinguishes itself from the sibling it replaces by naming mind_session(action="last"). The purpose is clear, though it is presented as a parenthetical after the deprecation notice, so it is not front-loaded.

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

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

The description explicitly tells the agent not to use this tool, gives the exact alternative (mind_session(action="last")), and states the removal version (v2.0). This is complete when/when-not guidance with a named alternative.

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 behavioral burden. It usefully discloses deprecation and the v2.0 removal, which is exactly the context an agent needs to avoid this tool, but it never says whether invoking it still works, returns an error, or where it routes. For a tombstoned tool, that operational behavior is the key missing disclosure.

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

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

Two terse fragments with zero waste, front-loading the DEPRECATED marker and the replacement before the parenthetical purpose. Optimal for a tombstone entry.

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 deprecated single-parameter stub with no output schema, the replacement pointer and removal version are the essential facts and both are present. It could be more complete by confirming whether calls now fail or are proxied.

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% for the single `agent` parameter, so the schema already documents it. The description adds no syntax, default, or meaning beyond that, which matches the baseline 3 when structured data does 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 states a specific verb and resource ("Start a new session") and explicitly names the successor tool that replaces it. An agent can identify this as a deprecated session-start stub without opening the schema. It falls short of 5 only because the deprecated framing, not the behavior, carries the identity.

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 an explicit, actionable directive: use mind_session(action="start") instead, and states it is removed in v2.0. The when-to-use and the alternative are both spelled out, leaving nothing 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?

With no annotations, the description carries the full burden and does well: it discloses the return shape (priority / reason / libraries), states the advisory limitation ('cannot force a search'), and explains the policy it implements. It does not cover failure modes or cost, but the key behavioral traits are present.

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 the return values, then the trigger conditions and the advisory caveat. It is dense and slightly run-on but every clause adds decision-relevant information; nothing is 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?

For a one-parameter classifier with no output schema, the description supplies purpose, trigger conditions, return values, and its own limitation, which is close to complete. Minor gaps are the absence of an explicit follow-up tool to invoke on a must-search verdict.

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 is only one parameter (query) and schema description coverage is 100%, so the schema fully documents it. The description adds policy context around when to supply the query but no new syntax or format meaning beyond the schema, making the baseline 3 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 and resource — it decides whether to search memory before answering — and clearly distinguishes itself from actual search siblings (mind_search, mind_recall) by being an advisory classifier rather than a retrieval tool. An agent can tell what it produces (priority, reason, libraries) 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 says to call it 'on a turn when unsure' and enumerates the trigger policy cases (named project, meta-cue, negation to verify, cross-session reference), giving clear usage context. It does not explicitly name the alternative tool to run after a positive decision (e.g., mind_search), so routing to siblings is only 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?

With no annotations provided, the description carries the full burden and does substantial work: it discloses that name is the identity so re-writing the same name edits in place and preserves history, that remove deletes, and that verify=true should only be used for deterministic signals, 'never a hunch.' It also explains that match ranks by relevance and by observed outcomes. Not covered: what match/list/show actually return or any error/permission 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?

A single dense paragraph, front-loaded with the core concept and the sibling contrast before detailing actions; nearly every clause conveys a distinct rule. Slightly breathy in places ('the way you would check for a house rule'), and the action list reads as a run-on, but nothing is gratuitous.

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 six-action tool with eight parameters and no output schema, the description explains the semantics of each action but never describes what match, list, or show return (ranked playbooks with what fields? the body? history?). Mutation-side behavior is well covered, but the read-path gap leaves an agent guessing about results.

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 already 100%, so the baseline is 3, but the description adds real meaning beyond the schema: name-as-identity semantics (writing the same name edits and keeps history) and the constraint that verify should only be set on deterministic signals. The 8KB body cap and task/when roles are left to the schema.

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

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

The description names the resource concretely (skills/playbooks, 'the house way of doing a kind of work') and its trigger (the task you are about to start), which is enough to separate it from mind_recall_all/mind_recall. The multi-action surface (match/set/list/show/remove/outcome) is enumerated, though the primary verb is diffused across six operations rather than stated crisply up front.

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 when to call it ('before starting non-trivial work'), what action to use for the common case (action=match takes a task description and returns the playbooks that apply), and explicitly routes the agent away from the sibling: 'mind_recall is the other half: it answers an error that already happened.' Per-action guidance is bundled in as well.

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. 'Show' weakly implies a read-only, side-effect-free operation, but the description says nothing about scope (which memory stores are counted), cost, or the shape of the returned statistics, and there is no output schema to fill that gap.

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

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

Three words, no filler, purpose stated up front. It is arguably too terse to be useful, but nothing in the sentence is wasted or 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?

For a zero-argument read tool this is the minimum viable description: it names the resource but not what the statistics cover (counts, sizes, types) nor when they refresh. With no annotations and no output schema, a slightly richer description would materially help an agent decide whether to call 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?

The tool takes zero parameters, so the schema is trivially complete and there is nothing for the description to disambiguate. The baseline of 4 for a no-parameter tool 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 ('Show memory statistics'), so an agent immediately knows this returns aggregate information rather than recalling or mutating memories. However, it does nothing to differentiate itself from adjacent diagnostics siblings such as mind_doctor, mind_history, or mind_context.

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?

There is no when-to-use guidance, no statement of when this is preferable to mind_doctor or mind_history, and no mention of any prerequisite state (e.g., memory must be initialized). The agent must infer usage entirely from the name.

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 substantive work: it discloses that no secret value ever crosses the MCP channel, that the operation is terminal-only, and that the tool's output is guidance rather than a performed action. It leaves unstated the exact shape of the rendered instructions and error behavior for an invalid action, which keeps it out of the top band.

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 with no filler, and the most important constraint ('terminal-only by design', secrets never cross MCP) is front-loaded before the action enumeration and the replacement note. The final replacement sentence is slightly redundant with the action list but earns its place as 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 2-parameter, annotation-free, output-schema-free tool the description is close to sufficient: it explains the design rationale, the three actions, and the deprecation mapping. The one gap is that an agent is not told explicitly that the returned text is meant to be surfaced verbatim to the user rather than acted upon.

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% for both parameters, so the baseline is 3. The description restates the three action values as instruction variants (store/get/list), which largely duplicates the schema's enum descriptions and 'What instructions to render', and adds nothing new about `key` beyond the schema's interpolation note.

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 and unusual purpose: it does not touch secrets but renders instructions for running the equivalent `mgimind vault` command. It explicitly distinguishes itself from the sibling tools by naming mind_vault_store / _get / _list as replaced. It stops short of a 5 only because the replacement relationship is asserted rather than explained (the siblings still appear in the toolset, leaving a small ambiguity about their live status).

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 clear context for when to reach for this tool ('Vault is terminal-only by design', secrets never cross the MCP channel) and routes the agent away from the older per-operation siblings. It does not spell out exclusions or edge conditions (e.g., what to do if the user asks for a value directly), so it lands at clear-context-without-exclusions.

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-disclosure burden. It reveals two important traits — deprecation/removal and that plaintext is never returned over MCP — but omits auth requirements, error behavior, and what the tool actually returns if invoked.

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 short and front-loads the deprecation warning, which is appropriate. However, the nested parenthetical "(Explain how to retrieve a secret (never returns plaintext over MCP))" is awkward and reads more like an instruction than a structured description.

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 deprecated single-parameter tool, the description sufficiently routes the agent away to mind_vault. It is incomplete for a still-callable tool because it does not explain return values or failure modes, and there is no output schema to fill that gap.

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

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

Schema description coverage is 100%, so the single key parameter is already documented in the schema. The description does not add format, syntax, or other meaning beyond what the schema provides, making the baseline 3 appropriate.

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

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

The description states a specific deprecated tool for retrieving a secret and explicitly points to the replacement, mind_vault(action="get"). It also notes that plaintext is never returned over MCP, which distinguishes it from a general retrieval tool. However, the fragmented deprecation-first phrasing and odd parenthetical keep it from being a fully clean purpose statement.

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 says the tool is deprecated, removed in v2.0, and directs the agent to use mind_vault(action="get") instead. This gives an unambiguous when-not-to-use and a concrete alternative.

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 behavioral burden and usefully discloses that the operation is terminal-only and requires the master password. It does not describe return values or error behavior, but the deprecation status and auth constraints are valuable.

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 deprecation warning is front-loaded and the replacement is stated immediately. The parenthetical is somewhat confusing and could be clearer, but the description remains short.

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 deprecated, zero-parameter tool with no annotations or output schema, the description provides the essential information: do not use it, use mind_vault(action="list"), and note terminal/master-password constraints. It is nearly complete, though the original purpose could be stated more cleanly.

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

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

The tool has zero parameters, so the baseline is 4. The description adds no parameter information, and none is 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 marks the tool as deprecated and names the replacement, mind_vault(action="list"), so an agent can distinguish it from active siblings. The parenthetical also hints at the original purpose of listing stored secret keys, though it is awkwardly phrased and incomplete.

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 tells the agent not to use this tool and to use mind_vault(action="list") instead, and states it was removed in v2.0. This is exactly the routing guidance needed for a deprecated tool.

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

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

With no annotations, the description carries the full burden, and it does disclose one genuine behavioral trait: it never accepts the secret over MCP, which is security-relevant context an agent could not infer from the schema. Beyond that it reveals nothing about what happens on call, and the deprecation status is stated inconsistently ('deprecated' vs 'removed in v2.0').

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 deprecation notice and redirect are correctly front-loaded, but the trailing parenthetical '(Explain how to store a secret (never accepts the secret over MCP))' is confusing, nested, and reads like an authoring instruction that leaked into the text. That fragment does not earn its place and actively obscures the message.

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-parameter, no-output-schema tool the description is just adequate: it tells the agent to migrate to mind_vault. However, it never resolves the core ambiguity of whether this tool is still callable or returns an error, and it leaves the security constraint sentence unexplained. An agent has the migration path but not a complete picture of current behavior.

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% for the single 'key' parameter, so the baseline is 3. The description adds no syntax, format, or naming guidance for the key beyond what the schema already says, and the parenthetical about never accepting the secret arguably raises a question the parameter docs do not answer.

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's primary function is a deprecation notice, and it names the replacement (mind_vault with action="store") clearly enough to distinguish intent. However, the stated purpose is muddled by the parenthetical '(Explain how to store a secret...)', which reads like leaked internal text rather than a purpose statement. An agent can tell this tool stores a secret but not cleanly what the tool itself does versus what it documents.

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 routes the agent to the alternative: mind_vault(action="store"), and states the condition (this tool is deprecated/removed in v2.0). That is stronger than most definitions. It loses a point because the 'removed in v2.0' claim conflicts with the tool still being present and callable, leaving the agent unsure whether it works at all.

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 does well: it discloses a side effect (spawns a local viewer), the delivery channel (user's browser), and the return value (the URL). It omits anything about permissions, port conflicts, or what happens if a viewer is already running, which keeps 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 sentences, front-loaded: what it does and what the user sees, then when to call it, then the mechanics and return. Every sentence adds distinct information with no filler.

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

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

For a zero-parameter tool with no output schema and no annotations, the description covers purpose, trigger, side effect, and return value. 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?

The tool takes zero parameters, which is the documented baseline of 4. The description correctly implies a no-argument invocation by never referencing any input.

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 ('Open the 3D memory visualization in the user's browser') plus what the visualization actually contains. No sibling tool in the list does anything comparable, so an agent can distinguish it immediately.

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 invocation trigger with quoted user phrasings ('SEE or SHOW their memory / "the brain" / how memory looks'), which is strong usage guidance. It stops short of naming when-not to use it or pointing to an alternative, so it lands at 4 rather than 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?

No annotations are provided, so the description carries the full behavioral burden. It does disclose the dual read/save mode, but that same information is already in the schema's save parameter, and it says nothing about fetch failures, permission/auth needs, rate limits, or whether saving overwrites existing library entries.

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

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

One compact, front-loaded sentence with no filler and the primary action stated first. It is arguably under-specified rather than over-long, but the structure itself is efficient.

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 two-parameter tool with no output schema, the description covers the core action and the Markdown return format. It omits what a 'library' value means, what the default save destination is, and error behavior, leaving meaningful gaps.

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

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

Schema description coverage is 100% and both parameters are documented in the schema, so the baseline of 3 applies. The description restates the read/save distinction but adds no format, default, or destination-library semantics beyond what the schema already provides.

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'), resource ('a webpage'), and output format ('as Markdown'), plus the optional save behavior. It is clear what the tool does, but it never distinguishes itself from plausible siblings like mind_browse or mind_ingest.

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 'optionally save to library' phrasing implies when to pass save versus omit it, which is useful implied guidance. However, there is no explicit when-to-use-this-vs-alternative statement (e.g., mind_browse or mind_ingest), so routing relies on inference.

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