Palim

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

Annotations already declare readOnlyHint=false and destructiveHint=false, so the write-and-safe profile is covered structurally. The description adds nothing beyond that: it does not mention idempotency behavior, duplicate handling, persistence scope, or auth requirements, despite idempotentHint=false making duplicate-write behavior a real question.

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?

A single front-loaded sentence with zero filler and the write purpose stated immediately. It is efficient, though the brevity is partly what leaves the usage and behavioral gaps unaddressed.

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?

An output schema exists, so return values need no explanation, and 100% schema coverage plus annotations carry the structural weight. The description is adequate for invoking the tool correctly, with the only real gap being when-to-use routing among the many sibling save/checkpoint/search tools.

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 five parameters (content, type, tags, metadata, source_session_id) are already documented in the schema. The description names a few memory categories that partly mirror the type enum but adds no format, constraint, or interaction detail beyond the schema, making the baseline 3 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?

The description states a specific verb (Store) and resource (memory, fact, decision, preference), so the agent understands this is a write operation for persisting knowledge. It clearly contrasts in nature with read-oriented siblings like palim_search or palim_get_context, but never names an alternative explicitly, keeping it just short of 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?

The phrase 'for later retrieval' weakly implies the purpose, but there is no guidance on when to choose this tool over palim_save_context, palim_checkpoint, or palim_save_session, nor any stated exclusions or prerequisites. The agent must infer the routing decision entirely on its own.

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=true and destructiveHint=false. The description adds one behavioral detail consistent with those annotations — reusing the session_id updates a single row (upsert) — but says nothing about what gets overwritten, permission needs, or the effect of omitting session_id.

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, front-loaded sentences with no padding, so it is not verbose. But the brevity is under-specification rather than economical conciseness — the sentences carry usage timing while omitting the tool's purpose entirely.

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 16-parameter persistence tool with many siblings performing similar saves, the description omits what a checkpoint is, what the context field should contain beyond the bare schema hint, and how it relates to palim_resume/palim_save_context. Output-schema coverage excuses return-value explanation, but the write-side guidance is still thin.

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 schema already documents all 16 parameters, including the session_id reuse convention. The description's only parameter remark ('reuse claude-code-<client session id>') repeats what the schema already states, so it adds no meaning beyond structured fields. 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?

The description never states what the tool does — it only says when to call it ('after connecting AND again after each meaningful chunk of work'). An agent must infer from the name/title that this writes a checkpoint record. It does not distinguish the tool from its near-identical siblings palim_save_context, palim_save_session, or palim_add_memory.

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 concrete timing ('after connecting AND again after each meaningful chunk of work'), which is genuine when-to-use guidance. However, it names no alternatives and provides no when-not to use it, leaving the agent unable to choose between this and palim_save_context/palim_save_session.

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 destructiveHint=true and idempotentHint=true, so the safety profile is covered structurally. The description still adds the concrete consequence that the deletion is permanent and irreversible, which is useful context beyond the boolean hints.

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 with the action and scope front-loaded and the irreversibility warning immediately after. No filler or restatement of the name.

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?

An output schema exists, so return values need no explanation, and annotations carry the safety semantics. Only minor gaps remain, such as behavior when the ID does not exist or is already deleted.

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% and the single parameter's description ('ID of the memory to permanently delete') fully documents it. The tool description adds no syntax or format detail beyond what the schema already supplies, so 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 ('Permanently delete one stored memory by ID'), which is immediately actionable. It implicitly distinguishes from palim_delete_session via the 'memory' resource, but never names or contrasts the sibling explicitly.

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 user-requested cleanup or deletion' gives a clear triggering context, and 'this cannot be undone' warns against casual use. It stops short of naming when-not to use it or pointing to an alternative for session/context deletion.

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 destructiveHint=true, idempotentHint=true and readOnlyHint=false, so the safety profile is covered. The description adds the genuinely useful behavioral fact that the default path is a reversible soft delete and only hard_delete=true destroys data permanently, which the annotations alone cannot express.

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 action and default behavior, then the opt-in for permanence. Every sentence carries distinct information and none is 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?

For a two-parameter tool with an output schema and full annotation coverage, the description supplies everything needed to call it correctly, including which mode is destructive. It stops short of noting any side effects on related data (memories, context) that a session deletion might cascade to.

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 both parameters are documented there, including the default for hard_delete. The description restates that same soft/hard dichotomy without adding format, identifier, or response details, so it sits at the baseline for a fully covered 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 and resource ('Delete a chat session') and immediately scopes the operation by naming the two deletion modes. It is clearly distinguishable from siblings like palim_delete_memory or palim_save_session, whose resources are memory and session creation respectively.

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 condition for selecting the harder mode ('Use hard_delete=true for permanent deletion'), and frames the default as reversible. It does not, however, say when an agent should delete a session at all versus using palim_save_session or palim_checkpoint, so no cross-tool routing is provided.

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 safety profile is covered. The description adds that the index is capped by default and can be expanded, which is modest extra context, but it says nothing about size limits, rate behavior, or what 'distilled' implies about completeness.

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 clauses, front-loaded with the resource and mode behavior; nothing is padded. The telegraphic fragment style is efficient but slightly terse for an agent parsing mode 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?

With an output schema present, return-value detail is not required, and the description covers both call shapes adequately. The remaining gap is the absence of any guidance on choosing this over palim_get_context or palim_search.

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 both parameters fully, including defaults and the 0-for-everything case. The description's 'Pass limit for a larger or full index' merely restates schema content, 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 ('Distilled knowledge profile') and describes both operating modes: no args returns a topic index, with topic returns the full document. However, 'brain' is internal jargon and the description never distinguishes this from sibling tools like palim_get_context or palim_search, which an agent must choose between.

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 clearly explains the two modes and what the limit parameter changes, which is useful conditional guidance. But it gives no when-to-use context relative to siblings such as palim_get_context, palim_search, or palim_resume, so routing remains an 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, and destructiveHint=false, so the safety profile is covered. The description adds that the output is 'formatted context' assembled by searching and retrieving sessions, which is useful but modest; it says nothing about pagination, ordering, or how many results are returned when max_sessions is exceeded.

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?

A single front-loaded sentence that names the action, the output artifact, the scoping input, and the retrieval mechanism with no filler. Nothing in it is redundant.

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, full parameter coverage, and annotations covering the safety profile, the description does not need to explain return values or side effects. It is nearly complete for a 5-parameter retrieval tool; the only real gap is the unstated relationship to sibling retrieval tools like palim_search.

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 every parameter (tags, topic, status, project, max_sessions) is already documented in the schema with examples and a default. The description adds no syntax, format, or interaction detail beyond what the schema provides, making the baseline 3 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?

The description states a specific verb (get) and resource (formatted context for a topic) and even describes the mechanism (searching and retrieving relevant sessions). It is clear on what the tool produces, but it does not distinguish it from siblings like palim_search or palim_get_brain, whose names suggest overlapping retrieval behavior.

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?

Usage is implied by the phrase 'for a specific topic', which tells the agent the tool is topic-scoped. However, there is no explicit when-to-use/when-not guidance and no mention of alternatives such as palim_search or palim_resume, so the agent must infer the boundary between this and its retrieval siblings.

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, so the safety profile is fully covered by structured data. The description adds only that the payload is a tool overview plus usage instructions, which is modest supplementary context with no rate limits, auth needs, or side effects to disclose.

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?

A single front-loaded sentence with the action and the returned content, no filler or 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?

An output schema exists and annotations cover the behavioral profile, so the description need not explain return values or safety. For a zero-required-parameter help tool it is essentially complete, with only the category-filtering affordance left solely to 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 description coverage is 100% and the single category parameter is documented in the schema itself, including its enum values and default. The description adds no meaning 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?

The description states a concrete verb ("Show") and resource ("overview of all available Palim tools and usage instructions"), which is unmistakably distinct from data-oriented siblings like palim_search or palim_add_memory. It is clear, though it does not explicitly name siblings to route against.

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?

Usage is only implied: an agent can infer this is the discovery/onboarding call, and the category enum hints at scoped lookups. There is no explicit when-to-use statement, no when-not-to-use, and no mention of 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?

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description goes beyond that by disclosing that the returned thread may be unrelated and should be discarded, and that the project filter matches to the most recently updated thread — useful behavior an agent would otherwise have to infer.

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?

Four short sentences, front-loaded with purpose and the calling instruction, with zero padding. The final sentence on project filtering partly duplicates the schema description, costing a bit of density.

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?

An output schema exists, so return-value explanation is unnecessary, and all four params are schema-documented. The description covers the primary calling pattern and a fallback rule; what's left out (no-thread behavior, how the resume interacts with session state) is minor for a read-only resumption helper.

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 four optional params are already documented. The description restates the project filter's case-insensitive, most-recently-updated matching (which the schema already says) and says 'no args', adding little beyond the schema, so 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: 'Continue the user's most recent Palim thread.' The scope ('most recent') is precise, but it never names a sibling (e.g., palim_get_context, palim_search) to distinguish itself from the other thread/context retrieval tools.

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?

'Call first in a new chat, no args' gives explicit timing guidance and a calling pattern, and 'Ignore the result if it is unrelated' tells the agent how to handle an off-target result. No alternatives or when-not-to-use conditions are named, so it stops short of 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 idempotent=true, destructive=false and readOnly=false, so the safety profile is covered. The description adds real behavioral context beyond them: what is stored ('no transcript', self-contained handoff) and that repeated calls should reuse session_id to update one row rather than create duplicates.

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 fragments, no filler: what it is, the key operational constraint, and when to invoke it. Purpose and the session_id instruction are front-loaded before the timing advice.

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, return values need no explanation, and the schema covers all parameters. The description supplies purpose and cadence but leaves the relationship to palim_save_session, palim_checkpoint and palim_resume unstated, which matters given the crowded sibling set.

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 16 parameters are already documented in the schema, including the session_id reuse semantics and the origin enum. The description adds no format or syntax detail beyond what the schema provides, 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?

The description states a specific action and scope: a lightweight checkpoint that produces a 'self-contained handoff, no transcript.' This distinguishes it in substance from a transcript-heavy sibling like palim_save_session, but it never names that sibling or any other, so the agent must infer the contrast from the sibling list.

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 concrete timing guidance ('Proactive after results and decisions, not only once') and an operational instruction ('Reuse session_id in this chat'), which is more than most definitions offer. It stops short of naming alternatives (palim_save_session, palim_checkpoint) or stating when not to use this tool.

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 flag destructiveHint/openWorldHint/readOnlyHint; the description goes well beyond by defining what is destroyed (overwrite replaces all existing messages vs. append), mandating pre-save redaction, and enumerating prohibited content classes (under-16, HIPAA PHI, PCI, adult content). That is substantive behavioral context an agent could not derive from annotations or 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?

Purpose is front-loaded, then routing, then compliance, then append procedure — each sentence carries distinct operational value with no restatement of the name or schema text.

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 destructive, nested-schema, multi-mode save tool with an output schema present, the description covers mode selection (append vs overwrite), call sequencing, compliance preconditions and sibling routing without needing to describe return values.

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 the schema already documents title, summary shape, messages, metadata and overwrite; baseline is 3. The description adds cross-call semantics the schema does not carry — reuse session_id/title across saves, fetch existing messages before appending, and always supply a complete summary plus metadata.tool_source — which is genuinely useful but partial.

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?

Opens with a specific verb+resource pair ('Save or append a full chat transcript') and immediately scopes what the resource contains (messages + summary). It explicitly distinguishes itself from palim_save_context, palim_update_session_metadata and palim_update_session_references, so an agent can route 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 explicit when-to-use alternatives ('Prefer palim_save_context for compact handoffs', 'For metadata-only or URL updates use palim_update_session_metadata / palim_update_session_references') plus the append recipe (reuse session_id + title, fetch existing messages first, send only new ones). 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 establish read-only, idempotent, non-destructive, closed-world behavior, so the safety bar is low. The description adds genuinely new behavioral context: the query matches session text or memory content/id, and project matching is case-insensitive. It does not describe result ordering or how sessions and memories are merged in the result set.

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?

Four short sentences, front-loaded with purpose before filtering details, with no filler. Slightly dense but every sentence 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?

Output schema exists, so return-value explanation is unnecessary, and annotations cover the safety profile. For a read-only search over two resource types, the definition covers matching semantics and no-query modes; the one gap is how the two result types are combined or ordered.

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 baseline is 3 and the schema already documents every parameter including case-insensitive project matching. The description repeats the case-insensitivity and adds matching-scope context for query, but contributes little 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 (search) and the resources it covers (saved sessions and memories), plus what the query matches against. It does not name or differentiate from siblings like palim_get_context or palim_resume, but the scope is unambiguous from the text alone.

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 a concrete calling condition: 'Omit query for tags-only or project-only session filtering,' which tells the agent how to use the tool in filter-only mode. It stops short of saying when to prefer this over sibling retrieval tools such as palim_get_context.

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