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

With no annotations provided, the description carries the full burden and effectively discloses key behavioral traits: it describes the action ('inject'), the effect ('stored as a message and included in the next completion call'), and the timing ('before the next message send'). It lacks details on permissions or error handling, but covers essential operation context.

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

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

The description is front-loaded and efficiently structured in two sentences: the first states the purpose and usage, the second explains the behavioral outcome. Every sentence adds value without redundancy, making it appropriately concise.

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

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

Given the tool's moderate complexity (3 parameters, no output schema, no annotations), the description is mostly complete: it clarifies the tool's role, usage timing, and behavioral effects. However, it could improve by mentioning potential side effects or error cases, though the lack of output schema is mitigated by the clear description of the injection process.

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

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

Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds minimal value beyond the schema by implying the context parameter's purpose ('external context'), but does not provide additional syntax or format details. This meets the baseline for 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?

The description clearly states the tool's purpose with specific verbs ('inject external context') and resources ('into a session'), and distinguishes it from siblings by specifying it prepares content 'before the next message send', unlike chat_message_send or chat_search which handle different actions.

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

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

The description provides clear context for when to use this tool ('before the next message send') and examples of what to inject ('Aiana memory recall, documentation snippets, or runtime state'), but does not explicitly state when not to use it or name alternatives among siblings like chat_message_send.

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 burden and does well by disclosing key behaviors: it performs ping operations (implying read-only, non-destructive checks), returns latency metrics, and serves as a pre-message verification step. It doesn't detail error handling or rate limits, but covers the core functionality adequately.

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 zero waste: the first states the action and output, the second provides usage context. It's front-loaded with the core purpose and efficiently structured, earning its place without redundancy.

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

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

Given the tool's low complexity (0 parameters, no output schema, no annotations), the description is complete enough for its diagnostic purpose. It explains what it does, when to use it, and the return value (latency for each service), though it could note the format of the latency data (e.g., in milliseconds) for slightly better 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 tool has 0 parameters with 100% schema description coverage, so the schema already fully documents the inputs. The description adds no parameter-specific information, which is fine since there are none. A baseline of 4 is appropriate as it doesn't need to compensate for any 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 specific action ('Ping Anthropic and Qdrant services') and the resource ('services'), with a distinct purpose of verifying operational status before sending messages. This differentiates it from sibling tools focused on chat operations like message sending or session management.

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 this tool ('to verify the app is operational before sending messages'), providing clear context for its application. It implies an alternative (not using it could risk sending messages when services are down), though it doesn't name specific sibling alternatives, which is acceptable given its unique diagnostic role.

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 burden. It discloses that the tool returns messages in chronological order and supports pagination, which are useful behavioral traits. However, it lacks details on permissions, rate limits, error conditions, or what the return format looks like (e.g., message structure), leaving gaps for a tool with no 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?

The description is a single, efficient sentence that front-loads the core action ('List messages in a session with pagination') and adds a key behavioral detail ('Returns messages in chronological order'). There is no wasted wording, making it highly concise 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?

Given no annotations and no output schema, the description is moderately complete for a read-only list tool. It covers the basic purpose and pagination behavior but omits details like response format, error handling, or usage context relative to siblings. This is adequate but has clear gaps in providing full operational context.

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

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

Schema description coverage is 100%, so the schema fully documents parameters like 'sessionId' as a UUID and 'limit'/'offset' for pagination. The description adds no additional meaning beyond the schema, such as explaining how pagination works in practice or constraints on parameter values, resulting in the baseline score.

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

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

The description clearly states the verb 'List' and resource 'messages in a session' with the additional detail 'with pagination', making the purpose specific. However, it doesn't explicitly differentiate from sibling tools like 'chat_search' or 'chat_session_get', which might also involve message retrieval, so it doesn't reach the highest 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 provides no guidance on when to use this tool versus alternatives such as 'chat_search' for searching messages or 'chat_session_get' for session details. It mentions pagination but doesn't specify scenarios where pagination is necessary or when other tools might be 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?

With no annotations provided, the description carries full burden. It discloses key behaviors: reconstructs conversation history, stores both user and assistant messages, and returns token usage. However, it doesn't mention rate limits, authentication requirements, error conditions, or whether this is a read-only or mutating 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 perfectly concise with two sentences that each earn their place. The first sentence states the core action and context, while the second explains key implementation details and return values. No wasted words or 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?

For a tool with 3 parameters, 100% schema coverage, but no annotations and no output schema, the description is adequate but has gaps. It explains the core functionality well but doesn't address error handling, authentication, or provide examples of the return format beyond mentioning 'assistant reply with token 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?

Schema description coverage is 100%, so the schema already documents all three parameters thoroughly. The description adds minimal value beyond what's in the schema - it mentions 'message content' which aligns with the content parameter, but doesn't provide additional context about parameter interactions or usage patterns.

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 specific action ('Send a message'), the resource ('in an existing session'), and the outcome ('get a Claude response'). It distinguishes from siblings like chat_session_create (creates new sessions) and chat_message_list (lists messages) by focusing on message sending within existing sessions.

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 context by specifying 'in an existing session' and mentioning conversation history reconstruction, which suggests this is for ongoing conversations rather than starting new ones. However, it doesn't explicitly state when NOT to use this tool or name alternatives like chat_session_create for new conversations.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. While it mentions the semantic search method and optional scoping, it lacks critical details such as permission requirements, rate limits, pagination behavior, or what the output format looks like (e.g., list of messages with scores). This is a significant gap for a search tool with no 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?

The description is appropriately sized and front-loaded, with the core purpose in the first sentence and optional features in the second. Every sentence earns its place by adding essential information without redundancy.

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

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

Given the complexity of a semantic search tool with no output schema and no annotations, the description is incomplete. It adequately explains the purpose and parameters but fails to address behavioral aspects like output format, error handling, or performance considerations, which are crucial for effective tool use.

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

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

Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds marginal value by implying the optional scoping ('optionally scope to a project or specific session'), which aligns with the 'project' and 'sessionId' parameters, but doesn't provide additional syntax or format details 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?

The description clearly states the specific action ('semantic search'), resource ('all stored conversation content'), and method ('using vector similarity'). It distinguishes itself from siblings like chat_message_list (which likely lists messages without semantic search) and chat_session_get (which retrieves specific sessions rather than searching content).

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

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

The description provides clear context for when to use this tool ('finds messages relevant to the query even if exact words don't match') and optional scoping parameters. However, it doesn't explicitly state when NOT to use it or name specific alternatives among the siblings, such as chat_message_list for non-semantic listing.

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 burden. It discloses key behavioral traits: the tool performs a mutation (archive action), archived sessions are hidden from default view but remain accessible via search and can be resumed. It doesn't cover permissions, rate limits, or error conditions, leaving gaps for a mutation 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?

The description is front-loaded with the core action ('Archive a session') followed by essential behavioral context in one concise sentence. Every word earns its place with no redundancy or wasted 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?

For a mutation tool with no annotations and no output schema, the description provides adequate context on what archiving does but lacks details on permissions, return values, or error handling. It's minimally viable but has clear gaps given the complexity of a state-changing operation.

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

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

Schema description coverage is 100%, with the schema fully documenting the single parameter (sessionId as UUID). The description adds no additional parameter semantics beyond what the schema provides, so it meets the baseline of 3 without compensating further.

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 specific action ('Archive a session') and resource ('session'), distinguishing it from siblings like chat_session_delete (destructive removal) and chat_session_list (viewing). It provides precise scope by explaining what happens to archived sessions.

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 context by stating archived sessions are 'hidden from the default list but remain searchable and resumable,' suggesting when to use this versus deletion. However, it doesn't explicitly name alternatives like chat_session_delete or provide explicit when-not-to-use guidance.

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

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

With no annotations provided, the description carries the full burden. It discloses that the tool creates a new session and returns a sessionId, which is basic behavioral info. However, it misses details like whether this requires authentication, rate limits, error handling, or if the session is persistent, leaving gaps for a mutation 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?

The description is front-loaded with the core action ('Create a new chat session with Claude') and efficiently lists optional parameters in a single sentence. Every sentence earns its place by clarifying purpose and output without redundancy, making it appropriately sized 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?

Given the tool has 4 parameters with full schema coverage but no output schema and no annotations, the description is moderately complete. It covers the basic action and output (sessionId), but for a creation tool, it should ideally mention more about behavioral aspects like permissions or side effects to compensate for the lack of structured data.

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

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

Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds minimal value by listing optional parameters (system prompt, project tag, model, title) but doesn't provide additional semantics beyond what's in the schema, such as usage examples or constraints.

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 ('Create') and resource ('new chat session with Claude'), specifying it's for initiating a conversation. It distinguishes from siblings like chat_session_get (retrieve), chat_session_list (list), and chat_session_delete (remove), making the purpose specific and differentiated.

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

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

The description provides clear context by mentioning it 'Returns the sessionId to use in subsequent calls,' implying this is an initial setup step. However, it lacks explicit guidance on when to use this versus alternatives like chat_thread_fork (for branching) or chat_session_archive (for storage), and no exclusions are stated, so it's not fully comprehensive.

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 burden of behavioral disclosure. It effectively describes key traits: the action is permanent and irreversible, it deletes all messages, and it removes vectors from Qdrant (an external system). This covers destructive impact, scope, and side effects beyond the basic delete 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 extremely concise (two sentences) and front-loaded with the core action. Every sentence earns its place: the first states the action and scope, the second emphasizes irreversibility and mentions Qdrant cleanup. There's no wasted verbiage 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 destructive tool with no annotations and no output schema, the description does well by covering the irreversible nature, scope (session and messages), and external system impact (Qdrant). It could slightly improve by hinting at permissions or error cases, but it's largely complete given the tool's complexity.

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

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

Schema description coverage is 100%, with the parameter 'sessionId' clearly documented as a UUID. The description doesn't add any additional meaning about the parameter beyond what the schema provides (e.g., format details or examples). Since the schema does the heavy lifting, the baseline score of 3 is appropriate.

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

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

The description clearly states the specific action ('permanently delete') and resource ('a session and all its messages'), distinguishing it from siblings like chat_session_archive (which likely preserves data) and chat_session_get/list (which are read-only). It goes beyond just restating the tool name by specifying the scope of deletion.

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

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

The description provides clear context for when to use this tool (permanent deletion of sessions) and implies when not to use it (e.g., for archiving or temporary removal, though alternatives aren't explicitly named). It doesn't explicitly name alternatives like chat_session_archive, but the irreversible nature strongly guides usage decisions.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions retrieving 'full session details including message history,' which implies a read-only operation, but doesn't specify permissions required, rate limits, or what 'full details' entails (e.g., metadata, timestamps). For a tool with no annotation coverage, this leaves significant gaps in understanding its behavior and constraints.

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

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

The description is two sentences, front-loaded with the core purpose and followed by usage guidance. Every word earns its place without redundancy or fluff, making it highly efficient 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?

Given the tool's low complexity (1 parameter, no nested objects) and high schema coverage, the description is adequate but not complete. It lacks output details (no output schema provided) and behavioral context like permissions or data scope. For a read operation with no annotations, it should ideally clarify what 'full details' includes to aid the agent in understanding the return value.

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 100%, with the single parameter 'sessionId' documented as a 'UUID of the session to retrieve.' The description adds no additional parameter semantics beyond what the schema provides, such as format examples or sourcing guidance. Since the schema does the heavy lifting, the baseline score of 3 is appropriate.

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

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

The description clearly states the verb ('Get') and resource ('full session details including message history'), making the purpose understandable. It distinguishes from siblings like chat_session_list (which likely lists sessions) and chat_message_list (which likely lists messages without full session context). However, it doesn't explicitly differentiate from chat_session_archive or chat_session_delete, which are also session-specific operations.

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

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

The description provides clear context for when to use this tool: 'to inspect or resume a prior conversation.' This implies it's for retrieving existing sessions rather than creating new ones (chat_session_create) or listing them (chat_session_list). It doesn't explicitly state when not to use it or name alternatives, but the context is sufficient for basic differentiation among siblings.

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

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

With no annotations provided, the description carries the full burden. It discloses sorting behavior ('sorted by most recently updated first') and filtering capabilities, which adds value beyond the input schema. However, it doesn't cover critical aspects like pagination, rate limits, authentication needs, or what the return format looks like (no output schema), leaving gaps for a mutation-free but data-rich 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?

The description is two concise sentences with zero waste: the first states the core purpose, and the second adds filtering and sorting details. It's front-loaded and appropriately sized, earning its place 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?

Given 3 parameters with full schema coverage, no annotations, and no output schema, the description is adequate but incomplete. It covers purpose, filtering, and sorting, but lacks details on return values, error handling, or operational constraints. For a list tool with no output schema, more context on what 'list' returns would be beneficial, though the current description meets minimum viability.

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

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

Schema description coverage is 100%, so the schema fully documents all three parameters. The description adds minimal value by mentioning filtering by project, state, and limit, but doesn't provide additional semantics beyond what's in the schema (e.g., default values or enum details are already covered). Baseline 3 is appropriate as the schema does the heavy lifting.

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 ('List') and resource ('recent chat sessions'), making the purpose unambiguous. It distinguishes from siblings like chat_session_get (retrieve specific session) and chat_session_create/archive/delete (mutations), though not explicitly named. However, it doesn't fully differentiate from chat_search (which might also list sessions), preventing a perfect 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 for listing sessions with filtering options, but provides no explicit guidance on when to use this tool versus alternatives like chat_search or chat_session_get. It mentions filtering parameters, which suggests context, but lacks clear when/when-not statements or named alternatives.

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

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

No annotations are provided, so the description carries the full burden. It describes the tool as returning aggregate stats for today, which implies it's a read-only operation (safe for monitoring). However, it doesn't disclose behavioral traits like rate limits, authentication needs, or whether the data is real-time vs. cached. The description adds some context but lacks depth for a tool with no 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 concise and well-structured: two sentences that efficiently state the tool's purpose and usage. Every sentence earns its place—the first describes the output, and the second provides context. There's no wasted verbiage, making it 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?

Given the tool's complexity (simple read operation with no parameters) and lack of annotations/output schema, the description is moderately complete. It explains what stats are returned and their purpose, but without an output schema, it doesn't detail the return format (e.g., structure of the stats). For a monitoring tool, more specifics on output could enhance 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 tool has 0 parameters, and schema description coverage is 100% (since there are no parameters to describe). The description doesn't need to add parameter semantics, and it appropriately focuses on the tool's output. A baseline of 4 is applied as per the rules for 0 parameters, as the description compensates by explaining what the tool returns.

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: 'Return aggregate stats: total sessions, total messages, and tokens consumed today.' It specifies the verb ('return') and the resource ('aggregate stats'), including the specific metrics provided. However, it doesn't explicitly differentiate from siblings like chat_health or chat_session_list, which might also provide related metrics.

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

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

The description provides clear usage context: 'Useful for quota monitoring and observability.' This indicates when to use the tool (for monitoring quotas and observability purposes). It doesn't specify when not to use it or name alternatives among siblings, but the context is sufficient for basic guidance.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key traits: it creates a new session (implying a write operation), preserves history up to a point, and leaves the original unchanged. However, it omits details like permissions needed, rate limits, or error conditions, which would be helpful for a mutation 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?

The description is front-loaded with the core purpose in the first sentence, followed by essential behavioral details in two concise sentences. Every sentence adds value without redundancy, making it efficient and easy to parse for an AI agent.

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

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

Given the tool's moderate complexity (a mutation operation with 3 parameters), no annotations, and no output schema, the description is adequate but incomplete. It covers the basic purpose and behavior but lacks information on return values, error handling, or deeper context like how the forked session integrates with other tools. It meets minimum viability but has clear gaps.

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

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

Schema description coverage is 100%, so the schema already documents all three parameters (sessionId, forkFromMessageId, title) with clear descriptions. The description adds no additional parameter semantics beyond what the schema provides, such as explaining the relationship between sessionId and forkFromMessageId or title defaults. Baseline 3 is appropriate as the schema does the heavy lifting.

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 specific action ('Fork a session at a specific message'), the resource involved ('session'), and the outcome ('Creates a new session with all history up to and including the fork point'). It distinguishes this tool from siblings like chat_session_create by specifying it creates a copy from an existing session at a particular point, not a blank session.

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 context ('to explore an alternative branch of conversation') but does not explicitly state when to use this tool versus alternatives like chat_session_create or chat_session_get. It mentions the original session is unchanged, which helps differentiate from destructive operations, but lacks clear guidance on prerequisites or exclusions.

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