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

Annotations already declare readOnlyHint=true, indicating a safe read operation. The description adds a valuable behavioral trait: 'without calling a model', which tells the agent this is deterministic extraction with no external model dependency. This goes beyond the annotation and helps set expectations for performance and side effects. It does not contradict any annotations.

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 primary action ('Extracts...') and lists the outputs. There is no filler, and every word contributes to understanding. It is concise without sacrificing 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?

For a tool with a single parameter and no output schema, the description covers the core purpose and lists the extracted entity types, which imply the return structure. It does not describe error handling or the exact output schema, but for a simple read-only tool, this is sufficient. The 'without calling a model' detail also addresses a potential performance concern. Overall, an agent has enough context to call 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?

There is only one parameter, conversationId, and the schema provides its type (string) and format (uuid). The description mentions 'one stored conversation' which implicitly ties the parameter to that conversation, but it does not explicitly describe the parameter's role. With schema_description_coverage at 0%, the description offers minimal compensation, though the meaning is obvious from context. A score of 3 reflects adequate but not rich semantics.

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 'extracts' and the resource 'one stored conversation', and enumerates the specific output types (decisions, open questions, action items, cited facts, topics). It also adds a distinguishing detail 'without calling a model', which sets it apart from any AI-based analysis siblings. This is specific and 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?

The description implies the tool is for analyzing a single conversation (from one stored conversation) and that it produces structured extractions, but it does not explicitly say when to use it over alternatives like get_conversation or search_conversations, nor does it mention exclusions (e.g., when you need raw text or multiple conversations). The usage context is implied but not fully articulated.

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 annotations already indicate a non-read-only, non-idempotent mutation. The description adds the context of thread continuation but does not elaborate on side effects, failure modes, or rate limits. Since annotations cover the core behavioral cues, the description provides marginal extra 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, focused sentence with no redundancy. It packs the core action and a motivating use case efficiently.

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?

It provides enough context for an agent to understand the typical use case (appending messages from a second client). It does not cover edge cases like missing conversation or message validation, but those are partially addressed by the schema. Overall, it is suitably complete for the tool's simplicity.

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 never names or explains the parameters. It refers to 'new turns' and 'existing conversation' but does not clarify that conversationId is the target identifier or that messages is an array of objects with role/content fields. The schema is left to carry all parameter meaning, but schema coverage is 0%, so the description fails to compensate.

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 (adds new turns), the target resource (existing conversation), and the purpose (keeping a thread unified across clients). This distinguishes it from siblings like save_conversation or import_conversation.

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

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

It gives a concrete usage scenario ('how a thread continued in a second client stays one thread') that implies when to use this tool. However, it does not explicitly mention alternatives or when not to use it, so it falls short of a perfect score.

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 indicates a read-only behavior consistent with the readOnlyHint annotation. However, it does not mention default behavior for the limit parameter, potential errors, or any other side effects.

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

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

The description is a single, concise sentence that efficiently conveys the core functionality without unnecessary elaboration.

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 lacks important context such as how 'recent' is defined, the role of the limit parameter, or output format. Given the simple schema, more detail 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?

The description does not explain the meaning or effect of the 'limit' parameter. The schema provides type and range, but no additional context is added by the description.

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 ('Returns') and the resource ('recent LNKZ events') with specific event types. It is distinct from sibling tools, though it does not explicitly differentiate itself.

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 is provided on when to use this tool versus alternatives. The description only states what it does, not the appropriate context or selection criteria.

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 explains what the graph contains and the kind of analysis it supports, going beyond the simple readOnlyHint annotation. It does not mention side effects, but it also does not contradict the read-only annotation.

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 core action, and uses only two sentences. It avoids unnecessary detail while still conveying the tool's purpose and outputs.

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 the graph's node/edge types and high-level value, but it lacks any explanation of the five parameters and does not describe the return format. Since there is no output schema, this leaves some gaps for an agent deciding how to invoke the 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?

The schema has five parameters with 0% description coverage, and the description does not mention any of them. An agent cannot infer the meaning or effect of limit, maxTopics, conflictThreshold, duplicateThreshold, or minTopicConversations from this description.

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 a specific action ('Builds a graph') and a specific resource ('stored conversations'), and distinguishes it from search by noting it answers questions search cannot. It differentiates well from sibling tools like search_conversations and find_conflicts.

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 when to use it: when corpus-level relationships and insights are needed, and contrasts with search. It does not explicitly name sibling alternatives such as find_conflicts or find_duplicates, but the intent is reasonably 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?

The description implies a read-only summarization behavior and lists what the packet includes. The readOnlyHint annotation already covers side effects, so no contradiction exists and the added output details support 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 two compact sentences, begins with the core action, and contains no filler or redundant wording.

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?

It explains the high-level output and use case but lacks parameter semantics and output format. Since there is no output schema and params are only partially inferable, an agent would need more details to invoke it with confidence.

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 five parameters but has zero descriptions, and the description never names or explains query, budgetTokens, conversationIds, includeExternal, or maxConversations. 'Token-budgeted' and 'stored conversations' only hint at two of them.

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 ('assembles') and names the deliverable ('token-budgeted brief') plus its contents (decisions, open questions, action items, excerpt, contradictions). It also positions the tool against the common alternative of pasting a transcript.

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

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

It gives a concrete usage signal: use instead of pasting a whole transcript. It does not enumerate when each sibling might be preferable, but the stored-conversation summary use case 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?

Annotations already declare readOnlyHint=false and idempotentHint=false, indicating a mutating, non-idempotent operation. The description adds that it stores a new conversation and links it back to the original, which is useful. However, it does not disclose potential side effects like token invalidation or whether the original handoff remains usable, leaving gaps in behavioral transparency beyond the annotations.

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, concise sentence that leads with the primary action ('Redeems a handoff') and flows into the significant consequence ('stores the continuation as a new conversation'). It is front-loaded and avoids fluff. It could be slightly more structured, but overall it is appropriately compact for its lack of parameter details.

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 five parameters (three required) and zero schema coverage, the description is far from complete. It omits any explanation of what the parameters mean, how the tool behaves in edge cases, or what the return value or errors might be. The absence of an output schema heightens the need for behavioral detail, which is missing. The only complete element is the high-level flow of redeeming and storing.

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 description coverage is 0%, meaning the description provides no information about the token, provider, messages, app, or title parameters. Since the description does not compensate for this absence, an agent cannot infer the meaning or format of the parameters. The schema constraints alone do not explain semantics (e.g., what format token is, what provider refers to, how messages are structured).

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: redeems a handoff and stores the continuation as a new conversation linked to the original. This distinguishes it from a generic 'redeem' operation by specifying the storage behavior. However, it does not explicitly contrast with sibling tools like redeem_handoff, so it falls short of full differentiation.

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 redeem_handoff or save_conversation. It lacks explicit context about the intended use case (e.g., 'use this when you want to continue a conversation from another client'). The usage scenario is only implied by the name and title.

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

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

Annotations declare readOnlyHint=false and idempotentHint=false, indicating a mutating, non-idempotent operation. The description adds valuable context: the link is expiring, use-limited, and can redact secrets before leaving. This goes beyond the annotations without contradicting them, though it does not cover side effects or failure modes.

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 fluff. The core action is front-loaded ('Mints an expiring, use-limited bearer link'), and the optional redaction detail is concise. Efficient and well-structured.

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

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

Despite 6 parameters and no output schema, the description does not explain what the tool returns (e.g., a link string or object), nor does it detail the parameters. It omits crucial details like how the link is used for redemption, required auth, or consequences of reaching maxUses or TTL. This is incomplete for an agent to invoke correctly without external knowledge.

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 0%, so the description must compensate for parameter meanings. It does not. It only hints at redaction (redact parameter) but fails to explain conversationId, note, maxUses, ttlMinutes, or audience. The schema itself lacks per-property descriptions, leaving the agent without adequate guidance for parameter semantics.

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 creates a handoff link (bearer link) that is expiring and use-limited, and explicitly mentions redaction. It distinguishes itself from siblings like redeem_handoff, revoke_handoff, and continue_handoff by focusing on creation.

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 primary use case (creating a portable context link for another party) and mentions an optional redaction feature. However, it does not explicitly name alternatives or state when not to use this tool, nor does it reference sibling tools for comparison. Context is clear but lacks explicit 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?

Annotations already declare destructiveHint=true and readOnlyHint=false, and the description adds the permanence ('permanently removes') and the specific scope (messages and handoffs). This goes beyond annotations by clarifying exactly what is destroyed. No contradiction.

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, front-loaded with the action, zero wasted words. It conveys the essential information efficiently.

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 delete with one parameter and no output schema, the description is sufficient. It mentions permanence and the items removed. It does not mention permissions or side effects beyond what is stated, but these are not critical for a basic 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?

The schema has one parameter 'id' with no description (0% coverage). The description does not explicitly discuss the parameter, but it is self-evident from the tool name and description that 'id' identifies the conversation. The description adds minimal value beyond the schema, so 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 states a specific verb ('removes') and resource ('conversation'), and clarifies the scope by listing what gets removed (messages and handoffs). This distinguishes it from siblings like save_conversation or get_conversation.

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 alternatives. It does not mention irreversibility or any prerequisites, nor does it suggest when to prefer it over other conversation-related 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?

Annotations include readOnlyHint=true, so the safe, non-destructive nature is already known. The description adds behavioral context by enumerating the output formats and asserting that 'Every format re-imports', which is a key property beyond the annotation. It does not mention response details (e.g., whether the output is a string or file), but given the read-only hint and simple nature, this is adequate. No contradictions with annotations.

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 with no filler. The first sentence front-loads the core action and enumerates formats; the second adds the re-importability trait without redundancy. Every clause earns its place, and the structure is tight and 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?

For a tool with only two parameters and no output schema, the description covers the essential usage context: what formats are available and that the export is round-trippable. It could explicitly state that the tool returns the exported content as a string, but given the tool's name and purpose, that is largely inferred. The description is complete enough for an agent to select and invoke the tool 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 description coverage is 0%, so the description must illuminate parameters. It adds meaning to the 'format' parameter by expanding each enum value (e.g., 'Markdown transcript', 'chat-completions message array'), which goes beyond the raw enum names. However, it does not provide additional context for 'conversationId' beyond what the schema already implies (a UUID identifier). The description partially compensates for the coverage gap but could clarify the purpose of the id more explicitly.

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: 'Writes a stored conversation back out in another client's format' and lists all supported formats (Markdown, brief, chat-completions, etc.). This distinguishes it from siblings like import_conversation (opposite direction) and get_conversation (likely native format). The verb 'writes...back out' plus the resource 'conversation' and the explicit scope of format conversion make the 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?

The description implies usage for cross-client exports via 'another client's format' and notes that 'Every format re-imports', suggesting interoperability. However, it does not explicitly state when to use this tool over alternatives (e.g., use get_conversation for native retrieval, import_conversation for incoming). No 'when-not-to-use' guidance or comparison to siblings is provided, so the agent must infer the appropriate 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?

Annotations already declare readOnlyHint=true, so the bar is lower. The description adds valuable context beyond the annotation by explaining that the tool is a heuristic that only surfaces candidates for review and does not adjudicate disagreements—this tells the agent the output is advisory, not authoritative, which is critical for downstream use. No contradictions with annotations.

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, no filler. The core function is front-loaded in the first sentence, and the second sentence adds a crucial caveat about its heuristic nature. Every word earns its place.

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

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

The tool is moderately complex (compares cross-conversation decisions) but has no output schema and no explanation of parameters. The description does not define 'recent conversations,' does not clarify what the threshold represents, and omits any mention of the output format (e.g., pairs with confidence scores). With only the readOnlyHint annotation and this sparse description, an agent would struggle to set parameters meaningfully or interpret results confidently.

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 0% for the two parameters, and the description provides zero explanation of what 'limit' or 'threshold' mean. The schema only gives numeric ranges/defaults but no semantic meaning—an agent cannot infer that threshold likely refers to a disagreement confidence level or how limit caps pairs returned. The description fails to compensate for this gap.

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 ('Compares'), a clear resource ('decisions across recent conversations'), and the output ('reports pairs that appear to disagree'). It also distinguishes itself from find_duplicates by focusing on disagreements rather than similar items, making its purpose unambiguous even without inspecting 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?

The description implies usage for initial conflict review by noting it 'surfaces candidates for review, it does not adjudicate them,' but it never explicitly states when to choose this over sibling tools like analyze_conversation or find_duplicates, nor does it mention any exclusions. The heuristic nature is clear, but the guidance is indirect rather than prescriptive.

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 annotation readOnlyHint=true already indicates a read-only operation, and the description does not add behavioral details beyond that. It does not mention output format, performance implications, or any potential side effects, but the read-only nature is consistent.

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-formed sentence that efficiently conveys the tool's function without unnecessary verbosity. It is appropriately concise and easy to parse.

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?

While the tool's purpose is clear, the description lacks details about the output structure (e.g., whether it returns conversation IDs, scores, or grouped results). Given the absent output schema, this omission leaves some ambiguity about what the caller 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?

The input schema defines limit and threshold with ranges and defaults, but the description does not explain their meaning. For instance, 'threshold' likely refers to a similarity threshold, but this is not stated. The schema alone does not convey the semantic role of these 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 the tool's purpose: it reports conversations with heavily overlapping transcripts, specifically for cases where the same chat is relayed through multiple clients. This distinguishes it from sibling tools like search_conversations or list_conversations.

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 concrete scenario ('whenever the same chat is relayed through more than one client') that signals when to use this tool. However, it does not explicitly contrast it with alternatives or mention any conditions that would make other tools more appropriate.

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

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

Annotations declare readOnlyHint: true, covering safety. The description adds value by specifying exactly what is loaded (messages, lineage, decisions, transcript), which is beyond the annotation. It does not disclose potential performance or size implications, but the read-only nature is already disclosed.

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, well-structured sentence that front-loads the core action ('Loads a stored conversation') and efficiently lists the contents. No redundant or unnecessary information, every word earns its place.

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

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

For a simple get-by-id tool with no output schema, the description lists the return contents (messages, lineage, decisions, transcript), which is adequate. It does not mention error cases (e.g., not found) but given the read-only annotation and simplicity, this is acceptable.

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 0%, and the description does not mention the 'id' parameter or its role as the conversation identifier. While the parameter is inferable from its name and format, the description fails to compensate for the lack of schema documentation, leaving the agent to guess its meaning.

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 'Loads' with the resource 'stored conversation' and lists the specific contents (messages, lineage, decisions, Markdown transcript). This distinguishes it from siblings like list_conversations (listing only) and search_conversations (searching), making the tool's 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?

The description implies usage for retrieving a single conversation's full content but does not explicitly state when to prefer this over siblings like list_conversations or search_conversations. No exclusions or alternative conditions are provided, 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.

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

The description does not mention side effects such as whether a new conversation is created, whether existing data is overwritten, or whether dryRun prevents mutation. With no output schema, the caller also cannot know what is returned.

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, compact sentence that covers the core function and format flexibility 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?

No return type, error behavior, size limits, or relationship to other tools is described. Given four parameters and no output schema, the description leaves too many operational questions unanswered.

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 descriptions cover 0% of parameters. Only format is vaguely addressed by the mention of automatic detection; payload, tags, and dryRun are undefined, despite the enum on format giving some implicit options.

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 normalizes transcripts from several named sources into portable conversations, and the title indicates importing. It could be more explicit about whether it saves the result or just validates/prepares it.

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 is provided for when to use this tool versus siblings like save_conversation or export_conversation. The description mentions format detection but does not clarify typical use cases or 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?

The annotation readOnlyHint=true already indicates a read-only operation, so the description does not need to restate that. It adds a useful detail: the tool reports the reason for disabled connectors, which is not covered by annotations. However, it does not disclose other behaviors like output format or potential delays. Given the annotation coverage, this is an adequate but not exceptional disclosure.

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, succinct sentence that front-loads the core purpose. It has no filler or redundant content, and every word contributes to clarity. It is an excellent example of concise, structured definition.

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 no parameters and no output schema, the description sufficiently conveys its function. It explains what is shown (configured/disabled with reason), which is the core need. It could potentially mention the output structure (e.g., 'returns a list'), but the description already implies a list of statuses. Given the simplicity, it is nearly 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?

There are zero parameters and schema description coverage is 100% (vacuously). Per the rubric, 0 parameters earn a baseline of 4. The description need not explain parameters since none exist, and it provides no additional parameter-related semantics. The baseline 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 'shows which context sources are configured and which are disabled, with the reason.' This is a specific verb (shows) and resource (context sources/connectors), and it distinguishes from sibling list tools (e.g., list_conversations, list_handoffs) by focusing on connectors. The purpose is unambiguous and self-contained.

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 any guidance on when to use this tool versus alternatives, such as when to prefer list_connectors over list_publish_targets or list_handoffs. It does not mention exclusions or context for selection. The reader must rely on the tool name to infer usage, which is insufficient given the many sibling list 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?

Annotations already declare readOnlyHint: true, so the description only needs to add behavioral context. It adds ordering (newest first) and filter options, but does not disclose pagination behavior, return format, or whether filters are exact matches. It supplements the annotation with some useful context without contradicting it.

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: 'Lists stored conversations newest first, optionally filtered by provider, tag, or participant.' Every word earns its place, and the primary behavior is stated first with filters appended.

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 five optional parameters, no output schema, and zero parameter descriptions, the description is too sparse. It does not explain pagination (limit/offset), filter matching behavior, return structure, or how it relates to search_conversations. An agent would need to inspect sibling behavior or make assumptions to paginate 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 description coverage is 0%, so the description must compensate. It names three of the five parameters (provider, tag, participant) as filters, but omits limit and offset entirely, and does not explain their purpose (pagination) or the matching semantics. It adds partial meaning but leaves gaps for the pagination-related 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 the verb (lists), the resource (stored conversations), the ordering (newest first), and optional filters (provider, tag, participant). It distinguishes from get_conversation (single) and search_conversations (search) without needing to name them explicitly.

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

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

The description implies this is the listing tool with optional filters, but it does not explicitly state when to use this versus search_conversations or get_conversation. No exclusions or alternatives are mentioned, leaving the agent to infer that list is for browsing and search is for querying.

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?

Beyond the readOnlyHint annotation, the description adds a concrete behavioral detail: 'Tokens are never returned.' This clarifies an important security aspect not evident from the annotation alone. No contradictions exist between the description and annotations.

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 brief and direct, using a single sentence to convey the core functionality and a second for an important caveat. There is no 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?

While the description accurately captures what the tool does, it does not explain how it fits into the broader handoff workflow or differentiate it from related tools. Given the existence of multiple handoff-related siblings, some contextual guidance 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?

The only parameter, conversationId, has no description. The schema provides its type (uuid) and optionality, but the description adds no explanation of its role or effect, leaving the parameter's semantics entirely undefined.

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 ('Shows') and its target ('issued handoffs'), and enumerates the specific attributes returned (expiry, remaining uses, audience, revocation state). This makes the purpose unmistakable.

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 is provided on when to use this tool versus sibling tools like redeem_handoff, create_handoff, continue_handoff, or revoke_handoff. The description does not mention any conditions or contexts that would indicate its 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?

Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds context beyond those by explaining it connects to downstream servers, reads what is available, and changes nothing, plus details the LNKZ_MCP_TARGETS configuration format. It does not mention potential failure modes or latency, but it adds meaningful behavioral context.

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

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

Two concise sentences, with the primary action stated up front and configuration details following. No filler or redundancy; every sentence earns its place.

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

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

Given zero parameters, no output schema, and annotations covering read-only behavior, the description adequately explains the tool's function, configuration, and side-effect-free nature. It could optionally describe the output format, but that is not critical 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 input schema is empty (0 parameters), so there is nothing for the description to explain. The baseline for 0 parameters is 4, and the description correctly avoids inventing parameters. It does not need to compensate for any schema gaps.

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 connects to configured downstream MCP servers and lists the tools they expose, marking potential writes. This is a specific verb+resource (list tools on downstream servers), but it does not explicitly differentiate from sibling tools like list_connectors, so it misses the top score.

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 as a discovery-only read operation ('This is discovery only') but does not provide explicit when-to-use guidance or contrast with alternatives like list_connectors or prepare_publish. It leaves the agent to infer when this tool is appropriate.

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 explicitly states that the tool never sends anything, making its non-destructive and read-only nature unmistakable. It also reveals what the return payload contains (the exact call and unfillable required fields), matching the readOnlyHint annotation and going beyond it.

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 tight and efficient, using three sentences to convey purpose, behavior, and recommended follow-up action. There is no redundant or filler 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 read-only annotation and the simple parameter set, the description covers the main behavior, output contents, and side-effect expectation. It is slightly incomplete in explaining the meaning of each parameter, but overall it gives enough context to use the tool safely and 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 schema has no parameter descriptions and the description does not individually explain conversationId, target, tool, or shape. With 0% schema coverage, the description needed to compensate by explaining these parameters, but it only indirectly refers to 'conversation' and 'downstream MCP tool.'

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 a specific action: maps a conversation onto a downstream MCP tool's input schema and returns the would-be call, including missing required fields. It also explicitly distinguishes itself from actually sending by saying it never sends anything, which separates it 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?

Explains when to use it: to review a prepared payload before executing it with the downstream tool. It even instructs the agent to make the call itself if execution is desired, providing practical usage guidance. It does not explicitly name sibling tools, but the guidance is clear enough.

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 does not disclose side effects such as token invalidation or state changes. Since readOnlyHint is false and idempotentHint is false, the tool may modify state, but this is not mentioned.

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, two sentences, and directly states the tool's purpose without redundant 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?

The description mentions what is loaded but lacks details about output format, return value, or any prerequisites (e.g., whether the token must be created first). Given the sibling tools, some context is missing for effective 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 single parameter 'token' is not explained in the description. The schema provides constraints (min/max length) but no semantic meaning, so the agent has no context on what the token represents or how it is used.

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 (loads), the object (portable packet), and the condition (unexpired LNKZ handoff token), and specifies the contents (transcript, decisions, questions). It is distinct from sibling tools like create_handoff or list_handoffs.

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 versus alternatives. It does not mention scenarios like redeeming a token after creation or how it differs from continue_handoff or revoke_handoff.

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 says 'Immediately invalidates', which indicates a state change and implies non-read-only behavior. The annotations already specify readOnlyHint=false and idempotentHint=true, so the description adds a small amount of context (immediacy, the fact that the link was already shared) but does not detail side effects, reversibility, or failure modes.

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, concise sentence that directly conveys the core action without any unnecessary words or clutter.

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 is minimal but adequate for a simple operation. However, it does not mention what happens if the handoff does not exist or is already revoked, nor does it indicate any return value or error conditions. Given the low complexity (one parameter, no output schema), this is a moderate 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?

The only parameter is handoffId, but neither the schema nor the description provides any details about it. The schema has no description for the parameter (coverage 0%), and the description does not compensate by explaining what handoffId refers to or any constraints. The name is self-explanatory, but according to the criteria, the description must compensate for missing schema coverage and does not.

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: it invalidates a handoff link that has already been shared. The verb 'invalidates' is specific and the resource is identified. The tool name 'revoke_handoff' further reinforces the purpose, and it is distinct from sibling tools like 'create_handoff' or 'continue_handoff'.

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 explicitly state when to use this tool versus alternatives, nor does it mention any prerequisites or conditions. While the purpose is self-evident, there is no guidance on when to choose revoke_handoff over other handoff-related 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?

Annotations already state readOnlyHint=false and idempotentHint=false, so the agent knows this is a non-idempotent write. The description adds 'normalized' and purpose but does not disclose side effects like whether it creates a new record, overwrites based on id, or what happens to lineage. For a write tool with zero additional behavioral disclosure, this is a significant 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, efficient sentence without waste. The main verb is front-loaded. It is concise, though almost too skimpy given the tool's complexity; but as a measure of conciseness and structure, it earns a 4.

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 9 parameters with nested objects, no output schema, and sparse annotations, the description is far from complete. It lacks any mention of required fields, examples, or semantics of the source object. An agent cannot reliably construct a correct request based solely on this description and the schema.

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

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

Schema description coverage is 0% and the description mentions none of the 9 parameters. It does not explain what 'title', 'source', 'messages', 'lineage', or 'metadata' mean, nor which are required. With complex nested objects and required fields, the agent has no semantic guidance beyond the raw JSON 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 ('Stores') and resource ('normalized conversation'), plus the intended downstream uses (search, package, hand off). It is clear and distinguishes itself from retrieval/list tools, but it does not explicitly differentiate from the sibling import_conversation, which could also imply storing conversations, so it loses a point.

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?

There is no explicit guidance on when to use this tool versus alternatives. It does not say 'use this when' or 'instead of import_conversation', nor does it mention any prerequisites or conditions. The phrase 'from any LLM client or device' hints at breadth but gives no decision criteria.

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

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

Annotations already provide readOnlyHint=true and openWorldHint=true, so the description doesn't need to cover safety. It adds a valuable behavioral detail: 'reporting per-source failures instead of hiding them,' which is not in the annotations and helps the agent set expectations for error handling. No contradiction with annotations.

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 states the scope and a key behavior without fluff. It is concise and easy to parse. However, it omits any parameter details, which would improve completeness, but the structure itself is 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 the tool has 4 parameters (with one required), no output schema, and no parameter details in the description, the definition is incomplete. An agent cannot deduce how to specify sources or exclude sources, what the limit does, or how to handle the query. The description should at least mention the query parameter and suggest the sources/excludeSources options to be minimally usable.

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 0% — the description does not mention any of the four parameters (query, limit, sources, excludeSources). With no schema explanation, the description must compensate, but it provides no guidance on how to use these parameters, leaving the agent without necessary context for correct invocation.

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 LNKZ conversations plus all configured connectors in a single call, and explicitly mentions the unique behavior of reporting per-source failures. This distinguishes it from siblings like search_conversations, which likely only search LNKZ conversations.

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: use this when you need a multi-source search across all connectors. It clearly lists the connectors included (Slack, Jira, Figma, etc.), which helps an agent understand scope. However, it does not explicitly state when NOT to use this or mention alternatives like search_conversations for single-source queries, so it lacks direct exclusion 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?

The readOnlyHint annotation already declares this as a read-only operation, and the description's 'search' verb aligns with that. The description adds the behavioral trait of 'ranked' results, which implies ordering by relevance, but provides no detail on pagination, result shape, or whether it returns full conversation objects or summaries. With annotations covering the safety profile, the description adds only marginal behavioral context.

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

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

A single, front-loaded sentence states the core purpose without any filler. It efficiently conveys the action, resource, and scope. No redundant information, and the structure allows an agent to grasp the tool's function 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?

For a simple search tool with two parameters and no output schema, the description is adequate but leaves gaps. It does not describe the return format (e.g., whether results include conversation IDs, metadata, or full messages), which could be critical for downstream processing. It also doesn't mention ranking criteria beyond 'ranked'. While the absence of an output schema heightens the need for return-value disclosure, the description remains functional for basic 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?

With 0% schema description coverage, the description must compensate for parameter meaning. It does so for the 'query' parameter by specifying the fields it matches (title, summary, participant, tag, message content), which is useful. However, it provides no elaboration on 'limit' beyond what the schema already shows (default, min, max). The description adds some value but does not fully cover all parameter nuances.

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 a specific action (search) on a specific resource (saved chats/conversations) and enumerates the searchable fields (title, summary, participant, tag, message content). It differentiates itself from siblings like get_conversation (retrieval) and list_conversations (listing) by focusing on ranked full-text 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 implies when to use the tool (when searching across conversations) but provides no explicit guidance on alternatives or exclusions. It doesn't mention that search_context might be more appropriate for context-specific searches, nor does it state that this is not for retrieving a single conversation. The usage context is clear but underdeveloped.

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 readOnlyHint annotation already establishes that this is a safe read operation. The description reinforces this by stating it 'counts' data, which is consistent with read-only behavior. It adds no further behavioral details (e.g., pagination or performance), but the annotation covers the critical safety aspect, so this 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 a single sentence that front-loads the action ('counts') and then lists the specific items. It contains no filler or redundancy and is immediately scannable.

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 no parameters and a read-only annotation, the description sufficiently communicates its purpose. While it does not describe the return format, the scope is clear enough for an agent to call it without ambiguity, and it is consistent with sibling tools that serve different specific functions.

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 schema is complete and there is nothing for the description to add. Per calibration, a baseline of 4 is appropriate for tools with no parameters, as the description has no obligation to clarify parameter usage.

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 'counts' and explicitly specifies the resources it aggregates: stored conversations, messages, providers, and active handoffs. This clearly distinguishes it from sibling tools like list_conversations or list_handoffs, which likely return detailed records rather than aggregate counts.

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?

There is no explicit guidance on when to use this tool versus alternatives. The description implies it for statistics/aggregate counts, but it does not name sibling tools or provide exclusions (e.g., 'use list_conversations for details'). Context is present but not explicit.

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