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

It discloses the live-subscription behavior, explains that timeout is a normal outcome rather than an error, describes cursor resumption via since_seq/next_seq, and covers buffer expiry with cursor_expired and oldest_seq. This adds substantial behavioral context well beyond what the annotations already state.

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?

Although the description is longer than average, every section earns its place: behavior, usage, return contract, and parameter details are separated cleanly. The length is justified by four parameters and a non-obvious return/cursor contract.

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

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

The description is complete for this tool's complexity: no output schema exists, yet it documents the return shape, event semantics, timeout behavior, cursor continuation, and both scope and keyspace modes. An agent has everything it needs to call this tool 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 0%, but the description fully compensates: it documents all four parameters, including scope's shared keyspace, keyspace as an advanced override, timeout_sec's default and normal timeout behavior, and since_seq's cursor semantics. This is exactly the compensation needed when the schema provides no descriptions.

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

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

The description uses a specific verb and resource: it waits until memory is written, updated, or deleted, and returns at the moment of change. It also distinguishes itself from montycat_semantic_search, so an agent can tell this subscription-style tool apart from its siblings.

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 when to use the tool: coordinating with other agents sharing a scope and confirming that a write from another session landed. It also gives a clear exclusion: do not use it in a tight loop as a substitute for searching, and directs agents to montycat_semantic_search 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?

Annotations already mark the tool as destructive, and the description adds valuable context: it destroys snapshot history but preserves loaded in-memory records, and notes that Montycat performs the final authorization check. This goes beyond the annotation and helps set accurate expectations for a mutation operation.

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 compact and well-organized: a one-sentence action statement, a two-sentence caveat about destructive scope and authorization, then a focused Args section. Every sentence earns its place, and the most important information is front-loaded.

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

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

For a single-parameter destructive tool with annotations already covering safety hints, the description is complete. It states what the tool does, what it affects, what it does not affect, the authorization step, and the meaning of the one required argument. No critical context is missing.

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

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

Schema description coverage is 0%, so the description must compensate for the parameter's meaning. It does so by explaining that keyspace is the 'Explicit in-memory keyspace whose snapshots are cleaned.' This adds key semantic detail beyond the bare property name and type in the input schema.

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

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

The description states a specific verb and resource: 'Delete snapshot files for one existing in-memory keyspace.' It also clarifies that it does not delete currently loaded in-memory records, which distinguishes it from siblings like montycat_remove_keyspace. This leaves no ambiguity about the tool's core function.

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

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

The description implies the tool is used to clean snapshot history for a keyspace, and it clarifies the destructive scope, but it does not explicitly state when to prefer this tool over alternatives or mention any exclusions. No sibling tools are referenced for routing decisions.

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

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

Annotations provide only generic false hints, so the description carries the behavioral burden. It discloses authorization delegation, the engine as final authorization boundary, the store-creation side effect for superowners, default storage behavior, and that supplying semantic_model implies semantic=True. It does not cover the effects of cache or compression, but the description adds substantial behavioral context beyond the structured fields.

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

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

The first sentence delivers the core purpose, and the governance/provisioning context is relevant rather than filler. The Args block is compact and useful. It is longer than strictly necessary but every section earns its place; no wasted wording.

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 provisioning tool with no output schema and only generic annotations, the description covers the important preconditions, authorization paths, defaults, and side effects. The main gaps are the undocumented cache and compression parameters and lack of explicit failure/return behavior, but the description is still strong enough for an agent to call the tool correctly in most cases.

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?

Given 0% schema description coverage, the description must compensate. It does explain keyspace, storage, semantic, semantic_model, and persistent, including meaningful inference like semantic_model implying semantic=True. However, it is completely silent on the 'cache' and 'compression' parameters, leaving two of seven parameters underdocumented.

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 action and resource: 'Create a new memory namespace' / keyspace. It clearly distinguishes this provisioning tool from sibling tools like list_keyspaces, remove_keyspace, and enable_semantic by establishing it as the creation entry point.

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

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

The description gives concrete conditions for use: a delegated owner can create a keyspace only when governance grants 'provision-keyspace' and the store already exists, while superowner credentials can create the store and first keyspace together. This is clear context, though it doesn't explicitly compare against sibling tools or state when not to use it beyond the store precondition.

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

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

Beyond the annotations (destructiveHint=true), the description explains the nuanced destructive behavior: vectors are retained unless drop_vectors is set, and dropping is recommended only in specific scenarios like changing embedding models. It also mentions governance enforcement, adding meaningful behavioral context not available from annotations.

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

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

The description is concise and well-structured: a one-line purpose, two sentences of important behavioral context, and a tight parameter list. Every sentence earns its place, with no filler or repetition.

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

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

Given the tool's destructive nature, three parameters, and absence of an output schema, the description covers what the tool does, its default non-destructive behavior, when to opt into destruction, and each parameter's meaning. Nothing essential for invoking it correctly is missing.

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

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

Schema description coverage is 0%, but the description fully compensates with an Args section covering all three parameters: keyspace ('Explicit keyspace to unenroll'), store ('Defaults to the configured store'), and drop_vectors ('Also delete stored vectors for this keyspace'). This adds meaning well beyond the bare schema titles.

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 ('Disable'), a clear resource ('semantic search'), and a scope ('one explicit keyspace'). This distinguishes it from siblings like montycat_enable_semantic and montycat_reembed_semantic without needing to open their schemas.

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

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

The description gives clear context: stored vectors are retained by default so re-enabling can resume without a full rebuild, and explicitly says to set drop_vectors only when intentionally clearing vectors. It does not explicitly name alternative tools, but the situational guidance is strong enough to guide correct 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?

The description notes a key behavioral trait—replacing text embedding with external vectors—but says nothing about side effects on existing data, whether the operation invalidates previously stored text embeddings, or what happens on repeated calls. Annotations are generic and do not fill this gap; no contradiction 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 one sentence with no wasted words, front-loads the main action, and places the differentiator at the end. It is easily parseable and appropriately sized for an overview, though it trades off depth.

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 four parameters, no parameter descriptions, and no output schema, an agent still lacks prerequisites, expected outcomes, error behavior, and relationships to setup tools like montycat_create_keyspace or montycat_install_engine. This is not enough to invoke the tool 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%, so the description must compensate for parameter meaning. It only clarifies the role of 'keyspace'; 'dimensions' and 'embedding_space' are unexplained, and the optional 'store' parameter is entirely opaque.

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

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

The description uses a concrete verb ('Enroll'), names the affected resource ('keyspace'), and clarifies the intent ('caller-supplied embeddings instead of text embedding'). This clearly distinguishes the tool from a text-embedding flow and from related sibling tools like montycat_enable_semantic.

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

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

The description implies when to use it: when callers will supply embeddings rather than relying on text embedding. It does not explicitly state when not to use it, nor does it name alternatives such as montycat_enable_semantic or montycat_install_engine, leaving some selection reasoning 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?

The annotations only provide generic false hints, so the description carries the burden of explaining behavior. It discloses meaningful side effects and constraints: the engine enforces manage-semantic and creator authority, existing records are backfilled, allowed-model constraints apply, and the operation is scoped to one keyspace. This goes well beyond what annotations alone tell an agent.

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 focused and efficiently structured: a one-line purpose, a short paragraph of behavioral constraints, and a clear Args list. Every sentence adds necessary information without fluff or 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?

The description covers the action, scope, permissions, side effects, and all parameter semantics, which is largely complete for invoking the tool. It does not mention return behavior, async behavior, or failure modes, and it does not cite sibling alternatives, so a small gap remains for fully autonomous decision-making.

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 input schema has 0% description coverage, so the tool description must compensate. It does: every parameter is explained, including defaults for store and semantic_model, the meaning of field, and the explicit allowed model names. This is strong, complete parameter guidance.

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 action and resource: "Enable semantic search for one explicit keyspace." It further differentiates itself with "This tool never enables semantic search database-wide," making the scope unmistakable. The title and body align clearly.

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 clearly implies when to use it: when enrolling a single keyspace for semantic search. It also gives an explicit exclusion: it never enables database-wide semantic search. However, it does not name sibling alternatives explicitly, such as montycat_enable_external_vectors or montycat_disable_semantic, so it lacks full alternative routing.

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

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

Annotations already flag destructive behavior with destructiveHint=true, and the description matches that. It adds useful behavioral context beyond the annotations by explaining that wait_for_index controls whether deletion waits for secondary indexes before returning and that keyspace defaults to the configured namespace.

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 a one-line purpose followed by a compact Args list. Every clause adds information, and there is no filler or restating 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?

With no output schema, zero schema descriptions, and a destructive operation, the description should define the full input contract. It covers the delete operation and wait_for_index behavior, but leaves scope unexplained and does not clarify the deletion target precondition. DestructiveHint covers the danger, so this is not a complete failure, but it is incomplete.

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%, so the description must compensate. It meaningfully explains keyspace, key, custom_key, and wait_for_index, but it omits the scope parameter entirely and does not clarify whether key/custom_key are alternatives or if at least one is required.

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 opening sentence 'Delete a stored record from memory by key or custom key' names a specific verb, resource, and selection method. It clearly distinguishes this from sibling tools like montycat_remember, montycat_recall, and montycat_remove_keyspace.

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 alternatives, no prerequisites, and no exclusions. The description implies deletion of memories, but the agent is left to infer that it should be chosen over related memory 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?

Beyond annotations, the description discloses concrete side effects: downloading an ~18 MB package, opening the OS installer, requesting an administrator password, and using sudo APT on Linux. It also warns about creating a second database and 'write memories where nobody is looking,' giving the agent real behavioral context.

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

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

The description is front-loaded with the primary action and each subsequent sentence adds necessary condition or effect information. It covers consent, behavior, refusal, no-op conditions, and Docker fallback without any 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 destructive, mutating install tool with no output schema, the description fully covers prerequisites, user consent, exact side effects, refusal conditions, and automatic Docker fallback. An agent has enough information to decide when to call it and what will happen.

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 input schema has zero parameters, so there are no parameter semantics to document. The description confirms there are no configurable inputs and instead explains what the tool autonomously handles, which is appropriate for a zero-parameter tool.

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

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

The first sentence states a specific action—'Install the Montycat engine on THIS computer, then start it'—with the resource and scope clearly named. This cleanly distinguishes it from the sibling read, memory, and update tools.

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 trigger condition: 'Call this only when memory tools report that no engine is running and the user has agreed to install one.' It also names exclusions and alternatives, including refusing when MONTYCAT_URI points elsewhere, doing nothing if an engine is reachable, and not being needed when Docker is available because startup falls back automatically.

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?

The description reinforces the readOnlyHint annotation and adds a non-obvious guarantee: 'This inspection is read-only and never creates a missing keyspace.' It also documents argument precedence, which is behavioral context beyond the schema. No contradiction with annotations.

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

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

The description is front-loaded with the tool's purpose, followed by targeted usage guidance and a compact Args section. There is no filler; each sentence adds operational 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 simple two-optional-parameter inspection tool, the description covers purpose, parameter semantics, defaults, and safety. It stops short of describing the exact output shape, but 'including field data types' gives a reasonable indication of the return content.

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?

With 0% schema description coverage, the Args section compensates fully: it explains keyspace as an explicit name with precedence, scope as an owner/user memory scope mapping to a configured keyspace, the special 'shared' value, and the default behavior when both are omitted.

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

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

The description opens with a specific verb and resource: 'List schemas enforced on a keyspace, including field data types.' This makes the tool's function immediately identifiable and distinguishes it from sibling list tools like montycat_list_keyspaces and montycat_list_memories.

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

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

It gives explicit when-to-use context: 'Use this before a structured write or retrieval when the target keyspace's required fields or types are unknown' and explains how it helps with typed filters. It does not name alternatives or state when not to use it, 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds minimal behavioral context with the word 'available' but does not mention output shape, possible empty results, or engine-state dependencies.

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, concise sentence that front-loads the action and resource without any wasted words or repetition of the title.

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, zero-parameter, read-only listing tool, the description adequately identifies the resource and scope. The lack of an output schema is not a major gap here, though a brief note on what the returned list contains would make it complete.

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

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

With zero parameters, the input schema imposes no burden and the baseline is naturally high. The description implies that no inputs are required, which is consistent with the empty schema.

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

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

The description uses a specific verb ('List') and resource ('available memory stores and keyspaces') scoped to 'this Montycat engine.' It clearly distinguishes itself from the sibling montycat_list_memories, which would list memory contents rather than keyspace names.

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 explicit guidance is given about when to use this tool instead of siblings like montycat_create_keyspace or montycat_remove_keyspace. The intended use is only implied by the verb 'list', with no when-to-use conditions or exclusions 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?

Annotations already mark this as read-only, idempotent, and non-destructive. The description goes further by explaining the 'up to limit records with their keys' return behavior, default values, and the non-trivial ordering semantics of `recent`, including persistent vs in-memory keyspace differences and fallback full scans. This is exactly the kind of behavioral context beyond annotations that agents need.

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 well-structured: purpose and routing are front-loaded, the returns behavior is stated immediately, and the Args section is compact with clear labels. The lengthy `recent` explanation is justified because it describes genuinely subtle ordering behavior, not fluff.

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

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

The description covers purpose, alternatives, output shape, defaults, and ordering behavior, making it largely complete for a read-only listing tool. However, the complete omission of the schema's `scope` parameter means an agent cannot know what that input controls or whether it is deprecated. For a tool with no output schema and no per-property schema descriptions, that is a meaningful completeness 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?

The description documents keyspace, limit, and recent with defaults and behavioral details, which is valuable given the schema has 0% property descriptions. However, the `scope` parameter appears in the input schema and is never mentioned in the description, leaving its meaning completely unexplained. This is a clear gap in an otherwise strong parameter documentation effort.

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

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

The description opens with 'Browse stored memories — enumerate what is remembered, not search by meaning,' giving a specific verb, resource, and scope. It explicitly contrasts itself with montycat_semantic_search and montycat_recall, so the agent can distinguish this tool from its siblings 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?

'Use this to review or list memory; for meaning-based recall use montycat_semantic_search, and for exact lookups use montycat_recall' is explicit when-to-use guidance with named alternatives. The negative constraint 'not search by meaning' also clarifies when not to use it.

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

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

Annotations already mark the tool as read-only and idempotent, and the description reinforces this by labeling it a read-only check. It adds valuable detail by stating that the tool 'identifies applicable grants, denials, creator authority, and storage/model constraints' and by clarifying that it does not execute the action.

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

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

The core behavior is front-loaded in the first sentence, followed by essential context about read-only planning use and a compact, well-organized Args block. Every sentence adds value, especially given the otherwise bare schema.

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

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

For a tool with five parameters and no output schema, the description covers purpose, usage context, behavioral boundaries, and all parameter semantics. It does not specify the exact return format, but it offers enough for correct selection and invocation.

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

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

The input schema has 0% description coverage and provides only parameter names and defaults, so the description must carry the full semantic burden. The Args block compensates thoroughly by enumerating allowed capability values, storage types, semantic model options, and default behavior for the store parameter.

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

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

The description uses a specific verb and resource: 'Explain whether the configured owner may perform a proposed action,' and it lists the kinds of constraints the explanation covers. This clearly identifies the tool's function, though it does not explicitly differentiate it from siblings like montycat_policy_view or montycat_policy_history.

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 says this is a 'read-only policy check for planning and diagnostics' and that 'executing the action still requires a separate tool call and fresh engine authorization.' This gives clear when-to-use and when-not-to-use context, but it does not name alternative sibling tools for comparison.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds meaningful behavioral context beyond those: owner-scoping by the authenticated Montycat credential, inability to select another owner, and the specific kinds of events visible (delegated, denied, revoked, transferred). No contradiction with annotations.

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

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

The description is tight and well-structured: purpose first, then scoping/behavioral notes, then an Args section. Every sentence earns its place, with no redundant phrasing.

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

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

For a simple read-only tool with two optional parameters and no output schema, the description covers purpose, scope, event types, and parameter defaults. It stops short of explaining ordering, pagination, or the exact return shape, but those are minor for a filtered history-view 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?

The input schema has 0% description coverage, so the description must compensate. It explains that store is an optional filter defaulting to the configured store, and keyspace is an optional filter. This adds real meaning beyond the bare property names, though it could go slightly deeper on how the filters narrow the history results.

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

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

The description opens with a specific verb+resource: 'View governance history visible to the configured owner.' It further specifies the types of events included (delegated, denied, revoked, transferred), clearly distinguishing this history tool from siblings like montycat_policy_view or montycat_policy_explain.

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 clearly states the tool is read-only and owner-scoped, and explains it surfaces governance events without allowing the caller to select another owner. It gives clear context for when to use it, though it does not explicitly name alternative tools or say 'use this instead of policy_view when you need historical events rather than current policy.'

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

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

Beyond the readOnlyHint and idempotentHint annotations, the description discloses the specific contents of the policy report: effective grants, denials, accessible and owned keyspaces, creator capabilities, provisioning constraints, and policy health. It also explains that the engine filters the result and remains the authorization boundary, adding useful behavioral context.

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

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

The description is compact, front-loaded with the core purpose, and every subsequent sentence contributes useful detail or parameter semantics. There is no redundant filler beyond the natural restatement of the tool's purpose.

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

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

For a zero-required-parameter read-only query with no output schema, the description is sufficient: it explains the optional input, defaults, result contents, and safety posture. An agent can invoke the tool correctly without needing additional undocumented 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 0%, so the description carries the burden for the single store parameter. It adds meaning by explaining that store is optional, what it selects for inspection, and that it defaults to MONTYCAT_URI or MONTYCAT_STORE. This adequately compensates for the sparse schema, though it does not mention accepted store formats.

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

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

The description clearly states the verb (view) and resource (the effective Montycat governance policy for the configured owner), and it expands on what the report contains. It does not explicitly contrast this tool with montycat_policy_history or montycat_policy_explain, so sibling differentiation is only implicit.

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 is provided about when to use this tool versus related policy or keyspace tools. The only usage-related context is the optional store parameter and its environment-variable default, which describes invocation rather than tool selection.

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

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds useful behavioral detail: recall is exact-match only, not semantic; filters use field equality; keyspace defaults to the configured one; and filter results default to a limit of 25. No contradiction with annotations 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?

The description is well-organized and front-loaded with the core distinction, followed by usage details and an explicit alternative. The Args block is slightly repetitive with the opening sentence but remains compact and scannable.

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 six optional parameters, no output schema, and 0% schema descriptions, the description carries heavy responsibility. It covers most operational behavior, but the undocumented `scope` parameter is a real gap, and the description does not state what the tool returns (single record vs. list) beyond implying it. It is adequate for basic use but not fully complete.

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

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

Schema description coverage is 0%, so the description must compensate. It does document `key`, `custom_key`, `filters`, `limit`, and `keyspace` with meaningful explanations and examples. However, it omits the `scope` parameter entirely, leaving the agent with only the unhelpful title 'Scope' from 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 opens with a precise statement: 'Recall memory by exact key or by field filter (not by meaning).' It names the resource (memories), the operation (recall), and the two lookup modes. It also explicitly names the semantic-search sibling, which distinguishes it clearly.

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

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

The description gives explicit usage guidance: use `key`/`custom_key` for a single record, use `filters` for field-equality lookups, and 'For meaning-based recall use montycat_semantic_search instead.' This is a clear when-to-use and when-not-to-use statement with an 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?

The description explicitly discloses that the operation clears the current vectors before rebuilding them, which is essential behavioral context beyond the destructiveHint annotation. It also directs the agent to verify the result via montycat_semantic_status, making the side effects and follow-up clear.

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 three sentences and front-loads the action. It contains no filler, clearly states the destructive effect, and adds a useful follow-up command. Every sentence earns its place.

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

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

For a destructive tool with no output schema and sparse parameter names, the description explains the main behavior, the side effect on existing vectors, and how to observe the outcome. It is sufficient for a basic call but leaves optional parameters and possible error conditions undocumented, so it is not fully complete.

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

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

The prose gives semantic meaning to the two required parameters: keyspace identifies the enrolled keyspace and semantic_model is the replacement embedding model. However, with 0% schema description coverage, the optional field and store parameters are left completely unexplained, so the description only partially compensates for the schema 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 description clearly identifies the action: replace an enrolled keyspace's text embedding model and backfill it. It also explains the consequence (clears and rebuilds vectors), which distinguishes it from sibling tools like enabling semantic search or creating a keyspace.

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 context is clear: this is used when you want to swap the embedding model for an already-enrolled keyspace. It also points the agent to montycat_semantic_status for observing the resulting configuration, though it does not explicitly state when NOT to use this tool or name alternatives for similar operations.

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?

The description goes well beyond the sparse annotations by disclosing automatic embedding and indexing, auto-stamping of _created_at, indexing of top-level fields for filters, wait_for_index catch-up semantics, and the return behavior. It adds substantial behavioral context that an agent needs to understand side effects and timing, with no contradiction of annotations.

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

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

The description is appropriately sized for the tool's complexity. It front-loads the primary purpose, then systematically covers return value, timestamp behavior, filtering implications, and a clear Args block. Every sentence adds value; no filler or 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?

Given the tool's complexity, 7 parameters, no output schema, and minimal annotations, the description covers everything needed: purpose, key return field, timestamp semantics, filtering via indexed top-level fields, per-parameter guidance, and advanced keyspace behavior. It is complete enough for an agent to call 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 0%, so the description carries the full burden. It provides detailed, meaningful explanations for all 7 parameters, including defaults, advanced usage, requirements (vector must match profile), and behavioral implications (wait_for_index). It fully compensates for the missing schema descriptions.

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

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

The description opens with a specific verb and resource: 'Store a fact or record in memory'. It immediately clarifies the core behavior (embedding and automatic indexing) and distinguishes itself from recall tools by naming them as follow-ups (montycat_semantic_search, montycat_recall). It is clearly differentiated from the sibling 'remember_bulk' by implication of a single record.

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

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

The description gives context about when storage matters ('Later recall it by meaning...'), but does not explicitly state when to choose this tool over alternatives like montycat_remember_bulk or montycat_update. No exclusions or explicit routing guidance are provided, so usage is mostly implied 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?

The description goes well beyond the minimal annotations by explaining that all records are embedded and indexed automatically, how timestamp affects indexing, what wait_for_index does, and the performance rationale for disabling timestamp. This is rich behavioral context for a write operation.

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 well-structured with an opening summary followed by a clear Args list. It is appropriately sized, and each parameter explanation is concise and relevant, though the two undocumented parameters add slight imbalance.

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

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

For a 6-parameter tool with no output schema, the description covers the core parameters and side effects but omits 'scope' and 'vectors', and doesn't mention return values or failure behavior. It is usable for basic invocation but not complete for advanced use cases.

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%, so the description must compensate. It clearly explains 'values', 'keyspace', 'timestamp', and 'wait_for_index', but leaves the 'scope' and 'vectors' parameters completely undocumented, which is a notable gap for an agent trying to use them correctly.

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 action ('Store many memories at once') and resource ('memories'), making the bulk variant clear. The name and title reinforce the bulk aspect, but it doesn't explicitly differentiate from the sibling montycat_remember, relying on the word 'bulk'.

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 'Store many memories at once' implies the use case for storing multiple records, but it doesn't explicitly say when to choose this over montycat_remember or montycat_forget. No alternatives or exclusions are provided, leaving the routing to inference.

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

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

Annotations already declare destructiveHint=true and idempotentHint=false, but the description adds substantial non-obvious behavior: it closes the keyspace's live watch, releases MCP resource-subscription ownership to prevent deadlock, and enforces policy/authority checks. This is precisely the kind of behavioral context an agent needs beyond the structured hints, and it does not contradict the annotations.

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

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

The description is well-structured and front-loaded with the destructive action and warning, followed by a labelled Args section. The technical sentence about closing watches and releasing subscriptions is somewhat niche but earns its place by explaining a real safety mechanism; 'explicit denials' is the only slightly vague phrase.

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 destructive operation, the description covers purpose, parameter semantics, and important safety side effects well. However, because both parameters are optional in the schema, the missing guidance on what happens if scope/keyspace are absent, or how they interact, is a meaningful completeness gap. With no output schema, a brief note on expected confirmation or error behavior would also strengthen the definition.

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%, so the description must carry parameter meaning, and it does well: scope is explained as mapping to keyspace mem_<scope> with the special value 'shared', and keyspace is described as an explicit override that bypasses scope. The main gap is that both parameters are optional in the schema but the description never clarifies what happens if both are omitted or whether they are mutually exclusive.

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

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

The description opens with a specific verb and resource: 'Permanently remove a memory namespace using the owner's authority.' This clearly identifies the operation and distinguishes it from sibling tools like create_keyspace, list_keyspaces, remember, or forget without requiring schema inspection.

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

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

The description implies lifecycle use and states authority prerequisites ('using the owner's authority', 'enforces remove-keyspace, creator authority, and explicit denials'). However, it never explicitly contrasts this tool with alternatives such as montycat_forget for deleting individual memories or says when not to use it, leaving the routing mostly implicit.

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

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

Beyond the read-only and idempotent annotations, the description discloses engine-version rejection behavior, score ranges and semantics per mode, that narrowing filters never affect ranking order, that an empty filter result returns [], and that supplying a vector bypasses query embedding. These behavioral details cannot be inferred from the annotations and materially help the agent anticipate edge cases.

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

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

The description is long but well structured: a purpose sentence, ranked-mode explanation, narrowing semantics, then an Args list. There is mild redundancy, such as repeating score ranges in the mode prose and again under min_score, but every section earns its place given the tool's complexity and the schema's lack of descriptions.

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 tool with no output schema and no enums, the description is remarkably complete: it specifies return contents (key, score, stored value), all valid score ranges, engine compatibility, timestamp indexing requirements, and edge cases like empty queries with vectors and empty filter results. An agent has enough information to call the tool correctly without external documentation.

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?

With 0% schema description coverage, the Args section carries the full burden and succeeds: all 11 parameters receive meaning, defaults, constraints, and cross-dependencies, such as 'query may be empty when vector supplies a precomputed query embedding' and 'timestamp_field must be stored as a Timestamp index.' This goes far beyond the schema's bare types and titles.

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 opening sentence states a specific verb ('Search'), a resource ('stored memory'), and two retrieval strategies, so an agent immediately knows what the tool does. It does not explicitly contrast the tool with siblings like montycat_recall or montycat_list_memories, so differentiation relies on implied semantics rather than direct comparison.

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 states when to use the tool ('Use this to recall relevant facts, documents, or past context for RAG and agent memory') and gives mode-selection guidance, such as using keyword mode for exact identifiers, error codes, or file names. It lacks explicit 'when not to use this tool' guidance or named alternatives, so it stops short of a perfect score.

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

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

Annotations already declare readOnlyHint and idempotentHint, so the safety profile is covered. The description adds valuable behavioral context by explaining the two invocation scopes and the superowner authority requirement for the database-wide view, going beyond what the annotations alone convey.

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

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

The description is compact and front-loaded: the first sentence states the tool's purpose, and the second provides the essential parameter guidance. There is no redundant or filler content; every sentence earns its place.

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

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

For a simple read-only status tool with two optional parameters, the description covers purpose, scoping rules, and an authorization caveat. It does not explicitly state what happens if only one parameter is provided, and there is no output schema, but the stated purpose already hints at the returned content.

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%, so the description carries the burden of explaining the parameters. It explains that both store and keyspace are needed together for a single keyspace view, and that omitting both selects the database-wide view, which meaningfully compensates for the schema's lack of descriptions.

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

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

The description clearly states the tool reads the engine's actual semantic configuration and backfill state, which is a specific verb and resource. It does not explicitly differentiate from sibling tools by name, but the read-status purpose is evident and distinct from search, memory, and policy tools.

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 provides clear usage context: pass both store and keyspace for a specific keyspace, or omit both for a database-wide view requiring superowner authority. It does not name alternative tools or explicitly state when not to use this tool, but the parameter-mode guidance is concrete and actionable.

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

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

Annotations already indicate the tool is not read-only and not idempotent, but the description adds meaningful behavioral context: enforcement of 'manage-snapshots' and creator authority, how to distinguish an environmental configuration error from an authorization denial, and the limitation on altering the global snapshot rate. This goes beyond the structured annotations without contradicting them.

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 compact and well-structured. It opens with the core action, then provides short, useful notes on permissions, error interpretation, and a boundary on what the tool cannot do, followed by the argument definition. Every sentence earns its place and there is no 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 simple one-parameter tool with no output schema, this description is largely complete: it states the action, the target resource, the required parameter, authorization expectations, and a common error condition. It does not describe the success response format or what happens if snapshots are already running, but those are minor gaps given the tool's low complexity.

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

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

The input schema only says 'keyspace' is a required string, and schema description coverage is 0%. The description compensates by defining the parameter as 'Explicit in-memory keyspace to snapshot' and by stating earlier that it must be an existing keyspace. This adds real semantic meaning beyond the schema, though it could be even more specific about naming conventions or how to discover valid keyspaces.

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

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

The description uses the specific verb 'Start scheduled snapshots' and names the exact resource: 'one existing in-memory keyspace.' This clearly distinguishes the tool from the sibling stop_snapshots and clean_snapshots tools, so an agent can tell what this tool does without opening other definitions.

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

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

The description gives clear context about when this tool is applicable: it starts scheduled snapshots for an existing in-memory keyspace. It also provides an important exclusion ('cannot alter the global snapshot rate') and explains how to interpret a 'Snapshot rate is not set' response. However, it does not explicitly name alternatives or state when to prefer a sibling 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?

The annotations only declare readOnlyHint, destructiveHint, and idempotentHint as false, so they provide little safety context. The description adds meaningful behavioral detail: existing snapshot files are retained, the final authorization check is performed by Montycat, and the action applies to exactly one existing in-memory keyspace. This clarifies non-destructiveness and preconditions beyond what annotations alone convey.

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

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

The description is compact and well ordered. The first sentence states the core purpose, the second paragraph provides two important side-effect/context facts, and the Args section clearly ties the parameter to its role. 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 tool with one simple parameter and no output schema, the description covers the main action, the key side-effect, and an important precondition. It does not mention error cases or explicitly reference how to resume snapshots, but the core operation is adequately specified 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 0%, and the schema only names the required parameter as 'Keyspace'. The description compensates by explaining that keyspace must be an explicit, existing in-memory keyspace whose snapshot schedule stops. This adds real semantic meaning and reduces ambiguity about what value to provide.

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

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

The description opens with a specific verb and resource: 'Stop scheduled snapshots' for an explicit in-memory keyspace. It clearly distinguishes the operation from siblings like montycat_start_snapshots and montycat_clean_snapshots by focusing on stopping a schedule rather than creating, cleaning, or managing snapshot content.

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

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

The description gives no explicit guidance about when to use this tool versus its siblings. It does not mention montycat_start_snapshots as the counterpart for resuming snapshots, nor does it state any conditions or exclusions. The only implicit signal is the word 'existing', which weakly implies a prerequisite.

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

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

Annotations only signal a non-read operation; the description adds meaningful behavior: partial in-place mutation, mutability of memories, and wait_for_index behavior. It does not discuss side effects or old-value handling, but it goes beyond annotations.

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

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

Purpose and usage guidance are front-loaded before the parameter list. Every sentence carries useful information, and the Args block is compact, readable, and free of 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 7-parameter mutation tool with no output schema and sparse annotations, the description covers the main flow well but omits scope and vector, and does not specify behavior when both or neither key and custom_key are provided. Adequate but not fully complete.

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

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

The schema has no documentation, so the description compensates by explaining updates with concrete examples, defining key and custom_key as record identifiers, and clarifying wait_for_index defaults. However, the scope and vector parameters are not explained at all.

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

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

The description opens with a specific action: 'Revise an existing memory in place' and immediately clarifies memory is mutable. It also distinguishes itself from storing a duplicate, which separates it from montycat_remember and montycat_forget without ambiguity.

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 when to use the tool: when a stored fact changes, such as a corrected value or updated preference, rather than storing a duplicate. It also clarifies that only passed fields are changed, preventing accidental overwrites.

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