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

With no annotations, the description carries full responsibility for disclosing behavior. It only says 'add' (implying mutation) but does not explain side effects, required permissions, idempotency, or how the note is associated with a user (despite a userId parameter). No additional context on behavior is provided.

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 sentence that conveys the essential action. No fluff, no redundant details. Front-loaded with the verb and object, making it easy to scan.

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?

This is a simple mutation tool with no output schema and no annotations. The description provides minimum viable information: it adds a note. But given the context of sibling tools (e.g., create_draft_reply, update_ticket), more context on when to use an internal note vs a customer-visible reply, or any prerequisites, would be valuable. The description is too thin to be fully complete for an agent that has limited knowledge of FreeScout internals.

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

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

Schema coverage is 100% – all three parameters (note, ticket, userId) are described in the schema. The description adds no extra meaning beyond the schema, so the baseline of 3 is appropriate, since the schema already documents parameters and the description doesn't compensate 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?

Clear verb+resource: 'Add an internal note to a FreeScout ticket.' This is specific and distinct from siblings like get_ticket or update_ticket, as it addresses a unique action (adding internal notes). The tool name and title are semantically consistent.

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 gives no guidance on when to use this tool versus alternatives (e.g., create_draft_reply or update_ticket). It doesn't mention typical use cases, prerequisites, or when not to use it. The only hint is the purpose statement itself.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the analysis intent but does not disclose whether the tool is read-only, whether it can modify a ticket, what input formats are actually accepted beyond the schema hint, or how its output 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, front-loaded sentence with no filler, redundancy, or tangential information. Every word contributes to communicating the tool's purpose.

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 enough to recognize the tool's core purpose and names three kinds of output, which is minimal viable. However, with no annotations and no output schema, it omits important operational context like side effects, response shape, and when to select this tool instead of a retrieval-focused sibling.

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, 'ticket', is already fully described in the schema as 'Ticket ID, ticket number, or FreeScout URL'. The description adds no additional parameter semantics, but the schema coverage is 100%, so the baseline of 3 is appropriate.

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

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

The description uses a specific verb ('Analyze') and names both the resource ('FreeScout ticket') and the output scope ('issue type, root cause, and suggested solution'). This clearly differentiates it from sibling tools that get, update, search, or add notes to tickets.

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 it should be used when a ticket needs diagnosis, but it does not explicitly state when to choose this over freescout_get_ticket or freescout_get_ticket_context, nor does it describe exclusions or when not to use it.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It only states that a draft is created and can be edited before sending. It does not mention side effects like whether the ticket is modified, whether any permissions are needed, whether the draft is stored permanently, or whether the operation is idempotent. For a write operation, this is insufficient 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 a single, front-loaded sentence that communicates the purpose and the key behavior without any fluff. It earns its place by stating the core function and the 'editable before sending' nuance, and it does so 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 tool with 6 parameters and no output schema, the description is minimal but not entirely inadequate. It conveys the main intent and the 'not sent yet' aspect, but it lacks details on how the draft relates to the ticket, whether the ticket status changes, or any prerequisites or constraints. Given the lack of annotations, this is a noticeable gap but not a critical failure.

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 every parameter (cc, to, bcc, ticket, userId, replyText) having a meaningful description. The tool description adds no additional parameter semantics beyond the schema, so the baseline score of 3 applies.

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

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

The description clearly states the tool creates a draft reply in FreeScout, with a specific verb ('Create') and resource ('draft reply'), and adds the key nuance that it can be edited before sending. This distinguishes it from sibling tools like freescout_add_note (which adds a note, not a reply) and freescout_update_ticket (which modifies ticket fields).

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 about when to use this tool versus alternatives, such as when to create a draft vs sending a reply directly, or when to use freescout_add_note instead. The description only states what it does, not the eligible scenarios or exclusions.

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

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

With no annotations at all, the description carries the full burden of behavioral disclosure. The phrase 'list of available mailboxes' is terse and does not explicitly state that this is a read-only operation, nor does it provide any details about the response structure, potential errors, or system behavior. Compared to the calibration examples, this is less informative than the 'list ALL calls' description that earned a 3, hence a 2 is appropriate.

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, short sentence that is directly to the point. Every word adds value, and there is no fluff. This is an example of excellent conciseness, not under-specification.

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 simplicity of the tool (no parameters, no output schema, no nested objects), the description is mostly sufficient. However, it could provide a bit more context, such as the type of data returned (e.g., mailbox IDs and names) or note that no authentication is required, which would help an agent determine if this tool meets their needs without making a separate call. Thus, it is adequate but not outstanding.

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, so the baseline of 4 is applied. The description does not need to add parameter context since none exist, and no additional information could meaningfully improve this dimension.

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 'Get list of available mailboxes' uses a specific verb 'Get', a clear resource 'mailboxes', and the qualifier 'available' indicates scope. It distinguishes itself well from sibling tools that deal with tickets and notes, making the function's purpose immediately obvious.

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 that this tool is used when you need a list of mailboxes, but it does not explicitly state when to use it versus alternatives or provide exclusions. Since there are no sibling tools that list mailboxes, the lack of explicit alternative guidance is mitigated, but the onboarding still relies on the agent inferring the obvious use case.

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

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

No annotations are provided, so the description carries full burden. It implies a read-only fetch operation but does not explicitly state that it is non-mutating, nor does it explain what 'analyze' entails, return format, or any limitations. This is adequate but not rich in 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 concise sentence that front-loads the core action and input requirement. Every word earns its place, with no unnecessary filler or redundancy.

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

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

With two parameters, no output schema, and no annotations, the description is minimally sufficient. However, it fails to clarify the meaning of 'analyze' or how this tool differs from freescout_analyze_ticket, leaving context gaps for a more complex 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?

The input schema provides descriptions for both parameters (ticket and includeThreads) with 100% coverage. The description adds no extra meaning beyond what the schema already documents, just echoing 'by ID or URL'. Baseline 3 is appropriate for full 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 fetches and analyzes a FreeScout ticket by ID or URL, using a specific verb and resource. However, it does not explicitly differentiate from the sibling freescout_analyze_ticket, so it misses the top score for sibling distinction.

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 like freescout_analyze_ticket or freescout_search_tickets. There is no context about selecting this tool over others, so it falls to 'no guidance' / 2.

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 says 'Get ticket context and customer info' but doesn't disclose what exactly is returned, whether it's a read-only operation, any side effects, or performance implications. For a tool that fetches context, it should clarify the scope of data (e.g., full conversation history, customer details) and any limitations. The description is too vague about behavior.

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, concise and front-loaded with the main purpose. It's efficient with no wasted words. However, it could be slightly more structured by mentioning the output or usage context, but it's appropriately sized for a simple tool.

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 purpose (drafting personalized replies), the description is incomplete. It doesn't mention what kind of context is provided (e.g., customer name, previous interactions, sentiment) or how it integrates with the drafting workflow. With no output schema and no annotations, the description should provide more detail about the return value and its use. The single sentence is insufficient for an agent to know what to expect.

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

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

Schema description coverage is 100% for the single parameter 'ticket', which is described as 'Ticket ID, ticket number, or FreeScout URL'. The description adds no additional meaning beyond that, but since the schema already covers it well, a baseline of 3 is appropriate. The description doesn't clarify how the tool resolves the ticket identifier, but that's not required.

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: 'Get ticket context and customer info to help draft personalized replies.' It specifies the resource (ticket) and the intent (drafting replies), which distinguishes it from siblings like freescout_get_ticket (which likely fetches raw ticket data) and freescout_analyze_ticket (which likely performs analysis). However, it doesn't explicitly differentiate from freescout_get_ticket, so it's not a 5.

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

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

The description implies usage when drafting personalized replies, but it doesn't explicitly state when to use this tool versus alternatives like freescout_get_ticket or freescout_analyze_ticket. There's no mention of when not to use it. The context is clear but lacks explicit exclusions or alternative guidance.

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

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

With no annotations, the description must disclose behavioral traits, but it only mentions that includeLastMessage provides a preview of the most recent message. It does not state that the operation is read-only, describe pagination behavior, return format, or any limitations. It adds little beyond what is obvious from the word 'search', so a score of 2 is appropriate.

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—three sentences—and front-loaded with the core purpose. It includes useful examples without verbosity. It could be slightly more structured but is efficient and to the point, earning 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 10 parameters, no output schema, and no annotations, the description is markedly incomplete. It does not explain the meaning of state, status, mailboxId, textSearch, or pagination defaults, nor does it describe the return structure or ordering. It covers only a few parameters, leaving the agent with significant gaps for a complex search tool. Thus a score of 2 is warranted.

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 adds meaningful semantics for a few parameters: assignee (with 'unassigned' and numeric user IDs), time filters (relative formats like '7d'), and includeLastMessage (preview of latest message). However, schema description coverage is 0% and many parameters (page, state, status, mailboxId, textSearch, pageSize) are entirely undocumented in the description. It partially compensates for the low coverage, meriting a 3.

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

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

The description clearly states the tool searches for tickets with explicit filter parameters. The verb 'Search' and resource 'FreeScout tickets' distinguish it from sibling tools like get_ticket or analyze_ticket, though it does not explicitly name alternatives. The purpose is unambiguous, earning a 4.

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 concrete usage examples for assignee (e.g., 'unassigned', number) and relative time filters (e.g., '7d', '24h'), and explains the includeLastMessage flag. It gives practical guidance on how to use the search, but does not mention when to prefer this over sibling tools or when not to use it. This justifies a 4.

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

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

No annotations are provided, so the description must carry the full behavioral burden. It only says 'Update ticket status and/or assignment' without disclosing side effects, permission requirements, reversibility, or any additional constraints. This is minimal 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 a single concise sentence, perfectly front-loaded with the action and target, containing zero fluff. It is optimally 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?

For a mutation tool with no annotations, no output schema, and 4 parameters, the description is too sparse. It does not explain what happens when status changes, the role of userId, or any prerequisites. Missing essential behavioral context for safe 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 coverage is 100%, so all parameters are already documented. The description adds no extra semantics beyond a high-level summary of 'status and/or assignment', which overlaps with the schema descriptions. Baseline 3 applies since schema carries the burden.

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

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

The description clearly states the verb 'Update' and the resource 'ticket', specifying two update aspects: status and assignment. It distinguishes itself from sibling tools like search, note, or analyze, though it doesn't explicitly name an alternative. This is a clear statement of purpose.

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 usage guidelines—no 'when to use' or 'when not to use' instructions, and no comparison with alternatives. The agent must infer the intended scenario from the tool name and schema.

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