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

With no annotations the description must carry the safety profile, and it does by flagging the operation as 'Permanent' and pairing it with a non-destructive alternative. It does not disclose what the call returns (e.g., deletion count) or how multiple filters combine, so the destructive disclosure is strong 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?

Two tightly packed sentences: the operation, its filter surface and its prerequisite come first, followed by the safety note and the alternative. No filler and no redundancy with the schema.

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

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

For a destructive, no-annotation, no-output-schema tool, the description covers permanence and filter scope but omits return behavior and whether the filters AND together versus OR. Adequate to call correctly, but a few gaps remain for a tool whose effects are irreversible.

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 description enumerates the filter families (tags, importance range, time window, type, session), which maps onto most of the eight parameters, and adds a cross-parameter rule ('at least one is required') that the schema itself does not encode. It stops short of syntax details for the timestamp/importance bounds that the schema partly covers at 63%.

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

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

States a specific verb and resource ('Bulk-delete memories') plus the qualifying dimension (matching filters) in a single clause. It is clearly distinguishable from the single-record dakera_forget and from dakera_memory_importance, which it names.

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

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

Gives the selection constraint ('matching filters ... at least one is required') and routes the agent to the correct alternative for the non-destructive case ('to demote instead, use dakera_memory_importance'). It lacks guidance on when to prefer this over per-record deletion, but the context is otherwise 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?

No annotations are provided, so the description carries the full burden. It does disclose real behavior the schema omits: the result cap 'at most limit (default 100)'. However, it never states that this is a read-only, non-mutating operation, nor mentions ordering, pagination, or auth requirements – gaps that matter for a list endpoint with zero annotation coverage.

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

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

A single dense sentence with the capability, the defining constraint, the limit cap, and the routing rule, all front-loaded. No filler or redundancy.

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

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

For a read-only filtered-list tool with no output schema and no annotations, the description covers purpose, the key filter dimensions, the result cap, and sibling routing. It is missing only ordering/pagination behavior and any mention of the required agent_id, which keeps it from being 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 description coverage is 56%, and the description enumerates the filter dimensions (tags, importance, time window, type, session), which loosely maps to the filter parameters. But it adds no format or semantics beyond the schema's own enum and inline descriptions, and the required 'agent_id' parameter is never mentioned anywhere.

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

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

States a specific verb and resource ('List memories') plus the defining scope constraint ('by filters ... without a query'), which is exactly what separates it from semantic recall. It explicitly names the sibling it replaces, so an agent can route correctly without opening any schema.

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

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

Gives a clear selection rule: 'Use instead of dakera_recall when no semantic search is needed,' naming both the alternative and the condition. It stops short of stating when NOT to use it (e.g., when relevance ranking matters) or how it relates to the other search 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?

The description discloses that the tool returns only names and summaries without loading full schemas, giving insight into its behavior and efficiency. However, it does not explicitly state that it has no side effects (e.g., read-only operation), which is left to inference. Since no annotations are provided, a bit more explicit safety disclosure would be ideal, but the current description is still reasonably 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 long, concise, and front-loads the primary purpose. It contains no filler words and each sentence adds value: the first states the function, the second provides usage guidance and efficiency rationale.

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 provides sufficient context for an agent to decide when to use this tool: it is a discovery step that avoids loading full schemas. It also names the companion tool for schemas, making the workflow clear. The mention of output (names and summaries) covers the basic expectations even without an output schema.

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

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

Both parameters (tier and query) are mentioned in the description: 'by keyword or tier.' The description explains that tier is a filter with enum values (core, power, admin, meta, all) and query is a keyword for searching names/descriptions. This provides full semantic coverage without redundancy with 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 that the tool searches the Dakera tool catalog by keyword or tier, which is a specific verb and resource. It also distinguishes this tool from others like dakera_load_tools by emphasizing it returns only names and summaries, making its purpose unambiguous.

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?

Explicit guidance is provided: 'Call this first to find relevant tools, then use dakera_load_tools to fetch only the schemas you need.' This tells the agent exactly when to use this tool versus alternatives and highlights the efficiency benefit of avoiding full schema loads.

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

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

With no annotations, the description carries the burden and does well: it discloses the credential requirement (write key for the namespace, expanded scope when neither namespace nor agent_id is given) and the provider fallback chain. It does not describe the shape of the extraction result or any failure modes, which keeps it from a 5.

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 dense sentences with no filler; the core action is front-loaded, followed by the provider chain and the auth caveat. The first sentence is long but each clause carries information, so no trimming is warranted beyond minor restructuring.

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 a nested extractor_override object, no output schema and no annotations, the description covers configuration resolution and auth scope well. It leaves the returned extraction structure unexplained, but with no output schema declared that is a secondary gap.

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 80%, so the baseline is 3, but the description adds meaning the schema lacks: the precedence order for extractor_override versus the namespace/server default, and the authorization implication of namespace/agent_id omission. That is genuine value beyond the structured fields.

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 gives a precise verb (Extract) and an explicit resource list (entities, topics, key phrases, summary) from text, and names the sibling/alternative dakera_auto_tag for ad-hoc GLiNER types. An agent can tell this apart from the retrieval-oriented siblings without opening the schema.

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

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

It names a concrete alternative ('For ad-hoc GLiNER types use dakera_auto_tag') and explains the provider resolution order (extractor_override → namespace default → server default GLiNER local), which tells the agent when this tool's configuration applies. It stops short of stating when-not to use it versus the search/knowledge_graph 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?

The description discloses that deletion is immediate and irreversible, and that using tags results in bulk deletion. With no annotations, this covers key behavioral aspects, though it does not mention potential side effects like cascading deletions or missing confirmation.

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, front-loaded with the purpose, and well-structured. It covers purpose, usage, and an alternative in two sentences without unnecessary detail.

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

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

Given the lack of an output schema, the description does not need to explain return values. It covers the essential 'when' and 'how' but leaves gaps regarding agent_id semantics and the interaction between parameters, which could affect an agent's 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 provides descriptions for memory_ids and tags, but agent_id has no description in either the schema or the tool description. The description explains the usage of memory_ids and tags, but does not clarify the role of agent_id or whether the two parameters can be combined or are mutually exclusive.

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

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

The description clearly states the tool's purpose: to permanently delete memories by ID or tag. It specifies the resource (memories) and the method (by ID or tag), and distinguishes it from sibling tools like dakera_batch_forget and dakera_memory_importance.

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 on when to use this tool: 'Provide memory_ids for exact removal or tags to bulk-delete all memories sharing those tags.' It also names an alternative (dakera_memory_importance) for a different use case (suppression instead of deletion), making the decision 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 must convey behavioral traits. 'Search' implies a read-only operation with no side effects, and the description does not hint at any modifications. However, it does not explicitly state that no data is altered, so a minor gap exists.

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 compact, using two sentences to convey purpose and usage guidance without unnecessary verbiage. It is well-structured and front-loads the core function.

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 need not explain return values. It fully covers the tool's purpose, selection criteria, and relationship to sibling tools, leaving no critical information missing for an agent to use 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?

All four parameters (query, top_k, filter, namespace) have descriptions in the schema, giving high coverage. The tool description adds no extra parameter-specific insights, so the baseline 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 tool performs 'BM25 keyword search over indexed documents' and explicitly distinguishes it from vector and hybrid search alternatives. It identifies the specific resource (indexed documents) and the verb (search) without ambiguity.

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 direct usage guidance: 'Use over vector search when exact-term recall matters' and 'For semantic+keyword combined use dakera_hybrid_search.' This tells the agent exactly when to select this tool over its 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 explains the hybrid algorithm and weight behavior, but does not disclose safety, permissions, cost, or error behavior. The 'single pass' note gives a performance hint, but overall transparency is limited.

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, front-loaded sentences with no redundancy. Every sentence provides essential information, and the structure is clear.

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, nested filter object, and no output schema, the description is somewhat minimal. It does not explain return values, pagination, or results handling, leaving gaps for a complex 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 coverage is 75% (two parameters lack descriptions in schema). The description adds meaning by explaining the vector parameter for BM25-only mode and the vector_weight range, enhancing understanding 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 specifies a hybrid search combining BM25 and vector ANN in a single pass, and distinguishes from siblings by noting BM25-only mode and use case for RAG when pure methods are insufficient.

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 states when to use ('RAG when pure semantic or keyword search alone is insufficient') and how to configure modes (omit vector for BM25-only, adjust vector_weight). Lacks explicit exclusion criteria but provides clear 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?

With no annotations to rely on, the description carries the full burden of disclosing behavioral traits. However, it only states the action ('build a knowledge graph') without clarifying whether this is a read-only operation, what side effects exist, or what the return structure looks like. The term 'build' could imply a mutation, but this is left ambiguous.

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, with no redundant content. It front-loads the primary function, then adds the use case and the differentiation from the sibling tool. Every word contributes to clarity.

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 hint at what the tool returns. It does not mention the result format (e.g., nodes, edges, graph object) nor any error or edge-case behavior. Given the complexity of building a knowledge graph, the description is insufficient for an agent to fully anticipate the tool's output.

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 75% of parameters with descriptions, but the tool description adds no additional insight about any of them. The missing description for agent_id is not compensated for by the prose. The description does not clarify acceptable values, defaults, or interactions between parameters, leaving the semantics solely 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 clearly states the tool's function (build a knowledge graph using embedding similarity), its intended use case (explore concept connections), and explicitly differentiates it from a sibling tool (dakera_graph_traverse) for BFS traversal of existing graphs.

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

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

It provides explicit guidance on when to use this tool ('Use to explore how a concept connects to stored knowledge') and when to use an alternative ('For BFS traversal of an existing linked graph use dakera_graph_traverse'). No ambiguity remains.

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

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

The description discloses the output behavior in detail: it returns schemas for found tools and a not_found list for unrecognized names. This transparency about both success and failure cases exceeds typical descriptions and is fully transparent for a read-only 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?

The description is concise, consisting of two sentences that directly state the function, usage timing, and output behavior. Every word serves a purpose, with no extraneous 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?

For a simple tool that fetches schemas, the description provides all necessary context: what it does, when to use it (after discover_tools), and what it returns (schemas plus not_found list). No additional information is needed for an agent to invoke 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?

The only parameter 'tools' is described as 'Tool names to load schemas for', which clearly explains its purpose and format. The schema description is comprehensive, and the tool description adds no ambiguity. Coverage is 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 the tool fetches the full inputSchema for one or more named tools, using specific verb 'Fetch' and resource 'tools'. It also distinguishes itself from siblings by specifying 'Use after dakera_discover_tools' and describing the return behavior.

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

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

The description explicitly instructs when to use the tool ('Use after dakera_discover_tools'), providing clear timing guidance. It also implies it is the appropriate tool for loading schemas, while other tools like search or extract serve different purposes.

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 and does add real behavior: default top_k=5, session neighbours placed in context_memories outside the top_k count, and include_associated expanding one KG hop. It omits read-only confirmation, pagination/result-size behavior, and what happens when a query matches nothing.

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 dense sentences, front-loaded with the core semantic-recall action and the important top_k consequence before the sibling redirect. Minor phrasing like 'score may rise' is slightly cryptic, but there is no filler.

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

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

For a 12-parameter tool with no annotations and no output schema, the description covers the most consequential semantics (top_k default, neighbour placement, KG expansion, ranking field). It still leaves a third of parameters and the result structure to be inferred, so it is adequate but not 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 67%, and the description compensates by disclosing the top_k default of 5 and the role of include_associated and neighborhood_mode ('session neighbours go in context_memories'), which the schema does not fully convey. It says nothing about since/until/min_importance/lang, but those are documented 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 states a specific verb+resource ('Semantic recall: the top_k memories closest to a query') and specifies the narrowing dimensions (tags, memory_type, session_id). It distinguishes itself from dakera_recall_associated, but does not differentiate from sibling semantic/hybrid/fulltext search 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?

It explicitly routes the agent to dakera_recall_associated for deeper KG traversal and explains include_associated's role, which is useful. However, it never states when to prefer this over dakera_search, dakera_hybrid_search or dakera_fulltext_search, leaving the main selection decision to inference.

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

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

No annotations are provided, so the description carries the full behavioral burden. It implies a read-only search and notes the filters are 'optional', but says nothing about ordering/ranking, default top_k behavior, result limits, or permissions — significant gaps for an unannotated retrieval 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 tight sentences with zero waste; the capability statement is front-loaded and the routing rule follows immediately.

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?

Purpose and sibling routing are complete and params are well covered by the schema, but with no output schema and no annotations the description leaves return format, ranking, and default result count unaddressed for a 6-parameter retrieval 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 83%, so the schema already documents nearly all parameters. The description only restates the tag and memory_type filters, adding no syntax, format, or defaulting detail beyond what the schema provides.

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

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

States a specific verb+resource ('Semantic search') and adds the differentiator that it supports optional tag and memory-type pre-filters. It explicitly names a sibling (dakera_recall), so an agent can separate the two without opening schemas.

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

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

Gives a clear routing rule: 'Prefer over dakera_recall when results must be constrained by tag or type alongside the semantic match.' It does not address the other search siblings (dakera_fulltext_search, dakera_hybrid_search), so the guidance is directional rather than exhaustive.

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

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

With no annotations, the description carries the full burden and does disclose real behavior: an already-ended (idle) session is not destroyed by this call and the supplied summary is silently discarded. That conditional, no-op-on-idle semantics is exactly what an agent needs before calling. It omits whether summary persistence is permanent or whether callers need auth.

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

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

Three short sentences, front-loaded with the action, then the trigger, then the edge-case caveat. Nothing is repeated from the name or schema and nothing extraneous is included.

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

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

For a two-parameter tool with full schema coverage, no output schema, and no nested objects, this is nearly sufficient: action, timing, and idle-session behavior are all present. Only the success-path outcome and any permission requirements are left unstated.

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, but the description adds genuine semantics the schema cannot: the summary's persistence is conditional on the session still being live. That is meaningful meaning beyond "Optional session summary".

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?

"Close a session with an optional summary" names a specific verb and resource, and the pairing with dakera_session_start is inferable from the session lifecycle. It stops short of naming the sibling explicitly, so an agent must rely on the name prefix to pair start/end.

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

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

"Call at run end, even on error" gives a clear trigger condition, including the error path that agents commonly mishandle. It also covers the degenerate case where the server already ended the session, though it names no alternative tool or prerequisite.

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 the full behavioral burden, and it does disclose one valuable trait: idle sessions are auto-ended after 4 h by default. It omits other important behaviors — whether calling again for the same agent_id creates a duplicate session, what the call returns, and any permission or concurrency 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 compact clauses with zero filler; the core purpose is front-loaded and the lifecycle caveat follows immediately. Every phrase contributes 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?

With no annotations and no output schema, the description should say more about the return shape (presumably the session_id) and what happens on repeated calls. It implies session_id is returned and covers lifecycle, but leaves the required agent_id and duplicate-session semantics unexplained.

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 67%, with agent_id (the required param) undocumented in both schema and description, while metadata is covered by the schema and idle_timeout_secs gets the useful extra detail that 0 means never. The description adds the 4 h default behavior but does not explain the required identifier.

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

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

States a specific verb and resource ('Open a session') and immediately explains its function relative to siblings: the session_id groups memories you store, which distinguishes it from dakera_store/dakera_session_end. It stops short of naming the counterpart tool explicitly, but the agent can place it correctly.

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 linkage to storing memories implies this is a prerequisite step before dakera_store, and the idle-timeout note hints at lifecycle expectations. However, there is no explicit 'use this when...' or 'do not use if a session already exists' guidance, and no mention of how it relates to dakera_session_end.

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 mentions decay and the importance scale but omits critical behavioral details: whether this operation is idempotent, what permissions are needed, how conflicts are resolved, whether it returns the ID, or the implications of expiry fields.

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?

Efficiently front-loaded with two sentences. The first states purpose, the second provides a key parameter default and guidance. No wasted words, though it could be slightly more structured with explicit usage notes.

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 11 parameters, no output schema, and no annotations, the description is incomplete. It covers purpose and one parameter but neglects critical behavior for a 11-param mutation tool: return values, error handling, alternative tools, and the semantics of fields like expires_at, ttl_seconds, and memory_type.

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 73%, so the schema already documents most parameters including importance (0.0-1.0). The description adds context about importance defaults and recommended values, which is useful but limited to one parameter. Baseline 3 is appropriate given the high schema coverage.

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

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

States a specific verb (persist) and resource (memory) with examples of memory content types (fact, decision, context). This clearly distinguishes it from read-oriented siblings like dakera_recall and dakera_search, though it doesn't name a specific alternative to avoid.

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 dakera_forget or dakera_search. The description implies usage through its content examples but offers no exclusion criteria or alternative routing.

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