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

No annotations provided, but the description discloses critical behavior: the query is in-process, volatile, and only includes completed calls. It also explains the durable mode switch to a hash-chained trail. This is sufficient transparency for a query 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 concise sentences perfectly front-loaded. The first covers the main purpose, the second the alternative usage. 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?

Given no output schema or annotations, the description is complete enough: it explains dual modes, scope, and volatility. It could mention return format briefly, but for a diagnostic tool it's adequate.

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 baseline is 3. The description does not add additional meaning beyond the schema for any of the five parameters. It remains at the baseline.

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 'Query recent tool calls made by THIS MCP session' with specific scope (in-process, volatile, completed calls only) and distinguishes it from the durable variant. This differentiates from sibling 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?

The description explicitly tells when to use the durable parameter for backend audit chain queries vs the default session buffer. It does not mention alternatives among siblings, but the guidance on the durable parameter 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 full burden. It discloses return format (per-item status) and max items (20), but does not mention potential side effects, error behavior, or authorization needs. Adequate but not comprehensive.

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 core action, and concise. 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 tool has one parameter and no output schema, the description adequately covers purpose, usage, and limits. Missing minor details like error handling, but complete enough for a batch operation.

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 baseline is 3. The description adds return behavior context but does not add meaning to the parameter beyond what schema already provides (array of memories, max 20).

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 stores multiple memories in one call, using specific verb and resource. It implicitly distinguishes from velixar_store (single memory store) by emphasizing 'multiple' and 'batch' context.

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 recommends use for bulk imports or multi-fact storage, providing clear usage context. However, it does not explicitly exclude cases where a single memory should be stored via velixar_store, leaving a minor gap.

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?

Without annotations, the description carries full burden. It clearly indicates a read-only listing operation, though could mention it is safe and has no 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?

Two sentences, front-loaded with purpose, 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?

Given no output schema, the description does not specify the format or detail of the returned list. Adequate but leaves some ambiguity for the agent.

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?

No parameters, baseline 4. Description adds no parameter info but none is 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?

Clearly states it lists all available tools, resources, prompts, and features. Distinct from siblings which are specific actions, making it a discovery tool.

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 says to use to discover cognitive capabilities. While it lacks when-not-to-use or alternatives, the context is clear for a meta 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?

No annotations are provided, so the description carries full burden. It discloses that originals are preserved as provenance (non-destructive) and includes a preview mode for safe exploration. It does not mention authentication, rate limits, or error handling, but for a consolidation tool, the key behaviors are covered.

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, no redundancy, starts with the core action and purpose. Every sentence adds essential information: what it does, when to use it, and key parameter guidance.

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 tool's complexity (4 parameters, no required, no output schema) and many siblings, the description covers the essential usage scenarios. It is missing minor details like return format or explicit assurance of non-destructiveness, but it is sufficient for correct selection and 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 coverage is 100%, so baseline is 3. The description adds value by explaining the dual usage pattern (memory_ids vs. topic) and the purpose of the preview flag, going beyond the short schema descriptions. The summary parameter is mentioned ('Optional: provide the consolidated summary') but the description does not detail its format or relationship to auto-generation.

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 uses a specific verb ('Merge') and resource ('related episodic memories into a single semantic memory'), clearly distinguishing it from sibling tools like velixar_store (store new) or velixar_update (modify). It explicitly states what the tool does and what is preserved.

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 guidance: 'Use when multiple episodic memories cover the same topic and should be unified.' It also explains two modes of operation (by memory IDs or by topic) and the preview flag. However, it does not explicitly state when not to use this tool or list alternatives, though sibling names imply other options.

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 provided, so the description fully shoulders the transparency burden. It lists the outputs (summary, relevant facts, open issues, contradiction flags, pattern hints), which is good for a read-only synthesis tool. It could mention limitations or permissions but is adequate.

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 three concise sentences that front-load the action and recommendation. Every sentence adds value: purpose, usage guidance, and output list. No redundant or extraneous content.

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 tool's complexity (synthesizing a brief with multiple components) and no output schema, the description covers the key outputs. It could be more detailed about the structure or dynamic nature of the brief, but it is complete for a first-use recommendation.

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 already described clearly in the schema. The description repeats the same info ('Optional topic', 'Compact mode (default true)') without adding new meaning, so baseline score 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?

The description clearly states the verb 'Synthesize', the resource 'best working brief for the current workspace', and the output components. It distinguishes itself from siblings by being recommended as the first tool for any new task.

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 'Recommended first tool for any new task', providing clear when-to-use guidance. It does not explicitly mention alternatives or when not to use, but the context of sibling tools implies further refinements.

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 burden. It discloses the resolve action (which modifies data) and the output structure, but does not mention whether changes are reversible, required permissions, or any side effects. Transparency is adequate but not thorough.

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 two sentences, front-loaded with the main action ('Surface conflicting...'), and every sentence adds value. No redundant or unnecessary phrases.

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 explains return values (pairs with severity and memory IDs). However, it does not specify default behavior (e.g., default action is 'list'?), nor does it emphasize that contradiction_id is required for resolve. Given 6 parameters and moderate complexity, the description is sufficient but not fully comprehensive.

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?

All 6 parameters are fully described in the schema (100% coverage), so baseline is 3. The description adds value by clarifying the return format (severity and memory IDs) and that resolve action marks as resolved, which aids interpretation 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 clearly states the tool's purpose: 'Surface conflicting beliefs, preferences, or facts.' It also mentions the resolve action and the return format (pairs with severity and memory IDs). This distinguishes it from sibling tools, none of which handle contradictions.

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 does not provide explicit guidance on when to use this tool versus alternatives, nor does it mention when-not-to-use. While the name and purpose imply it's for contradictions, no usage context or exclusions are given.

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, description carries full burden. It states the tool checks coverage and returns data, implying read-only behavior, but doesn't detail side effects, permission requirements, or limits. Description is adequate but not deeply transparent.

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 adding value. Front-loaded with the core action and outputs. No unnecessary words. Highly efficient.

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 no output schema, description explains return values (ratio, gaps, queries). It provides usage context and covers parameter behavior via schema. Minor gap: could define 'coverage ratio' more precisely, but overall complete.

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 covers 100% of parameters with descriptions, so description adds minimal extra parameter info. Baseline 3 is appropriate; the description does not enhance parameter understanding beyond 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?

Description clearly states verb 'Check', resource 'how well retrieved memories cover a topic', and specific outputs 'coverage ratio, gaps, and suggested follow-up queries'. It also frames itself as an 'Anti-hallucination guardrail', distinguishing it from sibling tools like search or store.

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 advises using the tool before synthesizing an answer to verify completeness, and labels it as an 'Anti-hallucination guardrail'. While it doesn't list alternatives or when not to use, the context is clear enough for an agent.

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 must disclose all behavioral traits. It mentions the tool 'returns' data but the parameter description 'Set verbose logging on/off' implies a side effect (changing server logging state), which is not clarified. The description should explicitly state whether the tool is read-only or may alter state.

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 concise with no extraneous words, front-loads the core purpose in the first sentence, and each additional sentence provides specific value.

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 tool with one optional parameter and no output schema, the description is largely complete—it enumerates return contents. However, it lacks clarity on the side effect of the 'verbose' parameter (setting vs. getting), which would be expected for completeness.

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 baseline is 3. The description adds no new semantic meaning beyond what the schema provides for the 'verbose' parameter, merely repeating its effect.

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 action 'Get debug information' and the resource 'current Velixar MCP server state', and lists specific return items (workspace config, cache state, etc.), distinguishing it from sibling tools like velixar_health or velixar_update.

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 states what the tool does but provides no guidance on when to use it vs. alternatives, no exclusions or context for appropriate usage. It meets the minimum viable standard.

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 soft-delete vs hard-delete behavior but does not mention if deletion is irreversible, side effects, or required permissions. Some behavioral info is provided but not 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?

The description is extremely concise with two front-loaded sentences. Every word adds value, 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?

Given no output schema and no annotations, the description covers the core behavior (delete vs archive), parameter aliasing, and usage. It could be enhanced by mentioning return values or error conditions, but it is largely complete for a delete 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 coverage is 100%, so parameters are already documented. The description adds value by explaining that 'id' is an alias for 'memory_id' and clarifying the effect of the archive parameter (soft-delete vs hard-delete), going 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 clearly states the tool deletes or archives memories, and distinguishes between hard delete and soft delete via the archive parameter. It is specific and differentiates from sibling tools like velixar_update.

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 tells when to use archive: true for recoverable soft-delete, implying when not to use it (hard delete). However, it does not provide explicit when-not-to-use guidance or alternatives among 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?

With no annotations, the description carries full burden. It mentions returning source names, tables, and insights but does not disclose whether the tool is read-only, if it has side effects, authentication needs, or error behavior. The description is too minimal to ensure correct agent decision-making.

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 two sentences long, front-loaded with the core purpose, and concisely states what the tool returns. Every sentence adds value without redundancy or 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?

Given the tool's simplicity and 100% schema coverage, the description is acceptable but lacks completeness: no output schema, no error handling, no pagination info. For a tool with many siblings, more context would help the agent select 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 coverage is 100%, so baseline is 3. The description does not add meaning beyond the schema; it only indirectly references the topic parameter. While the schema individually documents each parameter, the description offers no additional semantic value or usage tips.

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 finds data sources containing information about a given topic via a knowledge graph, specifying returns like source names, tables, and insights. While it distinguishes from siblings like velixar_graph_traverse or velixar_list_sources, it does not explicitly differentiate from all related 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?

The description provides no guidance on when to use this tool versus alternatives such as velixar_search or velixar_list_sources. It lacks context on prerequisites, limitations, or exclusions, leaving the agent to infer usage solely from purpose.

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 provided, the description carries full weight. It discloses key behaviors: duplicate detection (skips near-identical content), contradiction flagging, and preview mode. It does not explain output format, durability guarantees, or error handling, but the core behavioral traits are well covered.

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 three sentences long, with the purpose stated in the first sentence. Every sentence adds unique value: usage timing, duplicate/contradiction handling, and preview option. No extraneous 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?

The description covers usage, duplicate detection, and preview mode fairly well, but lacks details on return values (e.g., what is returned when storing vs. preview), error cases, and storage limits. Given no output schema, some return information would be beneficial for complete understanding.

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 baseline is 3. The description adds value beyond schema by explaining that tags can be auto-generated ('auto-generated if absent') and clarifying the effect of preview mode ('return extracted memories without storing'). This additional context improves 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 clearly states 'Extract durable memories from session content', specifying the verb (extract) and resource (durable memories from session content). It distinguishes itself from sibling tools like velixar_store (which stores arbitrary data) and velixar_consolidate (which merges memories) by focusing on extraction and duplicate detection.

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 defines when to use the tool: 'at natural memory-worthy breakpoints: task complete, decision made, bug solved, preference clarified.' It also mentions using preview mode for dry runs. However, it does not explicitly state when not to use it or provide direct comparisons to 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?

No annotations are provided, so the description must disclose behavioral traits. It only describes the export function without mentioning side effects (e.g., is it read-only?), performance implications, or whether it modifies memory state. The absence of such information reduces transparency.

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, well-structured sentence that front-loads the core purpose. Every word adds value, 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 a tool with 9 parameters and no output schema, the description is somewhat minimal. It omits details like default format, relationship between 'all' and 'limit', and the structure of the exported data. However, the filtering capabilities are listed, providing basic context.

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 input schema already documents all parameters. The description adds a summary of filtering options but does not provide additional meaning beyond what the schema already conveys. Baseline score 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?

The description clearly states the verb 'Export', the resource 'memories', and the output formats (JSON or Markdown). It also lists filtering capabilities, making the tool's purpose immediately clear and distinct from sibling 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?

The description implies usage for exporting filtered memory data, but does not explicitly state when to use this tool over alternatives like velixar_search or velixar_list. No guidance on when not to use it or prerequisites.

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 provided, so description carries full burden. It indicates 'fuzzy' matching, implying approximate behavior. However, it does not disclose other traits like case sensitivity, partial matching, or any constraints.

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 two sentences, directly stating the purpose and use case with no unnecessary words or repetition.

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?

Lacks information about return values or output format. For a search tool, missing what entities are returned (e.g., IDs, metadata). Sibling tools like velixar_inspect might complement, but incomplete on its own.

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 baseline is 3. The description adds minimal extra meaning beyond summarizing fields as 'by name or type'. It does not enhance understanding of individual parameters.

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 'Fuzzy entity search by name or type', specifying the action and resource. It distinguishes from siblings like velixar_search (which likely does exact search) and velixar_graph_traverse, but does not explicitly differentiate.

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 a usage context: 'Use to find entities without knowing exact names.' However, it does not specify when not to use it or suggest alternatives among sibling tools.

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 full burden for behavioral transparency. It states the output (counts, top types) but does not disclose any side effects, performance characteristics, or limitations. For a zero-parameter tool, this is minimally adequate.

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, consisting of two short phrases. It is front-loaded with the key output types. Every part is essential and wastes no 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?

Given the tool has zero parameters, no output schema, and no annotations, the description is adequate for its simplicity. It tells the user what the tool returns and the scope. Could be slightly more detailed, but it is sufficient for an agent to understand the tool's role.

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 has zero parameters, so the baseline is 4 as per guidelines. The description does not need to add parameter semantics since none exist. Schema coverage is 100% trivially.

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 provides an overview of a knowledge graph, including entity count, relationship count, and top entity types, scoped to the workspace. This is specific and distinguishes it from siblings like velixar_graph_traverse or velixar_graph_search.

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 mentions 'Workspace-scoped,' indicating the context, but does not explicitly state when to use this tool versus alternatives like velixar_graph_traverse. However, the purpose is clear enough for an agent to infer appropriate usage.

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 fully disclose behavioral traits. It only mentions support for fuzzy matching and filtering, ignoring safety (read-only vs destructive), performance (depth limit), or authentication needs.

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 two sentences, front-loading the core purpose. Every word is necessary and there is 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?

The description omits return value format (e.g., list of entities/relationships) and details on fuzzy matching behavior. Given the complexity of graph traversal and multiple sibling tools, more context is needed for effective tool selection.

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 description contributes minimal added value beyond stating that the tool supports filtering on entity_type and relationship_type. The schema already documents default and max for depth.

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 walks relationships from an entity using the phrase 'Walk relationships from an entity — what connects to X?'. It specifies support for fuzzy entity matching and filtering, distinguishing it from sibling tools like velixar_graph_search and velixar_graph_stats.

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 implies usage for exploring connections from a starting entity but provides no explicit when-to-use or when-not-to-use guidance. It does not mention alternative tools or exclusions.

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?

Discloses it returns connection state, workspace, and latency. Even without annotations, clearly a read-only, non-destructive operation.

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, each adding value: purpose and return information. No waste.

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 parameterless health check with no output schema, the description fully covers what the tool does and returns.

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?

No parameters, so schema coverage is 100%. Description adds no parameter info beyond schema, meeting baseline.

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?

Clearly states it checks backend connectivity and health, with verb 'check' and specific resource. Distinguishes from siblings as a health-only tool.

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?

Implies usage for verifying connectivity before other operations, but no explicit when-to-use or alternatives guidance.

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 full burden. It discloses the workspace-scoped nature and supported actions but does not describe behavioral traits such as permission requirements, what happens on deletion, or the effect of updates. For a mutation tool, this is insufficient.

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 two sentences, front-loaded with the core purpose, and every word adds value. No redundancy or extraneous 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?

No output schema exists, so the description should explain return values or behavior (e.g., what get returns, what list returns). It does not. Additionally, it lacks details on error scenarios or idempotency. The tool has 3 optional params and an enum, but the description doesn't fully cover the operational context.

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%, baseline 3. The description lists example field values (preferences, goals, constraints) that go slightly beyond the schema's examples, adding minor value but not compensating significantly for the 0% coverage gap in the schema (which is already 100%).

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 this tool manages user profile fields (preferences, expertise, communication style, etc.) and lists all supported actions (get, store, update, delete, list, history). This distinguishes it from generic sibling tools like velixar_store or velixar_list by specifying the identity/profile scope.

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 implies the tool is for managing user profile fields but does not explicitly state when to use it over alternatives (e.g., velixar_context for context data, velixar_store for arbitrary data). No guidance on prerequisites or exclusions 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?

With no annotations, the description bears full responsibility. It discloses the 50-item limit and conflict handling, which are important behavioral traits. However, it does not mention whether the operation is idempotent, what happens on partial failures, or any authentication/permission requirements. More behavioral context would be beneficial.

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 covering purpose, limit, and conflict handling. No unnecessary words or repetition. Information is front-loaded with the key action 'Bulk import memories from structured data'.

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 tool has 6 parameters and no output schema. The description covers the main purpose, a key constraint (max 50), and conflict strategies. However, it lacks details on return value (e.g., count of imported items) and error handling. Given the complexity, a bit more information would improve completeness.

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. The description adds value beyond the schema by stating the max 50 items per call and summarizing the conflict strategies. While the schema already documents each parameter, the description provides critical constraints and context that are not in 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 clearly states the tool does bulk import of memories from JSON or Markdown. It uses the specific verb 'import' and resource 'memories', and the title 'velixar_import' reinforces this. It distinguishes itself from siblings like 'velixar_store' (likely single item) by focusing on bulk operation and structured formats.

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 clear guidance on when to use this tool: for bulk imports (max 50 items). It also mentions conflict detection strategies (skip, overwrite, merge), which helps the agent choose the appropriate strategy. However, it does not explicitly state when not to use it or mention alternatives like 'velixar_store' for single items.

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 for behavioral disclosure. It mentions the aspects inspected (content, provenance, etc.) but does not explicitly state that the operation is read-only or describe any side effects, which is a 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?

The description is a single, front-loaded sentence with no redundant words. Every part is informative and contributes to understanding.

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 tool with one parameter and no output schema, the description provides a reasonable overview of what will be returned (raw content, provenance, relations, chain links), though it could be slightly more exhaustive.

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 provides 100% coverage for the single parameter (memory_id). The description adds value by listing what the inspection reveals, but does not add new semantic info about the parameter itself. 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 uses a specific verb 'inspect' and identifies the resource 'memory', and lists distinct aspects (raw content, provenance, relations, chain links) that differentiate it from sibling tools like velixar_search or velixar_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?

The description implies usage for detailed inspection of a single memory, but does not explicitly state when to use it over alternatives like velixar_search or velixar_context, nor does it provide when-not-to-use guidance.

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 that edges are declared at store time via source_ids, returns nodes with hop distance and is_origin, and directed child→parent edges. It implicitly indicates read-only behavior, though explicit statement of non-destructiveness would be ideal.

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 concise and well-structured, with the key distinction provided upfront. Every sentence adds value, no fluff 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?

Given no output schema, the description effectively explains the return format (nodes with hop distance and is_origin, directed edges) and the concept of origins. It provides sufficient context for an agent to understand what the tool does and what to expect.

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?

All 3 parameters are fully described in the schema (100% coverage). The description adds value by providing context for the direction parameter (explaining 'up' vs 'down' in terms of ancestors/descendants) and clarifying the meaning of depth. This goes beyond the schema's short 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 clearly states the tool traces derivation lineage (knowledge-building graph) and explicitly distinguishes it from similarity search (velixar_search_neighborhood). It uses specific verbs ('Trace the DERIVATION lineage') and defines key concepts (ancestors, descendants, origins).

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 (understanding what a memory was built from and what was built on it) and when-not-to-use (not for similarity, which belongs to velixar_search_neighborhood). It also explains the meaning of direction parameters (up=ancestors, down=descendants).

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 full burden. It describes the operation as listing and filtering but does not explicitly state that it is read-only, safe, or mention any side effects, permissions, or rate limits. The behavioral traits are implicit but not explicit.

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 two concise sentences that clearly convey the purpose and capabilities without any fluff or redundancy. Every sentence adds value.

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 of 9 parameters and no output schema, the description covers pagination, filtering options, and return metadata. It lacks explanation of sorting defaults and cursor-based pagination but is otherwise adequate for a list 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 the schema already documents all 9 parameters. The description adds high-level context (supports filtering by tags, date range, tier, memory type) but does not add detail beyond what the schema provides, thus baseline score 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?

The description explicitly states it lists recent memories with pagination and returns full metadata including IDs, tags, and timestamps. It clearly distinguishes from sibling tools like velixar_search (search) and velixar_delete (delete) by focusing on listing and filtering.

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 implies usage for listing memories with filters but does not explicitly compare with alternatives like velixar_search for full-text search or velixar_timeline for chronological views. No when-not-to-use or prerequisites are mentioned.

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 fails to disclose whether the operation is read-only, requires authentication, returns paginated results, or has side effects. The phrase 'list all' suggests a safe read, but this is unconfirmed.

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 front-load the main action and follow with filtering support. No wasted words, though the second sentence could be more specific about which parameters apply.

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 list tool with no output schema, the description covers the basics but omits potential concerns like pagination, result ordering, or error handling. It is adequate but not thorough.

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 both parameters have clear descriptions in the schema. The description merely restates the filtering capability without adding new details, meeting the baseline expectation.

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 action ('list'), the resource ('connected data sources'), and scope ('for the current customer'). It also mentions filtering options, which distinguishes it from generic list tools like 'velixar_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?

No explicit guidance on when to use this tool vs. alternatives like 'velixar_discover_data' or 'velixar_query_source'. The description implies its purpose but does not set boundaries or prerequisites.

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 reveals key behaviors: deduplication, temporal awareness, merging, and strategies (union, intersection, weighted). It does not cover rate limits, authentication, or error handling, but the disclosed behaviors are sufficient for typical use.

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 well-structured sentences. The first sentence front-loads the core purpose and features. Every word earns its place; no fluff.

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 is provided, so the description should clarify return format. It mentions 'merged results by default' but does not detail the structure or fields. Temporal awareness is named but not explained. With 6 parameters, the description covers usage but lacks depth on outputs.

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 baseline is 3. The description adds marginal value by example (setting merge:false) and mentions strategy, but the schema already describes all parameters adequately.

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 searches from multiple angles simultaneously with deduplication and temporal awareness, and specifies it returns merged results by default. It distinguishes itself from sibling tools like velixar_search (single query) and velixar_batch_search (which it replaces).

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 tells when to set `merge: false` for per-query results and notes this replaces velixar_batch_search, guiding the agent on alternatives. However, it does not explicitly state when not to use the tool or provide other exclusions.

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 disclose behavioral traits. It only mentions 'Supports dismiss action', implying mutability, but does not clarify side effects, permissions, or response behavior. This is insufficient for a tool with no annotation safety net.

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 two sentences long, front-loads the core purpose, and every word adds value. It is a model of conciseness.

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 6 parameters, no output schema, and no annotations, the description is too sparse. It does not explain return format, confidence thresholds, or the 'evidence' parameter's output, leaving the agent under-informed for correct usage.

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 covers all parameters with descriptions (100% coverage), so the baseline is 3. The description adds value by explaining the 'topic' omission behavior and the 'dismiss' action, but does not elaborate on 'limit', 'evidence', or 'min_confidence', which are left to 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 uses the verb 'Surface' and specifies the resource 'recurring problem/solution motifs from memory', which clearly indicates the tool's purpose. It is distinct from sibling tools like velixar_search or velixar_list by focusing on patterns rather than raw data.

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 a usage hint: 'Omit topic to return all detected patterns', which helps the agent decide when to use the topic parameter. However, it lacks explicit guidance on when not to use this tool or alternatives among the many sibling tools.

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 provided, so the description carries full burden. It discloses internal operations (multi-angle search, coverage check, temporal analysis) and mentions explicit gap declaration. However, it does not state whether the tool is read-only, what side effects exist, or any authorization requirements. Given no annotations, this is adequate but not comprehensive.

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?

Single sentence that efficiently conveys the core function and internal operations. Every phrase adds value with no redundancy or fluff.

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 7 parameters and no output schema, the description is too brief. It does not explain the return value (context package with gap declaration) or how it connects to sibling 'velixar_refine_context'. For a complex preparation tool, more detail is needed.

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 parameters thoroughly (including defaults for token_budget and context_ttl). The description adds high-level purpose but no per-parameter elaboration beyond what the schema provides. 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?

Description states specific verb 'assemble' with resources: token-budgeted context package, explicit gap declaration, and internal operations (multi-angle search, coverage check, temporal analysis). It distinguishes from siblings like 'velixar_context' by mentioning gap declaration and internal analysis, but does not explicitly contrast with 'velixar_refine_context'.

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?

No explicit when-to-use or when-not-to-use guidance. The description does not mention alternatives like 'velixar_context' (presumably simpler) or 'velixar_refine_context'. The agent must infer usage from the name and sibling list.

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 burden of behavioral disclosure. It states the tool queries and returns data, implying a read operation, but does not explicitly declare safety, idempotency, or side effects. It also lacks details on error handling, latency, or authorization requirements. The instruction to tag results is useful but insufficient for full transparency.

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 concise with three sentences, front-loading the core purpose and method. Every sentence adds value: purpose, guarantee of live data, and usage instruction. Slightly repetitive (live/real-time) but not wasteful. Could be tighter by merging sentences 2 and 3.

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 lack of an output schema, the description should provide more detail on the return format (e.g., rows, columns, JSON). It only guarantees 'real-time data' and a tag. The cursor parameter implies pagination but is not explained. For a query tool with 5 parameters, this leaves significant gaps in understanding what the agent receives.

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?

Since the input schema has 100% description coverage, the baseline is 3. The description adds marginal value by clarifying that the 'query' is natural language and translated, but this is already implied by the schema description. No additional semantics are provided for other parameters beyond what the schema offers.

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 queries a live data source via Marco Polo, returns real-time data, and translates natural language to SQL/API. This is specific enough to distinguish from siblings like velixar_list_sources (which lists sources) or velixar_search (which may not be live). However, it does not explicitly contrast with alternatives, so it falls short of a perfect 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 description provides no explicit guidance on when to use this tool versus siblings. It mentions 'Always tag results as [LIVE DATA]' but does not explain prerequisites, exclusivity, or typical usage scenarios. Without such context, an agent may mis-select this tool for non-live data needs.

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 for behavioral disclosure. It mentions batch refinement but does not disclose side effects (e.g., whether the original context is modified or replaced), reversibility, or limits. The return format is also omitted as there is 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?

The description is two sentences, front-loaded with the core purpose. Every sentence is essential, with no wasted words 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?

Given the absence of an output schema and the complexity of refinement (e.g., interaction between action/target and actions/budget), the description lacks details on return values, state changes, and parameter interplay. It is incomplete for a tool with 5 parameters.

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 baseline is 3. The description adds no extra meaning beyond the schema; it merely reiterates that single or batch actions are accepted. No additional parameter constraints or clarifications are provided.

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: expanding sections, filling gaps, or adding topics to an existing context package. It uses specific verbs and resources, and distinguishes from sibling tools like velixar_context (creation) and velixar_prepare_context (preparation).

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 no guidance on when to use this tool versus alternatives, nor does it mention prerequisites or when not to use it. The required context_id parameter implies prior context preparation, but this is not stated 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?

No annotations are provided, so the description must fully disclose behavior. It mentions supported operations (add, remove, replace) but lacks details on error handling, idempotency, required permissions, or whether operations can be combined in a single call.

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 redundancy. First sentence states core functionality; second sentence provides use cases and supported operations.

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 description covers basic purpose and operations but omits details about return values (no output schema), atomicity, and behavior when multiple operations are specified simultaneously.

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 parameters. The description adds minimal value beyond reiterating operations; it does not explain parameter constraints or dependencies.

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 'update' and the resource 'tags on memories'. It distinguishes from siblings like velixar_update (which updates entire memories) and velixar_store (which creates memories) by specifying tag operations.

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 use cases ('organizing, correcting, or enriching memory metadata'), giving clear context. However, it does not mention when not to use the tool or explicitly contrast with alternatives like velixar_update.

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 present, so the description must convey behavioral traits. It describes reading behavior (search, filtering) and implies no side effects, but does not explicitly state that the tool is read-only or safe. It adequately covers the basic behavior but lacks depth (e.g., no mention of performance, auth requirements, or effect on system state).

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: two sentences that front-load the core functionality and then list filter options. Every word earns its place; there is no irrelevant information 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?

Given 8 parameters, no output schema, and many sibling tools, the description covers the essential aspects: search method, filtering, and result ranking. However, it lacks details about the output structure (e.g., fields returned, pagination) and could more explicitly differentiate from similar sibling tools. Nonetheless, it is largely complete for a search 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 the baseline is 3. The description summarizes the filtering capabilities (tags, date range, tier, memory type) but does not add meaningful information beyond what the schema already provides for each parameter. No additional constraints or interactions between parameters are explained.

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 function: 'Search stored memories by semantic similarity.' It specifies the resource (memories), the operation (search), and the method (semantic similarity). It also mentions that it returns ranked results with relevance scores, distinguishing it from list or exact-match 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?

The description implies use for semantic search and mentions ranking, but does not explicitly state when to use this over alternatives like velixar_list, velixar_graph_search, or velixar_multi_search. No when-not or exclusion criteria are provided, leaving the agent to infer usage context.

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 provided, so the description carries the burden. It discloses classification into forward/backward/lateral and mentions vector space. However, it does not mention read-only nature, performance implications, or required permissions.

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 that efficiently conveys the core purpose without wasted words. Slight deduction for not explicitly linking direction parameter to enum.

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 5 parameters and no output schema, the description lacks information on return structure, pagination, or how to interpret results. It feels incomplete 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 coverage is 100%, so the input schema already describes all parameters. The description does not add additional meaning beyond what the schema provides, resulting in baseline score of 3.

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 action 'Find' and the resource 'memories near a known memory in vector space', and distinguishes from siblings like velixar_search by specifying vector space proximity and directional classification.

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 implies use for proximity search with directionality, but does not explicitly state when to use this tool versus alternatives like velixar_search or velixar_graph_traverse.

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 provided, so description carries full burden. It explains modes but lacks details on side effects, persistence, authorization, or behavior when mode changes.

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?

Single sentence that front-loads purpose and efficiently lists modes with their meanings. No superfluous 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?

Covers core functionality and mode details, but omits return value description when 'getting' mode and lacks broader behavioral context like effect on existing content.

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 has 100% coverage with enum description, but description adds explanatory context for each mode (e.g., 'strict' means PII redaction), which is not in 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?

Description clearly states the tool gets or sets the security scanning mode for memory content, specifying three modes with meanings. Distinct from siblings as no other tool deals with security mode.

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?

Implies use when needing to view or change scanning mode, but no explicit guidance on when not to use, prerequisites, or alternatives among sibling tools.

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 provided, so description bears full burden. Discloses that it recalls memories with filtering and ordering options, but does not describe behavior on missing sessions, rate limits, or authorization needs. Adequate but could be more detailed.

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 serving a distinct purpose: purpose, usage context, and parameter specifics. No redundant or unnecessary wording. Highly efficient.

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 7 optional parameters and no output schema, the description covers main use cases and links to sibling tool (session_resume). Could mention return format or default behavior, but sufficiently complete for a recall 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 coverage is 100% (7 parameters described), so baseline is 3. Description adds value by explaining usage context (e.g., chunk_id from session_resume manifest, order='chronological' for narrative reconstruction) beyond schema 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?

Description clearly states 'Recall memories from a previous session' with specific resources (session ID, date, topic) and a distinct verb. Differentiates from siblings like velixar_search (general search) and velixar_session_save/resume.

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 says 'Use when resuming work to restore prior context' and provides parameter-specific guidance (chunk_id for drill-down, order='chronological' for full narrative). Does not explicitly exclude alternatives but provides sufficient context.

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 burden. It discloses what the tool returns (narrative summary, key decisions, open threads, last state), but does not mention side effects, authorization needs, or whether it is read-only. As a resume tool, it is likely non-destructive, but this is not explicit.

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 sentence with a second sentence listing return items. It is front-loaded with the key purpose and 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?

Given the tool has 7 optional parameters and no output schema, the description explains what it returns and its purpose. However, it could better explain why it is the recommended way compared to alternatives and how the reconstruction works. Still, it is fairly complete 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?

Schema description coverage is 100%, so baseline is 3. The description does not add significant meaning beyond the schema; it only provides overall context. The schema already describes each parameter adequately.

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 it reconstructs full session context in a single call, which is a specific verb+resource, and distinguishes it from siblings by calling it the recommended way to resume work.

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 says 'recommended way to resume work', providing clear context for when to use it, but does not explicitly mention when not to use it or name alternatives like velixar_session_save or velixar_session_recall.

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 auto-generation of session_id and return of session_id, but does not specify whether providing an existing session_id overwrites the record, or if there are any side effects (e.g., requires certain permissions, rate limits). The behavior is minimally transparent.

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 two sentences, both front-loaded with key information. No unnecessary words. Every sentence contributes: first states purpose, second explains auto-generation and return.

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 3-parameter tool with no output schema, the description covers the core function and return value. It omits behavior when session_id is provided (overwrite vs. create new) and doesn't describe tags, but is otherwise sufficient for basic use.

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% (all parameters described in schema). The description adds only one extra detail: 'Auto-generates session_id if not provided.' For tags, the schema says 'Additional tags' and description omits them entirely. The description adds marginal value 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 clearly states the tool's action: 'Save a session summary for later recall.' It specifies the resource ('session summary') and distinguishes from sibling tools like 'velixar_session_recall' and 'velixar_session_resume' by being the save counterpart.

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 no guidance on when to use this tool versus alternatives such as 'velixar_store' (for arbitrary data) or 'velixar_update' (for updates). It does not clarify the context where saving a session summary is preferred.

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 provided, but the description fully discloses key behaviors: workspace-scoping, persistence, automatic chunking, exact-duplicate blocking, near-duplicate option, tier system, and max size enforcement.

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?

Well-structured with front-loaded purpose and grouped details. Slightly verbose but every sentence adds value; could trim a few 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?

Given the complexity (9 params, no output schema), the description covers all critical aspects: chunking, dedup, scope, parameter usage, and result behavior (existing ID returned). No 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%, but the description adds significant context beyond the schema: explains source_ids as derivation lineage, check_duplicate for near-duplicates, atomic for no-split, tier meanings, quarantine_zone visibility.

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 'Store a memory for later retrieval' and enumerates specific use cases (facts, decisions, preferences, etc.). It distinguishes from siblings by focusing on storage vs. search, delete, etc.

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 advises when to use (store) and when to check duplicates first, even naming velixar_search as an alternative. Warns about size limits and automatic chunking.

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. It discloses date range filtering and summary mode, which are key behaviors. However, it omits details like default limit, sorting order, error handling, and whether it is read-only. The description is moderately transparent but could be more thorough.

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 consists of two concise sentences that front-load the core purpose and immediately highlight key features. Every word earns its place with no redundancy or fluff.

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 tool's complexity (5 parameters, temporal filtering, summary mode), the description covers the main purpose and one feature but lacks details on output format, pagination (limit default), and behavior when both topic and memory_id are omitted. It is adequate but not fully complete.

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% (all 5 parameters described). The description adds value by mentioning summary mode, which is not directly in the schema, and explicitly ties after/before to date range filtering. This goes beyond the schema's baseline of 3.

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: showing how a topic, entity, or belief evolved over time. It specifies the verb 'Show' and the resource 'evolution over time', which distinguishes it from sibling tools like velixar_search or velixar_list, but it does not explicitly differentiate from all siblings.

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 no explicit guidance on when to use this tool versus alternatives like velixar_search or velixar_graph_traverse. It implies usage for temporal queries but lacks exclusions or context about when not to use it.

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 provided, so description must disclose side effects, permissions, and error behavior. It only states the action without revealing that updates are partial or what happens on failure.

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?

Single sentence is efficient and front-loaded, but it omits critical details that would not significantly lengthen it.

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, no information on return values. With 4 optional parameters, description should indicate at least one required field. Missing context for a mutation 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 covers 100% of parameters, so baseline is 3. Description adds no extra meaning beyond schema; e.g., it does not clarify the alias relationship between 'id' and 'memory_id'.

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?

Description clearly states the tool updates an existing memory's content or tags, specifying verb and resource. It distinguishes from create/delete tools but could be more precise about the object type.

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?

No guidance on when to use this tool vs siblings like velixar_retag or velixar_consolidate. The agent has no context to choose appropriately.

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 present, so the description bears the full burden. It discloses that files are parsed, chunked, and tagged with source metadata, but does not cover side effects (e.g., overwrites, storage limits), error conditions, or access requirements.

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 efficiently convey purpose, supported formats, and processing. 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?

The description explains what happens to the uploaded file and covers the key parameters. However, it omits what the tool returns (e.g., confirmation, memory ID) since no output schema is provided, which is a minor gap for an upload 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 coverage is 100% and parameter descriptions are clear. The description adds that files are 'tagged with source metadata' which loosely relates to the tags parameter, but does not provide additional meaning beyond what the schema already states.

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: uploading a file into Velixar memory with full source provenance. It enumerates supported file types and outlines the processing steps (parsed, chunked, tagged), distinguishing it from related tools like velixar_store or velixar_update.

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 implies usage for single file uploads with provenance tracking but provides no explicit when-to-use or when-not-to-use guidance. Alternatives like velixar_batch_store or velixar_update are not mentioned, leaving the agent to infer context.

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