mcp-light-memory

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

Annotations already declare the safety profile (readOnly=false, destructive=false, openWorld=false), and the description adds the local-write scope, confirms no durable-memory deletion, and states no network access. It does not clarify whether checkpoints overwrite prior state or how the non-idempotent behavior manifests, so it is strong but not fully exhaustive.

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

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

Two sentences, front-loaded with the core action, then usage and behavioral caveats. Every clause earns its place with no redundancy.

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

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

With no output schema, the description adequately covers when to call it, what state it writes, and what it does not touch, which is sufficient for a checkpoint write. It could be slightly more complete on resume interaction with the sibling 'resume' tool.

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

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

Schema description coverage is 100%, so all six parameters (reason, next, phase, blockers, completed, in_progress) are already documented in the schema. The description adds no parameter-level detail beyond what the structured fields provide, making the baseline 3 appropriate.

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

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

States a specific verb and resource ('Persist current operational task state') with the added purpose of resuming after interruption or context loss. It explicitly distinguishes itself from the sibling 'remember' by noting that tool is for reusable knowledge, so an agent can tell them apart without opening schemas.

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

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

Gives explicit when-to-use guidance ('at meaningful milestones and before ending a work session') and names the alternative ('use remember for reusable knowledge') with the condition that selects it. Nothing is left to inference about timing or 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 declare readOnlyHint=false, idempotentHint=false, openWorldHint=false, and destructiveHint=false, so part of the description ('non-idempotent', 'no network access') restates structured data. It does add value beyond them by disclosing what state is touched ('may update task or usage state') and a non-obvious negative guarantee ('does not delete durable memories').

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

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

Two sentences, no waste, with the core action front-loaded and usage/behavioral caveats packed into the second sentence. Every clause carries information.

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

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

For a 2-parameter, non-destructive mutation with full annotation coverage and no output schema, the description covers trigger, alternative, state mutation, idempotency, and network behavior. It stops short of describing what the returned 'context packet' contains, a minor gap given no output schema is declared.

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 'task' and 'limit' are already documented in the schema. The description adds no syntax, format, or defaulting detail 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 a specific verb ('Start or resume a task') and resource ('durable project memories and current working state'), and explicitly routes the focused-lookup case to the sibling 'search'. An agent can distinguish it from search, resume, and checkpoint 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 concrete triggers ('before project changes or after a context reset') and names the alternative tool and the condition that selects it ('use search for a focused lookup'). Nothing about when-to-use is left to inference.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, and the description largely restates these facts ('read-only and idempotent', 'no network access'). It adds only marginal new context via 'does not modify memory or task state', which is implied by readOnlyHint. With annotations carrying the safety profile, this is adequate but adds little.

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

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

Three short sentences, with the core purpose and the usage trigger front-loaded before the safety caveat. The final sentence is largely redundant with the annotations, which slightly dilutes the otherwise tight structure.

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

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

For a zero-parameter, read-only check with an output schema present, the description covers purpose, when to call it, what to do with the result, and the safety profile. Return-value semantics are left to the output schema, which is appropriate.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline of 4 applies. No parameter-related claims are made or needed.

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

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

States a specific verb (check) and resource (whether project state changed since the last checkpoint), which is a distinct operation from the sibling 'checkpoint'. The name 'guard' is opaque on its own, but the description resolves it immediately.

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

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

Explicitly names the trigger ('Use before finishing a task to detect uncheckpointed work') and the conditional follow-up action ('then checkpoint if stale'), routing the agent to the sibling tool under a stated condition. Nothing is left to inference.

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

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

The description's behavioral claims ('does not delete existing memories', 'performs no network access') largely restate destructiveHint=false and openWorldHint=false from the annotations, and it adds the useful locality framing of 'local durable memory'. It does not disclose what the annotations cannot: whether repeated calls with identical content create duplicates (idempotentHint=false implies they do) or what the write returns. With annotations already carrying the safety profile, this is adequate but adds limited new 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?

Three short sentences, front-loaded with purpose, then usage routing, then behavioral constraints. No filler or repetition; every clause carries information.

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

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

For an 8-parameter write tool with full schema coverage, no output schema, and annotations present, the description covers purpose, usage routing, and side-effect profile. The only gap is duplicate/return behavior on a non-idempotent write, which is minor.

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

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

Schema description coverage is 100% with per-field descriptions and enum values, so the schema does the heavy lifting. The description's list of knowledge kinds loosely maps to the type enum but adds no format, syntax, or selection guidance beyond it. 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?

Specific verb+resource (store durable project knowledge that survives across sessions) with the durable/temporary distinction made explicit against the checkpoint sibling. An agent can tell immediately what this tool produces and how it differs from checkpoint 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?

States exactly when to use it (stable decisions, constraints, gotchas, failures, hypotheses, reusable knowledge) and names the alternative with its own condition (checkpoint for temporary task progress). Nothing is left to inference.

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

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

Annotations already declare readOnlyHint=false and idempotentHint=false, but the description adds genuinely new context: it removes an entry from a stack (pop semantics), leaves durable memories intact, and performs no network access. The non-destructive clarification is valuable since 'remove' could otherwise read as data loss, though it restates non-idempotency already in 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?

Two sentences, both front-loaded: the operation first, then routing guidance and behavioral guarantees. No filler, and every clause carries information an agent needs.

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

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

For a zero-param mutation with no output schema, the description covers the operation, the routing decision, state side effects, and network behavior. The only gap is what 'resume' returns (the resumed task content), which an agent might reasonably want to know, but annotations and description together are otherwise 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. No parameter-related claims are needed or missing.

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 precise verb pair and resource: 'Resume and remove the top saved task from the task stack.' This distinguishes it from sibling 'tasks' (inspect) and from 'checkpoint'/'remember' by naming the exact stack operation performed.

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

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

Explicitly names the precondition ('Use after tasks shows resumable work') and the alternative ('use tasks when you only need to inspect the stack'). Both when-to-use and when-not-to-use are covered with the sibling 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?

Annotations already declare readOnly/destructive/openWorld/idempotent hints, but the description goes further by explaining the reason for the non-idempotent hint (repeated calls may update retrieval or usage metadata) and clarifying that durable memory content and the task stack are not altered. The no-network-access statement also adds context beyond the openWorldHint.

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

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

Three sentences, each load-bearing: purpose/output first, routing guidance second, behavioral caveats third. No repetition of schema content and 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?

With an output schema present, the description need not explain return values, and it still flags that results carry confidence and abstention metadata. Combined with full schema coverage and annotations, an agent has everything needed to call it correctly.

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

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

Schema description coverage is 100%, so all six parameters are already documented in the schema. The description adds no syntax, format, or interaction details for query, types, statuses, at, limit, or explain, 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 ('search durable project memories') plus the output character ('ranked results with confidence and abstention metadata'). It explicitly contrasts itself with the sibling 'context' tool, so an agent can route between them without opening either schema.

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

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

Gives an explicit when ('focused fact retrieval without starting a task') and a when-not with the named alternative ('use context when beginning or resuming work'). Nothing about tool selection is left to inference.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, and the description largely restates these (read-only, idempotent, no state modification, no network access). It adds no information beyond the structured hints, but it also contradicts nothing, so a 3 is appropriate.

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 and scope, followed by usage and safety context. No filler and nothing repeated needlessly.

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 operation is parameterless, an output schema exists to describe the return shape, and annotations cover the safety profile; nothing an agent needs in order to call this correctly is missing.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; per the rubric, a 0-parameter tool has a 4 baseline. The description correctly avoids inventing inputs.

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 (Return) and enumerates the exact resources covered (memory, checkpoint, index, recovery status for the current project), which is well beyond a restatement of the name "status". It stops short of explicitly distinguishing itself from the operational siblings like resume or checkpoint, so it lands just under a 5.

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

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

"Use for diagnostics and health checks" gives a clear context for invoking it, implicitly steering the agent away from action-oriented siblings such as remember or resume. There are no explicit when-not conditions or named alternatives, which keeps it from 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, idempotentHint, and destructiveHint=false, so the description's 'read-only and idempotent, does not modify task state' largely restates structured data rather than adding new behavior. 'Performs no network access' is a marginal addition but is already implied by openWorldHint=false.

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

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

Front-loads the purpose in the first sentence and stays to three short sentences, though the safety restatement ('read-only and idempotent, does not modify task state') is somewhat redundant with annotations and could be trimmed.

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 an output schema present, the description need not explain return values, and it covers purpose, timing, and the safe-read nature adequately for a zero-parameter read 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 tool takes zero parameters, so the baseline is 4; there is no parameter semantics to document, and the description correctly says nothing about inputs.

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 ('List the current task stack and resumable task state') that an agent can distinguish from sibling tools like resume or status without opening a schema.

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

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

Gives clear timing guidance ('Use before resume when you need to inspect pending work') and implicitly contrasts with resume by noting it leaves the stack unchanged, but does not explicitly name alternatives or when-not-to-use conditions beyond that.

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