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

The description adds meaningful context beyond the annotations (idempotentHint=false, destructiveHint=false): atomic wrapping, per-insert fsync savings, per-item partial success where invalid items are reported but valid items still commit, and 2000-char content truncation in the echoed response with a pointer to getMemory. That is rich disclosure. However, the interaction between 'atomic' and 'valid items are still stored' is ambiguous, and it doesn't state duplicate-memoryId behavior despite declaring non-idempotency.

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

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

Front-loaded with purpose, then WHEN/WITHOUT/NOTE blocks that make scanning easy. Minor redundancy: 'Significantly faster than calling storeMemory repeatedly' and 'Reduces overhead from per-insert fsync' say the same thing twice.

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 carries the return-value burden and does so: per-item error reporting, warningCodes semantics, and content truncation with a recovery path via getMemory. Nothing essential for correct invocation is missing.

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

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

Schema description coverage is 100% and the primary parameter additionally carries its own inline description with required fields and warningCodes. The prose mostly restates that structure and points to storeMemory's schema, so this is the baseline case where 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?

States a specific verb and resource ('Persist multiple memory units in a single atomic SQLite transaction') and immediately scopes it against siblings: not storeMemory for singles, not importMemories for file imports. An agent can pick this over the 14 siblings 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?

Has explicit WHEN TO CALL (session end, 10-20 memories at once) and WHEN NOT TO CALL sections that name the two alternative tools and the condition selecting each. 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?

Discloses it is read-only with no side effects, and returns memories ranked by relevance. No annotations provided, so description fully informs 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?

Three concise paragraphs, front-loaded with purpose, then usage, then parameter detail. No unnecessary 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?

Given one parameter, no output schema, and moderate complexity, description fully covers purpose, usage, and parameter meaning.

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 covers parameter with description, and description adds examples of query values. Since schema coverage is 100%, baseline is 3; the added examples justify a 4.

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?

Clearly states it is a fallback memory retrieval for hosts without MCP resource support, returns memories ranked by relevance, and distinguishes from siblings like retrieveMemories and the resource URI.

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 specifies when to call (session start, mid-session when host lacks resource support) and when not to call (host supports resources, instead use URI or retrieveMemories).

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 (destructiveHint=true), description adds details: deletion from local SQLite store, immediate, irreversible, and unrecoverable, providing full 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?

Concise with a main sentence plus structured WHEN TO CALL/WHEN NOT TO CALL sections. Every sentence adds value; no 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?

Given one required parameter, no output schema, and simple functionality, the description covers purpose, usage guidelines, and behavioral transparency completely.

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 already describes memoryId in detail (UUID, obtain from prior calls, immediate deletion). Description adds no new parameter info beyond the schema, so baseline score of 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?

The description clearly states the action (permanently delete) and the resource (a single memory by ID), distinguishing it from siblings like batchStoreMemory or storeMemory. The 'WHEN TO CALL' and 'WHEN NOT TO CALL' sections further clarify scope.

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 provides when (memory incorrect/dangerously outdated/duplicate) and when not to call (doubt, merely old/low-relevance), with clear alternatives 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?

Annotations already declare readOnlyHint and idempotentHint, and the description's 'Read-only; no side effects' reinforces rather than contradicts them. It adds genuine value beyond the annotations by enumerating the returned payload (content, kind, importance, timestamps, session metadata), which matters because there is no output schema.

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

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

Front-loaded with the core action and return shape, then a clearly labeled WHEN TO CALL section, then a short alternative hint. No sentence is redundant and length is proportionate to a one-parameter read tool.

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?

Because there is no output schema, the description usefully lists returned fields and covers the exact-ID prerequisite. It stops short of stating behavior on a missing/invalid ID (empty result vs error), which is the one remaining gap for an agent calling with a stale ID.

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 memoryId parameter is already documented with its origin sources. The description restates the 'exact ID' constraint without adding format, length, or failure-mode detail the schema lacks, 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 and resource ('Fetch a single memory record by its exact ID') and immediately distinguishes itself from the search/timeline siblings by requiring an exact ID. The returned fields are enumerated, so the agent knows precisely what it gets back.

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 WHEN TO CALL block is explicit: call after searchMemoryIndex or memoryTimeline to hydrate selected IDs, and it names retrieveMemories and listMemories as additional ID sources. It also gives an exclusion — for topic searches start with searchMemoryIndex instead — so the routing decision is unambiguous.

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

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

Annotations already declare idempotentHint and destructiveHint=false, but the description adds real value beyond them: the idempotency mechanism (upsert by sessionId), the existence of a retention prune of stale memories, threshold-gated summarization, and the four possible status outcomes plus warningCodes for cloud/local fallback. It does not detail what the prune actually removes or what permissions/keys cloud summarization requires.

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?

Well front-loaded: one-sentence pipeline summary, then labeled WHEN TO CALL / WHEN NOT / parameter notes / response codes. Slightly padded by the repeated 'omit for sensible defaults' phrasing and some incidental detail, but nothing is genuinely 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?

No output schema, yet the description enumerates the status values and warningCodes, which is the main return-value need. The remaining gap is undocumented optional params (scope, workingDirectory, several config keys) that an agent could mis-set silently.

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% across 6 params including a nested config object, so the description must compensate. It explains sessionId, sourceAdapter, memoryId's default derivation, and three config fields — helpful — but leaves scope, workingDirectory, factMode, summaryTokenCap, redactionEnabled, and anthropicApiKey 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?

States a specific composite action (summarize ingested events into durable memory plus a light retention prune) and names the exact alternative (summarizeSessionToMemory) it differs from. An agent can distinguish it from siblings like ingestSessionEvents or storeMemory 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 WHEN TO CALL (once, at the very end, after ingestSessionEvents) and WHEN NOT TO CALL (mid-session, or when a summary already exists — use summarizeSessionToMemory instead). It even notes the Claude Code SessionEnd hook makes explicit invocation usually unnecessary, which is exactly the routing info an agent needs.

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

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

Goes well beyond the annotations by disclosing immediate single-transaction writes, idempotency keyed on the (project, session, eventIndex) UNIQUE index, and the 500-event cap. It is consistent with idempotentHint=true, but never mentions the replaceExisting parameter, which could change the no-op-on-reingest behavior an agent relies on.

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 does, then organizes when-to/when-not/limits into scannable blocks. Every sentence carries actionable information; nothing is filler.

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

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

With no output schema and no annotations covering safety beyond idempotency, the description covers transactionality, idempotent retry semantics, and batch limits thoroughly. The one material gap is the undocumented replaceExisting flag and scope, which affect how an agent should shape repeat calls.

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 documentation burden; it does explain the nested event fields (id, eventIndex, eventType, payloadJson) but omits createdAt, scope, workingDirectory and especially replaceExisting, whose effect on the idempotency guarantee is unstated. Useful but incomplete compensation.

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 ('Push raw session events ... to sessionmem') plus the downstream purpose (session-end summarization, token-savings analytics). It explicitly distinguishes itself from storeMemory, so an agent can tell ingestion of transient events from storing first-class memories 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?

Provides explicit WHEN TO CALL (periodically at task boundaries, or one batch before session end) and WHEN NOT TO CALL, naming storeMemory as the alternative for durable facts. It also gives operational guidance for oversized batches (chunk at 500, overlapping is safe).

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 idempotentHint=true; description confirms read-only with no side effects and warns the output can be very large, adding value 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?

The description is concise with a clear main sentence followed by structured usage guidelines (WHEN TO CALL, WHEN NOT TO CALL), front-loading essential information with 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 list tool without output schema, the description covers purpose, usage, and behavioral traits well. Minor gap: does not describe the return format, but given the simplicity and annotations, it is nearly 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%, and the description does not explain the 'limit' parameter or its effect, despite the parameter having constraints in the schema. The description should compensate for low schema coverage but fails to do so.

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 returns every memory unfiltered, and contrasts with retrieveMemories which ranks by relevance, making the purpose specific and distinguishable from 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?

Explicitly provides WHEN TO CALL (audit, detect duplicates, build full summary) and WHEN NOT TO CALL (session start; suggests retrieveMemories instead), with clear alternative named.

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

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

Goes well beyond the readOnly/idempotent annotations by disclosing that superseded history is included by default, that the default limit is 10 with a max of 50, and that the call does not bump access counters — a non-obvious side-effect distinction that matters for agents reasoning about memory usage stats.

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?

Six short sentences, zero filler, with the primary selection modes front-loaded and constraints (limits, defaults, counter behavior) trailing. Every sentence carries a distinct operational fact.

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?

Six optional parameters, no output schema, and no annotations beyond safety hints — the description covers modes, bounds, defaults, and history behavior, and notes output is 'compact' versus getMemory's full records. Only the undocumented `scope` parameter keeps it from being 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 0% schema description coverage, the description carries the burden well: it explains memoryId, fromDate/toDate (inclusive, UTC), limit (default 10, max 50), and includeHistory (superseded history included by default). The `scope` parameter is never mentioned anywhere, which is the one real 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?

Names a specific verb and resource (browse compact memories) with two precise selection modes: capture order around memoryId, or an inclusive UTC fromDate/toDate range. It also distinguishes itself from getMemory, which returns full details rather than compact entries.

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?

"Provide an ID or both dates" gives a clear admission condition, and "Use getMemory for full details" routes the agent to the right sibling for the expanded-record case. It does not position itself against listMemories, retrieveMemories, or searchMemoryIndex, so the sibling routing is only partial.

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

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

Annotations already provide destructiveHint=false and idempotentHint=true. The description adds context by detailing the exact state changes (setting counters to 0, clearing timestamps) and affirming no deletions. 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?

Description is clear and well-structured with separate sections for purpose and usage guidelines. Slightly verbose but efficient; could be trimmed without losing meaning.

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 simplicity (no params, no output schema), the description fully covers purpose, behavior, usage contexts, and side effects. Leaves no relevant 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?

With zero parameters and 100% schema coverage (empty schema), baseline is 4. The description compensates by explaining the action and its effects, adding value beyond the schema.

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

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

The description clearly states the tool resets access-pattern counters for all memories in the current project, specifying it sets access_count to 0 and clears timestamps without deletion. It distinguishes from siblings like forgetMemory or listMemories by focusing on counters rather than storage or retrieval.

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 provides 'WHEN TO CALL' and 'WHEN NOT TO CALL' sections, advising use after major refactors and against use during normal operation where self-correction occurs. This gives clear context and alternatives.

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

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

The opening claims 'Read-only; no side effects,' which directly contradicts the readOnlyHint=false annotation. Although a later NOTE admits that access-pattern counters are updated and the tool is not side-effect-free, the definition remains internally inconsistent in a way that could mislead an agent about 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?

The definition is front-loaded with purpose and organized into clear WHEN TO CALL / WHEN NOT TO CALL sections. It is somewhat long and repeats schema details, and the incorrect 'Read-only; no side effects' line is wasted and harmful, but the structure is otherwise 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 six-parameter retrieval tool with no output schema, it covers ranking, default result count, mode/depth usage, and alternatives well enough to call correctly. The side-effect contradiction prevents a higher score, but the schema fills in tag and includeHistory semantics.

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

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

Schema description coverage is 100%, so all six parameters are already documented in the input schema. The description largely restates mode, depth, query phrasing, and limit behavior, with no additional syntax or edge-case guidance beyond the schema.

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

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

The description states a specific verb and resource: semantically search stored memories and return top matches ranked by relevance, recency, and importance. It distinguishes itself from siblings by naming getMemory for memoryId lookups and listMemories for store auditing.

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 CALL triggers for session start and mid-session topic changes, plus WHEN NOT TO CALL conditions including avoiding repeated retrieval and not calling every user turn. It also routes specific cases to getMemory and listMemories.

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

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

Adds substantial behavioral context beyond the annotations: it describes return fields, default and maximum limit, that access counters are not updated, and how hasMore relates to the bounded candidate pool. Annotations already cover read-only and idempotent behavior, and the description complements them well.

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, information-dense, and free of filler. Each sentence adds practical value about workflow, return shape, limits, or side effects.

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?

It covers the search workflow, return shape, limit defaults, and hasMore semantics, which is useful for a tool without an output schema. However, for a six-parameter tool with no schema descriptions, it leaves key parameters like tags, scope, scopeMode, and includeHistory 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 description coverage is 0%, so the description must explain parameter meanings. It only clarifies limit (default 10, maximum 50) and implies query via "topic lookups"; tags, scope, scopeMode (filter vs boost), and includeHistory 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?

States a specific verb and resource: "Search a compact memory index." It also distinguishes the tool from memoryTimeline and getMemory by positioning it as the starting point for topic lookups and full-body retrieval.

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

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

Explicitly routes the agent: "Start here for topic lookups, use memoryTimeline for nearby context, then getMemory for selected full bodies." This gives clear when-to-use guidance and names the relevant alternatives.

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

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

No annotations provided, so description carries full burden. Discloses that access counts are incremented on retrieval and that it is a fallback. However, does not detail criteria for 'top relevant memories' or side effects if called multiple times.

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 concise paragraphs with clear structure, including a 'WHEN TO CALL' note. No redundant 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?

Given no output schema and no annotations, description covers purpose, usage, and a behavioral note. Could mention behavior when no relevant memories exist or if called multiple times, but overall adequate.

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?

No parameters, so baseline 4. Description adds context about the injection purpose but no need for parameter details.

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?

Description clearly states it's a fallback to inject memories when host doesn't support MCP prompts. It specifies the action (injects top relevant memories for current project) and distinguishes from siblings like 'retrieveMemories' or 'fetch_memories' by explaining it's a session start injection.

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 (once per session start, when host lacks prompt support) and when not to call (if host already surfaces sessionmem startup prompt). Provides alternative guidance (rely on automatic prompt) to avoid duplication.

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 provide readOnlyHint and idempotentHint. Description adds the specific statistics returned and reaffirms no side effects. Valuable context but not essential 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?

Three well-structured sentences: purpose, when to call, when not to call. No redundancy, every sentence adds value.

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

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

Complete for a simple parameterless tool with no output schema. Covers purpose, usage guidelines, and differentiates from siblings.

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?

No parameters exist, so description adds no param info. Baseline is 4; description is clear about what the tool does without needing to reference parameters.

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 specifies the exact resource and action: returning aggregate statistics (total stored memory count and total ingested session event count) for the current project. It clearly distinguishes from sibling tools like retrieveMemories.

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 (diagnostic/monitoring) and when not to call (not for normal context loading), with an alternative tool suggested.

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 carry idempotentHint=false and destructiveHint=false; the description adds material context beyond them — immediate disk writes, the non-idempotent duplicate-record behavior, redaction behavior, and the meaning of advisory warningCodes. Nothing contradicts the annotations.

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

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

Front-loaded with the core operation, then cleanly partitioned into WHEN TO CALL / WHEN NOT TO CALL / parameter notes / response notes. Despite its length, each block carries distinct, 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 9-parameter mutation tool with no output schema, the description covers invocation context, behavioral caveats, and return-signal semantics (warningCodes). An agent has everything needed to call it correctly and interpret the response.

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 9 parameters. The description's notes on kind categories and importance's effect on retrieval ranking largely restate the schema rather than adding syntax or format detail, 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 and resource ('Persist a single memory unit to the local SQLite store') and immediately scopes it as single-unit, which distinguishes it from the sibling batchStoreMemory. An agent can identify the operation without opening the schema.

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

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

Explicit WHEN TO CALL and WHEN NOT TO CALL sections with concrete examples (technology choices, bug root-causes vs. trivial observations, transcripts). It also routes to the alternative (batchStoreMemory) inside the write-limit warning, giving a clear switch condition.

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 idempotentHint=true and destructiveHint=false, and the description usefully explains *why*: upserting on memoryId replaces the prior summary instead of duplicating, so an agent understands the overwrite behavior. It does not cover auth requirements, size/retention limits, or what a successful call returns, 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?

Front-loaded with the core action and upsert semantics, then organized into WHEN TO CALL / WHEN NOT TO CALL / Provide blocks. Slightly list-heavy for the payload, but nearly every line carries decision-relevant information rather than restating the schema.

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

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

With no output schema and no annotation coverage of returns, the description still gives an agent everything needed to invoke it correctly: purpose, routing, idempotency behavior, and key parameter meanings. Only the response shape and the meaning of scope/workingDirectory are 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 coverage is 0%, so the description must carry the load, and it does for five of seven parameters — notably defining memoryId as a stable per-session id and giving a practical anchor for importance (1-10; 7 is typical). scope and workingDirectory are left entirely unexplained, so it does not fully compensate.

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 action and resource: storing an agent-authored session summary as a durable 'summary' memory, and explicitly frames it as the one-call, caller-written counterpart to summarization. The upsert-on-memoryId clause further pins down the semantics so it is distinguishable from storeMemory and handleSessionEnd.

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?

Has explicit WHEN TO CALL and WHEN NOT TO CALL blocks naming the alternatives (handleSessionEnd for generated summaries, storeMemory for non-summary facts). The selection condition between the two paths is stated plainly rather than inferred.

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