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

No annotations are provided, so the description carries the full disclosure burden. It does reveal that 'process' saves (mutation) and that 'flush' is an emergency capture skipping dedup with a lower threshold, but says nothing about what gets overwritten, idempotency, or permission requirements for a write-capable tool.

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

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

Two tight sentences, action semantics front-loaded before the usage note. Minor redundancy with the action enum descriptions, but no filler or preamble.

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

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

For a mutation-capable tool with no annotations and no output schema, the description covers triggers and the two key actions but omits what the caller gets back and the safety profile. Adequate as a minimum viable entry point, with clear gaps.

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

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

Schema coverage is 100%, so all five parameters including the action enum are already documented in the schema, and the description's enum glosses largely restate it. Baseline 3 applies; the description adds little parameter meaning beyond the schema.

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

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

States a specific verb+resource: auto-extract memories from text, and sketches the two most consequential actions ('process'=analyze+save, 'flush'=emergency capture). It does not differentiate itself from close siblings like nmem_remember or nmem_remember_batch, so the agent cannot fully tell which entry point to prefer.

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

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

Gives concrete context: 'Use at session end or when processing large text blocks,' and ties 'flush' to the pre-compaction emergency case. It offers no explicit exclusions (e.g., when to fall back to nmem_remember instead), so the routing is implied rather than closed.

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

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

No annotations are provided, so the description carries the full behavioral burden. 'Get' plus 'auto-injected context' implies a read-only, non-mutating operation and hints that the content feeds automatic injection, but it says nothing about ordering, freshness defaults, or what happens when the token budget is exceeded. The richer behavioral details (token stripping, compact mode, ghost memories, expiry warnings) live only in the parameter descriptions, not the tool description.

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

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

Three short sentences, zero filler, and the core scoping statement is front-loaded ahead of the alternative routing. 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 six-parameter read tool with no output schema and no annotations, the description plus the rich parameter descriptions cover enough to invoke it correctly. The only remaining gap is the shape of the returned context, which is partly compensated by parameters like compact, token_budget, and warn_expiry_days that describe response behavior.

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

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

Schema description coverage is 100% and all six parameters carry clear, substantive descriptions (defaults, ranges, and effects like 'strip metadata hints' or 'calls_expiry_warnings'). The tool description adds no parameter-level meaning at all, so the baseline 3 for full schema coverage is correct.

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

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

States a specific verb and resource ('Get recent memories') and immediately frames the output as 'auto-injected context', which tells the agent what kind of payload to expect. It explicitly distinguishes itself from two siblings (nmem_recall, nmem_recap), so the agent can select it without opening any other schema.

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

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

Gives an explicit use case ('broad task context') and routes two alternatives by condition: specific queries to nmem_recall, project-level context to nmem_recap. This is a clean when-to-use / which-alternative mapping with nothing left to inference.

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

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

No annotations are provided, so the description must carry the full behavioral burden. It mentions persistence across sessions, which is a key behavioral trait, but doesn't describe whether saving is reversible, what permissions are required, or what happens to existing memories when new ones are added. For a mutation tool with zero annotation coverage, this is a notable gap.

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

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

Two concise sentences that are front-loaded with the core action and purpose. Every sentence adds value without 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 complexity (8 parameters, mutation operation, no annotations, no output schema), the description covers the basic purpose and a key usage distinction, but leaves significant gaps regarding behavioral traits like reversibility, permissions, and interaction with existing memories. It is adequate but not complete for a tool of this 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?

Schema description coverage is 100%, so the schema already documents all 8 parameters thoroughly. The description doesn't add any parameter-specific meaning beyond what the schema provides. Baseline 3 is appropriate when the schema does all the heavy lifting.

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

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

The description clearly states the verb and resource: it SAVES project context, decisions, and instructions that persist across sessions. It distinguishes itself somewhat from siblings by scoping to project-level facts rather than task-specific memories, which helps differentiate it from nmem_remember.

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 to use for project-level facts, not task-specific memories, and pairs it with nmem_recap for loading. It doesn't name all relevant alternatives like nmem_remember, but the primary when-to-use condition is clear.

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

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

With no annotations, the description carries the full behavioral burden. It discloses the retrieval mechanism (spreading activation) and the depth ladder, but says nothing about cost (token budgets, compact default), the read-only nature, or what the response looks like. The depth explanation largely duplicates the schema rather than adding 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?

Five short, front-loaded sentences with the core purpose first and the sibling redirect last; nothing is padded. The depth enumeration is the only segment that restates structured data rather than adding new 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 30-parameter tool with no output schema and no annotations, the description is thin: it never mentions the rich filter surface (tier, as_of, valence, trust/arousal thresholds) or the shape of what comes back, even though the absent output schema means the description could reasonably carry some of that. The schema's 100% coverage keeps this from being inadequate, but it is only minimally sufficient.

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 30 parameters are already documented in the schema, and the description's depth ladder repeats what the schema's depth property already says. It adds no syntax, defaults, or interactions beyond the structured fields, 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 ('Query memories') and the mechanism ('spreading activation'), then explicitly distinguishes itself from the sibling nmem_context for broad recent context. An agent can pick this tool over its 9 siblings 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?

Gives an explicit trigger ('when you need past context, decisions, or knowledge'), a refinement hint ('Add tags for precision'), and names the alternative tool with the condition that selects it ('Use nmem_context instead for broad recent context'). This is when-to-use plus when-to-use-something-else.

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

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

No annotations exist, so the description carries the full behavioral burden. It usefully discloses per-level token costs and that it restores cross-session state, but never states read-only semantics, what happens when no saved context exists, or whether the level/token_budget interplay can drop content.

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

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

Three short sentences, imperative verb front-loaded, and the highest-value instruction (session-start trigger) immediately follows the purpose. 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?

Covers purpose, timing, and the primary level parameter for a 4-parameter tool with no output schema and no annotations. It is slightly thin on the interaction between level, compact, and token_budget and on the empty-context case, but the essentials for correct invocation are present.

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

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

Schema description coverage is 100%, so each parameter (level, topic, compact, token_budget) is already documented in the schema, including level's token estimates. The description's level restatement adds nothing beyond that, so the baseline 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?

States a specific verb+resource ('LOAD project context') and names the upstream writer (nmem_eternal), so an agent can tell it restores rather than saves. However, it does not distinguish itself from close siblings like nmem_recall, nmem_context, or nmem_situation, all of which plausibly read stored state.

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

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

Gives an explicit trigger: 'Call at SESSION START to restore cross-session state.' That is a clear when-to-use condition. It stops short of naming alternatives or exclusions (e.g., when to prefer nmem_recall or nmem_context instead), so it lacks the full when/when-not guidance a 5 requires.

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

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

No annotations are provided, so the description carries the full disclosure burden. It usefully reveals automatic behaviors (type auto-detection, automatic contradiction resolution creating a RESOLVED_BY synapse), but says nothing about idempotency, dedup, permissions, or what a call returns.

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

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

Three short sentences, front-loaded with the core action, then behavior, then usage. Every clause earns its place with no redundancy or 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 an 18-parameter mutation tool with no annotations and no output schema, the description covers intent and routing well but omits the return shape (e.g., fiber_id) and mutations side-effects, leaving the agent to infer output from parameter docs like 'compact'.

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% across 18 parameters, so the schema already documents tier, domain, trust_score, validity windows, encryption, etc. The description only echoes 'ephemeral' and the auto-detected 'type' without adding syntax or defaults beyond the schema, so the baseline of 3 applies.

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

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

States a specific verb and resource ('Store a memory') and adds distinguishing behaviors (auto-detects type, auto-resolves contradicted errors via RESOLVED_BY synapse). It names the sibling it is not for project context (nmem_eternal), though it does not distinguish itself from nmem_remember_batch.

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

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

Gives explicit triggering conditions ('after completing a task, fixing a bug, or making a decision') and explicit exclusions with remedies ('temporary notes -> ephemeral=true', 'project context -> nmem_eternal'). Clear when/when-not guidance; the batch sibling is not addressed.

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

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

With no annotations, the description carries the full behavioral burden and delivers a genuinely non-obvious trait: partial success, where one bad item won't block the rest. It also notes the max-20 cap, though it says nothing about persistence, permissions, or response shape.

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 compact sentences, each carrying a distinct fact (scope, threshold, failure mode), with the core capability front-loaded. No filler.

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

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

For a batch write tool with no annotations and no output schema, the description covers purpose, when-to-use, and failure semantics well. It lacks any mention of what a successful call returns or its persistence guarantees, which would round out the picture.

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

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

Schema coverage is 100%, so all three top-level parameters and nested memory fields are documented in the schema itself. The description's 'max 20' merely repeats maxItems already present, adding no new parameter meaning. Baseline 3 is correct.

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

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

States a specific verb and resource ('Store multiple memories at once') plus a hard constraint (max 20). The plural scope implicitly contrasts with the singular nmem_remember sibling, though it never names it.

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

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

Gives an explicit trigger condition: 'Use when saving 3+ memories together.' This routes the agent away from the single-item tool, but it does not name nmem_remember directly nor state when to prefer it explicitly.

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

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

With no annotations, the description carries the full behavioral burden; it does disclose the important scope trait that state lives only for the current session and is not persisted across sessions. However, it says nothing about mutation semantics — whether 'set' replaces or merges existing state, or whether 'end' destroys it — which matters for a stateful tool.

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

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

Three short sentences, zero waste, with the core purpose front-loaded ahead of the scoping caveat and the alternative routing. Nothing needs to be trimmed and nothing is buried.

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

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

For a 7-parameter stateful tool with no annotations and no output schema, the description covers scope and routing but omits what a call actually returns (e.g., what 'get' yields, what 'end' reports) and the interaction between compact/token_budget and the response. Adequate but with real gaps given there is no output schema to lean on.

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 seven parameters (including action enums and token_budget/compact behavior) are already documented in the schema, making 3 the correct baseline. The description's parenthetical '(task, feature, progress)' merely echoes a subset of fields and adds no syntax or format detail beyond the schema.

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

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

The description states a specific verb+resource ('Track current session state') and immediately scopes it with the listed fields (task, feature, progress). It also distinguishes itself from the sibling nmem_eternal by naming what it is not (cross-session persistence), so an agent can pick it without opening either schema.

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

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

It gives an explicit when-not ('Single-session only') paired with a named alternative ('For cross-session persistence use nmem_eternal'), which is exactly the routing signal an agent needs against a crowded sibling set. The condition that selects the alternative is stated, not inferred.

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

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

With no annotations, the description carries the full burden and does disclose the safety profile ('Pure read — never mutates state') plus the bounded output shape (top 3 decisions, active task, blockers). It stops short of explaining what 'gap detection' actually surfaces or whether results are scoped to a session/user, which would be useful for a read tool with 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?

Two tightly packed sentences with zero filler; the content enumeration is front-loaded and the behavioral guarantee comes last as a natural closing caveat.

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

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

For a read-only snapshot tool with no output schema, the description adequately covers what is returned, how it relates to sibling tools, and its non-mutating nature. Minor gaps remain around the semantics of 'gap detection' and result scoping, but nothing blocks correct invocation.

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

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

Schema description coverage is 100%, so both parameters (compact, token_budget) are already documented with their token-saving behavior. The description adds no parameter-level detail beyond that, so the baseline 3 applies.

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

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

States a specific verb+resource ('one-shot snapshot of the current working situation') and enumerates exactly what it returns: active session task, top 3 recent decisions, open blockers, gap detection. It explicitly distinguishes itself from siblings nmem_recap and nmem_recall, so an agent can route correctly 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?

Names the alternatives it supersedes (nmem_recap + multiple nmem_recall calls) and the condition that selects it ('when resuming a session'). It is a clear when-to-use with alternatives, but omits any when-not guidance (e.g. for narrow single-topic lookups where nmem_recall is cheaper).

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

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

With no annotations present, the description carries the full burden, and it does disclose the key behavioral trait: automatic 30-day expiration. It also names the disposal path (nmem_forget). It omits other relevant behavior such as what the call returns (an ID is presumably needed to later forget the item) and whether the write is idempotent.

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

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

Two short sentences with no filler; the defining trait (quick, auto-expiring) is front-loaded before the disposal instruction. Every clause earns its place.

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

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

For a single-required-parameter write tool with no output schema and no annotations, the description covers lifetime and teardown adequately. It falls short on the return/identifier behavior needed to actually invoke nmem_forget later, and on how it differs from the other memory-writing 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?

Schema description coverage is 100%, so task, compact, priority, and token_budget are all already documented in the schema, including the 0-10 range and default. The description adds no parameter-level meaning beyond that, so the baseline of 3 applies.

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

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

States the resource ('TODO memory') and its transient nature ('auto-expires in 30 days'), which implicitly distinguishes it from the persistent siblings nmem_eternal and nmem_remember. However, it never uses an explicit verb like 'create' or 'store', so the write action must be inferred from the required 'task' parameter. Clear but no direct sibling 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?

Gives one lifecycle instruction — 'Use nmem_forget to close when done' — which tells the agent how to dispose of the item. It does not say when to prefer nmem_todo over nmem_remember or nmem_eternal (e.g., 'for short-lived tasks only'), so the selection guidance against alternatives is left to inference from the 30-day expiry.

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