AgentRecall

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

No annotations are provided, so the description carries the burden. It explains the return format (corrections/rules/insights plus a verdict) and the critical meaning of 'blocked' (authoritative correction overrides the plan). This goes beyond the schema by explaining behavioral semantics, though it omits mention of any recording/persistence side effects.

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 informative but a bit dense, with multiple clauses and parentheticals. It is still well-structured, front-loads the most important usage, and each sentence adds value (usage, pre-action trigger, return semantics). Minor trimming could improve readability.

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

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

For a tool with 13 optional parameters and no output schema, the description provides crucial context: when to invoke, what to pass for risky actions, and how to interpret the response. It could be more complete by explaining decision trail persistence, but the essential information is 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 coverage is 92%, so the baseline is 3. The description adds meaningful guidance for `action_description` (one sentence, what you're about to do) and mentions `goal` implicitly, but most other parameters are only documented in the schema. This is adequate but not exceptional.

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 specifies the tool's purpose: validate understanding, verify alignment, and check interpretation against human intent. It also names a distinct second purpose (pre-action safety check before irreversible writes), which differentiates it from sibling tools like remember/recall.

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

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

The description gives explicit when-to-use scenarios (user asks for alignment, before high-risk actions) and even lists example actions (publish, deploy, delete). It does not explicitly state when not to use the tool or name alternatives, but the context is sufficiently 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 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.