AgentRecall

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

No annotations are provided, so the description carries the full burden and does so well: it explains that `verdict: blocked` means an authoritative correction overrides the plan, and that a plain-string human_correction is only staged while the object form activates a durable rule. These are non-obvious operational consequences that an agent cannot infer from the schema alone. It omits any statement of side effects of the decision-trail mode or error behavior.

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

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

Front-loaded with a bracketed timing tag ('MID-SESSION — safe any time') before the prose, so the agent gets the when first. It is dense and longer than most, and the action_description guidance partly repeats the schema text, but nearly every sentence carries actionable routing or semantics.

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 13-parameter tool with no annotations and no output schema, the description covers the alignment and pre-action modes thoroughly and describes the return payload (corrections/rules/insights plus verdict). However, the Bayesian decision-trail feature (prior/posterior/evidence/decision_id/confidence/assumptions/outcome) is essentially undocumented in the description, leaving a large chunk of the tool's surface explained only by the schema.

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 92%, so the schema already documents most parameters (baseline 3), but the description adds real value beyond it: it specifies that action_description should be one sentence of what you're about to DO, and draws the critical distinction between the string form (staged) and the structured {rule, why, applies_when} form (activated). That meaning is not fully conveyed by the schema's own descriptions.

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

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

The description states a specific verb ('check') against a concrete resource (alignment/understanding with human intent) and enumerates the situations that trigger it. It clearly distinguishes its role from the sibling memory tools by framing itself as a validation gate. The only blur is that it also silently carries correction-recording and decision-trail modes, which muddies the single-purpose framing.

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 trigger conditions: user asks to validate/verify understanding, and pre-action checks before publish/deploy/delete/credential/external-send. It even points at session_start's pending_corrections for resolving staged items. It stops short of stating when NOT to use this versus remember/recall, so it is clear-but-not-exhaustive.

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 of behavioral disclosure. It only states the tool's purpose and that it can be used freely. It does not mention side effects, authentication needs, rate limits, or any constraints beyond being a retrieval operation. This is insufficient for a tool with multiple parameters.

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

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

The description is extremely concise—a single line with a tag and purpose statement. It is front-loaded with the retrieval tag and immediately useful information. 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?

Despite having 5 parameters (1 required) and no output schema, the description provides no context about the feedback mechanism, the 'since' parameter, or the limit parameter. It does not explain the return format or behavior for complex queries. The description is too sparse for the tool's complexity.

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

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

The schema coverage is 80%, meaning most parameters have descriptions. The tool description adds no additional meaning beyond the schema; it only describes the overall purpose. Baseline for high coverage is 3, so no extra credit for parameter insights.

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's purpose: to recall, search, find, or look up previous memory, context, or decisions. It uses specific verbs and identifies it as a retrieval operation, distinguishing it from siblings like 'remember' (likely for storage). The tag '[RETRIEVE — use freely, any time]' reinforces its role.

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

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

The description provides explicit when-to-use guidance: 'Use when the user asks to recall, search, find, or look up previous memory, context, or decisions.' It also includes the tag 'use freely, any time,' implying no restrictions. However, it does not mention when not to use or explicitly name alternatives, though sibling tools suggest boundaries.

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 must disclose behavior itself. It does note it is a write and that 'saying it is not saving it,' which is a valuable behavioral insight. However, it omits details about side effects, persistence scope, or potential errors, relying on schema routing hints for additional context.

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

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

The description is a single front-loaded sentence with a parenthetical qualifier. It is concise, informative, and avoids redundancy, earning its place without unnecessary detail.

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

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

For a simple write tool with no output schema, the description and schema collectively cover the core invocation steps, including trigger phrases and routing. However, the undocumented project parameter and lack of confirmation/return behavior leave minor gaps.

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

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

The schema provides descriptions for content and context (67% coverage), with the context parameter richly documented through routing hints. The project parameter has no description and the tool description does not explain it, leaving a noticeable gap in parameter understanding.

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 explicitly identifies this as a MID-SESSION WRITE for a single fact or decision, and lists specific trigger phrases ('remember, store, note, save'). It distinguishes itself from likely read or session siblings by focusing on persistence of a specific item.

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

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

The description gives clear usage guidance with concrete triggers ('Use when the user asks to remember, store, note, or save a specific decision, fact, or insight.'). It does not provide when-not-to-use exclusions or alternatives, but the context is unambiguous for a write operation.

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 full burden. It discloses the critical behavioral trait 'nothing auto-saves; you must call this', which is vital for correct invocation. It also reveals the optional pipeline update capability. However, it does not describe idempotency or error conditions.

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 with no waste. The first sentence is an imperative warning that front-loads the most critical behavioral instruction. The second sentence concisely describes optional parameters. Every word earns its place.

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

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

No output schema, so description should cover return values or side effects. It mentions that the tool persists session state and optionally updates the pipeline narrative, but does not state what the tool returns (e.g., confirmation) or whether it fails silently. The description is adequate for a simple end-point but lacks full closure.

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 83%, so baseline is 3. The description adds minimal meaning beyond existing schema descriptions—it mentions that close_phase/open_phase update the 'project pipeline narrative spine', but the schema already explains their purpose. The extra context is helpful but not substantial enough to raise the score.

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 ends a session and must be called on save/exit. It lists specific triggers like 'save, checkpoint, summarize, end, retain, or persist' which distinguishes it from sibling tools like session_start (opposite) and check/recall/remember (retrieval-focused). The verb 'End' and resource 'Session' are precise.

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

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

The description explicitly states when to use the tool (when user asks to save/end/etc.) and mentions an optional feature (close_phase/open_phase) available in the same call. It does not include explicit when-not-to-use statements, but the context of session ending is clear given sibling names.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It reveals that the tool is an entry point and explains lite mode's ≤500-token briefing behavior, but it does not state what 'full' actually returns beyond schema hints, nor any side effects like session state resets. Some context is added, but gaps remain.

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 a single, dense paragraph with the critical instruction front-loaded in brackets. Every clause earns its place: entry order, trigger phrases, and lite mode trade-off. No fluff or repetition of schema fields.

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 session-start tool with no output schema, the description covers the essential context: when to call, what it does, and mode behavior. It lacks explicit mention of return value or project auto-selection, but the schema covers those parameters, and the lite/full distinction implies the output payload. Good enough for a tool with four optional params and no nested objects.

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?

Despite 75% schema description coverage, the description adds significant semantic value by explaining when to choose mode='lite' and tying it to recall(). The context and verbose parameters are left to the schema, but the mode guidance elevates the description above the baseline schema detail.

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

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

The description opens with '[ENTRY — call FIRST, before acting]', clearly identifying the tool as the session initialization entry point. It specifies exact user intents ('start, load, continue, resume, or open memory') and distinguishes it from siblings like recall and 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?

Explicitly instructs to call FIRST before acting, defines when to use it (user asks to start/load/continue/resume/open memory), and provides a concrete use case for mode='lite' in fresh conversations, even referencing recall() as an alternative for on-demand memory retrieval.

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