Server Quality Checklist

Tool Scores

• get_destinationC
  2.7/5.0
  Behavior2/5

  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 implies a read-only operation ('Get'), but does not specify permissions, rate limits, error handling, or what 'detailed configuration' entails. This is inadequate 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.

  Conciseness5/5

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

  The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is appropriately sized and front-loaded, making it easy to parse quickly.

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

  Completeness2/5

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

  Given the lack of annotations and output schema, the description is incomplete. It does not explain what 'detailed configuration' includes, potential error cases, or how the output is structured. For a tool with no structured behavioral data, this leaves significant gaps for the agent.

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

  Parameters3/5

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

  The input schema has 100% description coverage, clearly documenting both parameters (hookId and destinationId). The description adds no additional meaning beyond the schema, such as explaining the relationship between hook and destination or parameter constraints. Baseline 3 is appropriate when schema does the heavy lifting.

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

  Purpose3/5

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

  The description states the tool 'Get detailed configuration for a specific destination' which clearly indicates a read operation (get) on a resource (destination configuration). However, it does not differentiate from sibling tools like 'list_destinations' or 'get_hook', making it vague about its specific scope compared to alternatives.

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

  Usage Guidelines2/5

  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 'list_destinations' or 'get_hook'. It lacks context on prerequisites, exclusions, or specific scenarios, leaving the agent to infer usage based on the tool name alone.

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

• update_transformationC
  2.7/5.0
  Behavior2/5

  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 states 'update' implies a mutation, but fails to describe critical traits like required permissions, whether changes are reversible, side effects on related resources, or error handling. This is inadequate for a mutation tool with zero annotation coverage.

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

  Conciseness5/5

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

  The description is a single, efficient sentence with zero wasted words. It's front-loaded and appropriately sized for the tool's complexity, making it easy to parse quickly without unnecessary elaboration.

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

  Completeness2/5

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

  Given the complexity (a mutation tool with 5 parameters, no annotations, and no output schema), the description is incomplete. It lacks details on behavioral traits, parameter usage beyond the schema, and expected outcomes, making it insufficient for safe and effective tool invocation.

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

  Parameters3/5

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

  Schema description coverage is low at 40%, with only 'name' and 'code' parameters documented. The description adds no additional parameter semantics beyond the schema, failing to compensate for the coverage gap. However, it doesn't contradict the schema, so it meets the baseline for minimal value.

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

  Purpose3/5

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

  The description 'Update an existing transformation' clearly states the action (update) and resource (transformation), but it's vague about what a 'transformation' entails in this context. It doesn't differentiate from sibling tools like 'update_destination' or 'create_transformation', leaving ambiguity about the specific domain or scope.

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

  Usage Guidelines2/5

  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. It doesn't mention prerequisites (e.g., needing an existing transformation), exclusions, or comparisons to siblings like 'create_transformation' or 'delete_transformation', leaving the agent to infer usage from context alone.

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

• delete_destinationC
  2.8/5.0
  Behavior2/5

  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 states the action ('Remove') which implies a destructive operation, but doesn't specify whether this is permanent, reversible, requires specific permissions, or has side effects (e.g., affecting associated transformations). This is a significant gap for a mutation tool with zero annotation coverage.

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

  Conciseness5/5

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

  The description is a single, efficient sentence with zero waste. It is appropriately sized for a simple operation and front-loads the core action, making it easy to parse quickly.

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

  Completeness2/5

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

  Given the complexity of a deletion operation, lack of annotations, no output schema, and 0% schema description coverage, the description is incomplete. It fails to address critical aspects like confirmation prompts, error conditions, or return values, leaving the agent with insufficient context for safe and effective use.

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

  Parameters2/5

  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 the two undocumented parameters. It mentions 'hookId' and 'destinationId' implicitly by referring to 'a destination from a hook', but provides no details on their format, source, or constraints. This adds minimal value beyond what the schema's property names already imply.

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

  Purpose4/5

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

  The description clearly states the action ('Remove') and the target ('a destination from a hook'), making the purpose understandable. It distinguishes itself from siblings like 'delete_transformation' by specifying the resource type. However, it doesn't explicitly contrast with 'update_destination' or 'list_destinations', which slightly limits differentiation.

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

  Usage Guidelines2/5

  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 'update_destination' or 'list_destinations'. It lacks context about prerequisites (e.g., needing an existing hook/destination) or exclusions, leaving the agent to infer usage from the tool name alone.

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

• delete_transformationC
  2.8/5.0
  Behavior2/5

  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 states the action is a deletion, implying a destructive mutation, but doesn't elaborate on consequences (e.g., permanence, side effects), permissions required, or error handling. This leaves significant gaps for a mutation tool, though it correctly indicates the operation type.

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

  Conciseness5/5

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

  The description is a single, direct sentence with zero wasted words. It front-loads the core action and resource, making it easy to parse quickly. Every word earns its place by conveying essential information without redundancy.

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

  Completeness2/5

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

  For a destructive mutation tool with no annotations, 0% schema coverage, and no output schema, the description is incomplete. It lacks details on behavioral traits (e.g., irreversibility), parameter meanings, error cases, and expected outcomes. While concise, it doesn't provide enough context for safe and effective use by an AI agent.

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

  Parameters2/5

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

  The input schema has 0% description coverage, so parameters 'hookId' and 'transformationId' are undocumented in structured fields. The description adds minimal value by implying these IDs identify the hook and transformation to delete, but doesn't explain format, sourcing, or validation rules. It partially compensates for the schema gap but insufficiently for a 2-param tool.

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

  Purpose4/5

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

  The description clearly states the action ('Delete') and target ('a transformation from a hook'), making the purpose immediately understandable. It distinguishes itself from siblings like 'delete_destination' by specifying the resource type, though it doesn't explicitly contrast with other deletion tools. The description avoids tautology by not merely restating the tool name.

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

  Usage Guidelines2/5

  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 doesn't mention prerequisites (e.g., needing a hook and transformation to exist), exclusions, or relationships with sibling tools like 'update_transformation' or 'list_transformations'. Usage context is implied but not explicitly stated.

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

• create_destinationC
  2.9/5.0
  Behavior2/5

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

  With no annotations provided, the description carries full burden but only states the basic action without disclosing behavioral traits. It doesn't mention whether this is a write operation (implied but not explicit), what permissions are required, whether it's idempotent, what happens on failure, or what the response looks like. For a creation tool with zero annotation coverage, this is inadequate.

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

  Conciseness5/5

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

  The description is a single, efficient sentence that gets straight to the point with zero wasted words. It's appropriately sized and front-loaded, making it easy to understand the core purpose immediately.

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

  Completeness2/5

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

  For a creation tool with 4 parameters (including a complex nested config object), no annotations, and no output schema, the description is insufficient. It doesn't address what happens after creation, error conditions, authentication requirements, or provide any context about the destination types (HTTP, MQTT, email) mentioned in the schema. The description should do more given the complexity.

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

  Parameters3/5

  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 no additional parameter semantics beyond what's in the schema - it doesn't explain relationships between parameters, provide examples, or clarify usage patterns. Baseline 3 is appropriate when the schema does all the work.

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

  Purpose4/5

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

  The description clearly states the action ('Add a new destination') and resource ('to a hook to forward events to'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'update_destination' or 'list_destinations', which would be needed for 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.

  Usage Guidelines2/5

  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 'update_destination' or 'list_destinations'. It doesn't mention prerequisites (e.g., needing an existing hook), exclusions, or contextual considerations for choosing between creation and other operations.

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

• create_transformationC
  2.9/5.0
  Behavior2/5

  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 states it 'creates' something, implying a write operation, but doesn't address permissions, side effects, error handling, or what the response looks like. For a mutation tool with zero annotation coverage, this is a significant gap 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.

  Conciseness5/5

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

  The description is a single, efficient sentence that front-loads the core purpose without unnecessary words. It directly states what the tool does, making it easy to parse and understand quickly.

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

  Completeness2/5

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

  For a mutation tool with 4 parameters, 50% schema coverage, no annotations, and no output schema, the description is insufficient. It doesn't explain the return value, error conditions, or behavioral nuances like what 'active' default means in practice. The agent lacks critical context for proper invocation.

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

  Parameters3/5

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

  Schema description coverage is 50% (only 'name' and 'code' have descriptions), and the description doesn't add any parameter details beyond what the schema provides. It mentions 'JSONata transformation' which relates to the 'code' parameter, but this is already implied in the schema. The baseline is 3 since the schema covers half the parameters, and the description doesn't compensate for the undocumented ones like 'hookId'.

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

  Purpose4/5

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

  The description clearly states the action ('Create a new JSONata transformation') and the target resource ('for a hook'), which is specific and unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'update_transformation' or 'list_transformations', which would require a more detailed comparison of functionality.

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

  Usage Guidelines2/5

  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 'update_transformation' or 'list_transformations'. It lacks context about prerequisites (e.g., needing an existing hook) or exclusions, leaving the agent to infer usage from the tool name and parameters alone.

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

• get_aggregated_hook_metricsC
  2.9/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries full burden. It mentions 'historical aggregated metrics' but fails to disclose behavioral traits such as rate limits, authentication needs, data freshness, or what 'aggregated' entails (e.g., summary statistics). This leaves significant gaps for a metrics tool.

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

  Conciseness5/5

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

  The description is a single, efficient sentence that front-loads key information ('Get historical aggregated metrics') without unnecessary words. Every part earns its place, 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.

  Completeness2/5

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

  Given the complexity of a metrics tool with 4 parameters, no annotations, and no output schema, the description is incomplete. It lacks details on return values, aggregation methods, error handling, and usage context, leaving the agent under-informed for proper invocation.

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

  Parameters3/5

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

  Schema description coverage is 75%, with three parameters well-described in the schema (startDate, endDate, groupBy). The description adds minimal value beyond the schema, only implying date ranges without detailing parameter interactions or semantics. Baseline 3 is appropriate given the high schema coverage.

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

  Purpose4/5

  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 ('historical aggregated metrics for a specific hook'), specifying the scope with 'custom date ranges'. It distinguishes from siblings like 'get_hook_metrics' by emphasizing aggregation and historical data, though it doesn't explicitly contrast them.

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

  Usage Guidelines2/5

  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 'get_hook_metrics' or 'list_events', nor does it mention prerequisites or exclusions. It implies usage for historical metrics but lacks explicit context for selection.

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

• get_eventC
  2.9/5.0
  Behavior2/5

  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 states it retrieves details but doesn't mention whether this is a read-only operation, if it requires authentication, rate limits, error handling, or what the output format entails beyond 'JSON payload'. This leaves significant gaps for a tool with two required parameters.

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

  Conciseness5/5

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

  The description is a single, efficient sentence that directly states the tool's function without unnecessary words. It's appropriately sized and front-loaded, making it easy to understand quickly.

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

  Completeness2/5

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

  Given the complexity of retrieving event details with two required parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain the return values, error conditions, or behavioral traits, leaving the agent with incomplete information for proper tool invocation.

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

  Parameters3/5

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

  The input schema has 100% description coverage, with clear parameter descriptions for 'hookId' and 'eventId'. The description adds no additional parameter semantics beyond what the schema provides, so it meets the baseline score for high schema coverage.

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

  Purpose4/5

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

  The description clearly states the action ('Get') and resource ('full JSON payload and details of a specific event'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'list_events' or 'wait_for_event', which prevents 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.

  Usage Guidelines2/5

  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 'list_events' for multiple events or 'wait_for_event' for asynchronous retrieval. It lacks context about prerequisites or exclusions, leaving usage unclear.

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

• get_hook_metricsC
  2.9/5.0
  Behavior2/5

  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 'real-time metrics' but doesn't specify whether this is a read-only operation, what permissions are required, if there are rate limits, or what the response format looks like. For a tool with no annotations, this leaves significant behavioral gaps.

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

  Conciseness5/5

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

  The description is a single, efficient sentence that front-loads the purpose with specific details (real-time metrics, request counts, success/failure rates). Every word earns its place, with no wasted text or redundancy.

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

  Completeness2/5

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

  Given the complexity (a metrics retrieval tool with no annotations and no output schema), the description is incomplete. It doesn't explain the return values, error conditions, or behavioral traits like data freshness or access requirements. This leaves the agent with insufficient context to use the tool effectively.

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

  Parameters3/5

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

  The schema description coverage is 100%, so the schema already documents both parameters (hookId and timeWindow) with descriptions and enum values. The description adds no additional parameter semantics beyond what the schema provides, such as explaining the impact of timeWindow choices or hookId format. Baseline 3 is appropriate when the schema does the heavy lifting.

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

  Purpose4/5

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

  The description clearly states the action ('Get real-time metrics') and the resource ('for a specific hook'), with specific metrics mentioned (request counts, success/failure rates). It distinguishes from siblings like 'get_hook' (which likely returns hook configuration) and 'get_aggregated_hook_metrics' (which might provide aggregated data across multiple hooks). However, it doesn't explicitly contrast with 'get_aggregated_hook_metrics' to fully earn a 5.

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

  Usage Guidelines2/5

  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. It doesn't mention when to choose this over 'get_aggregated_hook_metrics' or other sibling tools, nor does it specify prerequisites or exclusions. The context is implied but not explicit.

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

• list_destinationsC
  2.9/5.0
  Behavior2/5

  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 it's a list operation, implying read-only behavior, but doesn't cover critical aspects like pagination, rate limits, authentication requirements, error handling, or the format of returned data. For a tool with no annotation coverage, this leaves significant gaps in understanding how it behaves beyond basic functionality.

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

  Conciseness5/5

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

  The description is a single, clear sentence that efficiently conveys the core purpose without unnecessary words. It's front-loaded with the main action and resource, making it easy to parse quickly. There's no wasted verbiage, and every part of the sentence contributes directly to understanding the tool's function.

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

  Completeness2/5

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

  Given the lack of annotations and output schema, the description is incomplete for a tool that likely returns a list of destinations. It doesn't explain what a 'destination' entails, the structure of the output, or any behavioral traits like pagination or errors. While the purpose is clear, the description fails to provide enough context for an agent to fully understand how to use and interpret results from this tool in a real-world scenario.

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

  Parameters3/5

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

  The input schema has 100% description coverage, with the single parameter 'hookId' clearly documented in the schema. The description adds no additional parameter semantics beyond what's in the schema, such as format examples or constraints. Given the high schema coverage, the baseline score of 3 is appropriate, as the schema adequately handles parameter documentation without needing extra details in the description.

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

  Purpose4/5

  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 ('destinations configured for a specific webhook'), making the purpose understandable. However, it doesn't explicitly distinguish this tool from similar siblings like 'list_hooks' or 'get_destination', which would require mentioning it's specifically for destinations associated with a hook ID rather than a general listing.

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

  Usage Guidelines2/5

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

  The description provides minimal guidance by specifying 'for a specific webhook', implying usage when you have a hookId. However, it lacks explicit when-to-use advice, such as comparing to 'get_destination' (for single destination details) or 'list_hooks' (for hooks themselves), and doesn't mention prerequisites or alternatives, leaving the agent to infer context from sibling names alone.

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

• update_destinationC
  2.9/5.0
  Behavior2/5

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

  With no annotations provided, the description carries full burden for behavioral disclosure but offers minimal information. It states this is an update operation (implying mutation) but doesn't describe permissions needed, whether changes are reversible, error conditions, or what happens to unspecified configuration fields. For a mutation tool with 6 parameters, this leaves significant behavioral gaps.

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

  Conciseness5/5

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

  The description is a single, efficient sentence that states the core purpose without unnecessary words. It's appropriately sized for a tool with a clear name and structured schema, though this conciseness comes at the expense of completeness in other dimensions.

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

  Completeness2/5

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

  For a mutation tool with 6 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain what 'update' entails (partial vs. full replacement), success/failure responses, or how it interacts with sibling tools. The agent lacks critical context to use this tool effectively beyond basic parameter passing.

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

  Parameters3/5

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

  The description mentions 'configuration' which aligns with the 'config' parameter in the schema, but adds no specific meaning beyond what the schema provides. With 67% schema description coverage (4 of 6 parameters have descriptions in schema), the baseline is 3. The description doesn't compensate for the 33% gap (hookId and destinationId lack schema descriptions) or provide additional context about parameter relationships.

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

  Purpose4/5

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

  The description clearly states the action ('Update') and resource ('an existing destination's configuration'), making the purpose immediately understandable. It distinguishes this as an update operation rather than creation or deletion, though it doesn't explicitly differentiate from sibling tools like 'update_transformation' beyond the resource name.

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

  Usage Guidelines2/5

  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 'create_destination' or 'get_destination'. It doesn't mention prerequisites (e.g., needing an existing destination), exclusions, or contextual triggers. The agent must infer usage from the tool name alone.

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

• get_hookB
  3.1/5.0
  Behavior2/5

  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 what information is retrieved ('delivery URL, metadata, and recent metrics'), but does not cover critical aspects such as authentication requirements, error handling, rate limits, or whether the operation is read-only or has side effects. For a tool with no annotations, this is insufficient, warranting a score of 2.

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

  Conciseness5/5

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

  The description is a single, well-structured sentence that efficiently conveys the tool's purpose without unnecessary details. It is front-loaded with the core action and includes specific examples of what is retrieved, making it highly concise and effective.

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

  Completeness3/5

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

  Given the tool's complexity (a read operation with one parameter) and the absence of annotations and output schema, the description is minimally adequate. It covers what the tool does but lacks details on behavior, usage context, and return values. This results in a score of 3, as it meets basic requirements but has clear gaps in completeness.

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

  Parameters3/5

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

  The input schema has 100% description coverage, with the parameter 'hookId' fully documented in the schema. The description does not add any additional meaning or context beyond what the schema provides, such as examples of hook IDs or validation rules. Given the high schema coverage, 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.

  Purpose4/5

  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 detailed configuration for a specific webhook, including delivery URL, metadata, and recent metrics.' It specifies the verb ('Get'), resource ('webhook'), and scope ('detailed configuration'), but does not explicitly differentiate it from siblings like 'get_hook_metrics' or 'list_hooks', which is why it scores 4 instead of 5.

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

  Usage Guidelines2/5

  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. It does not mention when to use 'get_hook' over 'list_hooks' for a single hook or 'get_hook_metrics' for metrics, nor does it specify prerequisites or exclusions. This lack of usage context results in a score of 2.

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

• list_hooksB
  3.1/5.0
  Behavior2/5

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

  With no annotations, the description carries full burden but only states it returns IDs, URLs, and active status. It lacks behavioral details such as pagination, sorting, rate limits, authentication requirements, or error conditions, which are critical for a list operation.

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

  Conciseness5/5

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

  The description is a single, efficient sentence that front-loads the core action and resource, with no wasted words. It directly communicates what the tool does and what it returns.

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

  Completeness2/5

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

  For a list tool with no annotations and no output schema, the description is incomplete. It mentions return fields but omits behavioral context like pagination, ordering, or error handling, leaving gaps for an agent to use it effectively.

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

  Parameters4/5

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

  The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, focusing on the tool's purpose, which aligns with the baseline for zero parameters.

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

  Purpose4/5

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

  The description clearly states the action ('List all webhooks') and resource ('configured in the Zhook account'), with specific return values mentioned. It distinguishes from siblings like 'get_hook' (singular) by indicating it returns all hooks, though it doesn't explicitly contrast with other list tools like 'list_destinations'.

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

  Usage Guidelines2/5

  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. It doesn't mention prerequisites, compare with 'get_hook' for single hook retrieval, or specify use cases like auditing or setup verification.

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

• list_eventsB
  3.2/5.0
  Behavior2/5

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

  With no annotations provided, the description carries full burden for behavioral disclosure. It mentions the tool lists 'recent events' and is 'useful for checking payloads,' but fails to specify key behaviors: whether it's read-only, how 'recent' is defined (e.g., time window), if results are paginated, error handling, or authentication needs. This leaves significant gaps for a tool that interacts with event data.

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

  Conciseness4/5

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

  The description is concise with two sentences that efficiently convey the core purpose and utility. It's front-loaded with the main action, though it could be slightly more structured by explicitly separating purpose from usage context. No wasted words, but minor room for improvement in clarity.

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

  Completeness3/5

  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 incomplete for a tool with 2 parameters. It covers the basic purpose but misses behavioral details (e.g., safety, data format, error cases) and output expectations. For a list operation in a hook/event system, more context on result structure and limitations would be beneficial.

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

  Parameters3/5

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

  Schema description coverage is 100%, with clear documentation for 'hookId' and 'limit' parameters. The description adds minimal value beyond the schema, only reinforcing the purpose ('list recent events') without explaining parameter interactions or semantics like what 'hookId' refers to in context. Baseline score of 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.

  Purpose4/5

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

  The description clearly states the action ('List recent events') and resource ('received by a specific hook'), making the purpose understandable. It distinguishes from siblings like 'get_event' (single event) and 'wait_for_event' (blocking operation), but doesn't explicitly contrast with other list tools like 'list_hooks' or 'list_destinations', keeping it from 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.

  Usage Guidelines3/5

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

  The description implies usage context ('Useful for checking what payloads have been delivered'), suggesting it's for monitoring hook deliveries. However, it lacks explicit guidance on when to use this versus alternatives like 'get_event' (for a specific event) or 'get_hook_metrics' (for aggregated data), and doesn't mention prerequisites or exclusions.

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

• list_transformationsB
  3.2/5.0
  Behavior2/5

  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 action ('List all transformations') but doesn't describe return format, pagination, error conditions, or authentication needs. For a read operation with zero annotation coverage, this is a significant gap 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.

  Conciseness5/5

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

  The description is a single, efficient sentence with zero waste. It's front-loaded with the core action and resource, making it easy to parse quickly without unnecessary details.

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

  Completeness2/5

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

  Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what 'transformations' entail, the return structure, or error handling. For a tool with one parameter but no behavioral context, more detail is needed to be fully helpful to an agent.

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

  Parameters3/5

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

  The description adds minimal value beyond the input schema, which has 100% coverage. It implies the parameter 'hookId' is for a 'specific webhook', but doesn't elaborate on format, sourcing, or constraints. With high schema coverage, the baseline score of 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.

  Purpose5/5

  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 ('transformations configured for a specific webhook'), making the purpose explicit. It distinguishes from siblings like 'list_hooks' or 'list_events' by specifying transformations tied to a particular hook, not a general listing.

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

  Usage Guidelines2/5

  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. It doesn't mention prerequisites (e.g., needing a valid hookId), exclusions, or comparisons to siblings like 'get_hook' or 'list_hooks', leaving usage context implied at best.

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

• create_hookB
  3.3/5.0
  Behavior2/5

  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 mentions the return ('Returns the new hook ID and its public URL'), which is helpful, but fails to cover critical aspects like authentication requirements, rate limits, side effects, or error handling for a creation tool.

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

  Conciseness5/5

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

  The description is a single, efficient sentence that front-loads the core action and return value. Every word earns its place with zero waste, making it easy to parse quickly.

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

  Completeness3/5

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

  Given the complexity (5 parameters with nested objects) and no annotations or output schema, the description is minimal. It covers the basic purpose and return, but lacks details on behavioral traits, usage context, or error handling, leaving gaps for a creation tool with multiple configuration options.

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

  Parameters3/5

  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 5 parameters. The description adds no additional parameter semantics beyond what the schema provides, such as explaining the implications of 'type' or 'deliveryMethod' choices. Baseline 3 is appropriate when schema does the heavy lifting.

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

  Purpose5/5

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

  The description clearly states the action ('Create a new webhook or MQTT hook') and the resource ('hook'), specifying two distinct types. It distinguishes from siblings like 'create_destination' or 'create_transformation' by focusing specifically on hooks, and mentions the return value, which adds clarity.

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

  Usage Guidelines2/5

  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 'create_destination' or 'trigger_webhook'. It lacks context on prerequisites, such as when a webhook vs. MQTT hook is appropriate, or any exclusions for usage scenarios.

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

• trigger_webhookA
  3.7/5.0
  Behavior2/5

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

  With no annotations provided, the description carries full burden but only states this 'mimics a real third-party service' without disclosing critical behavioral traits. It doesn't mention whether this requires authentication, rate limits, what happens if the hook doesn't exist, or what response to expect. For a tool that sends data, this is insufficient behavioral disclosure.

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

  Conciseness5/5

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

  Two concise sentences that are front-loaded with the core purpose. Every word earns its place - no redundancy, no unnecessary elaboration, perfectly sized for the tool's complexity.

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

  Completeness3/5

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

  For a tool with no annotations and no output schema, the description is adequate but incomplete. It explains the purpose well but lacks information about authentication requirements, error conditions, response format, or what 'test' means operationally. Given the complexity of triggering webhooks, more context would be helpful.

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

  Parameters3/5

  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 4 parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema, maintaining the baseline score of 3 for high schema coverage.

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

  Purpose5/5

  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 test webhook event') and target resource ('to a specific Hook'), distinguishing it from sibling tools like create_hook, get_hook, or list_hooks. It specifies this is for testing purposes, not actual webhook creation or management.

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

  Usage Guidelines4/5

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

  The description provides clear context about when to use this tool ('to mimic a real third-party service sending data'), but doesn't explicitly state when NOT to use it or name specific alternatives. It implies this is for testing rather than production use, though not explicitly.

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

• wait_for_eventA
  4/5.0
  Behavior4/5

  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 behavioral traits: it connects to a WebSocket (implying a persistent connection), waits for the next event (not historical), returns the full payload immediately, and has a 60-second timeout. It doesn't cover error handling or what happens after timeout, but provides substantial operational context.

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

  Conciseness5/5

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

  The description is highly concise with three short sentences that are front-loaded with essential information (action, resource, mechanism, timeout). Every sentence earns its place by adding critical context without redundancy or fluff.

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

  Completeness4/5

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

  Given the tool's moderate complexity (real-time event waiting), no annotations, and no output schema, the description is reasonably complete. It covers the core behavior, timeout, and return, but lacks details on error cases, output format, or WebSocket connection lifecycle. For a tool with these gaps, it does well but isn't fully comprehensive.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema already fully documents both parameters (hookId and timeoutSeconds). The description adds minimal value beyond the schema by mentioning the timeout default (60 seconds) and that it's for waiting, but doesn't provide additional syntax or format details. Baseline 3 is appropriate when the schema does the heavy lifting.

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

  Purpose5/5

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

  The description clearly states the specific action ('waits for the NEXT event to arrive'), resource ('on a specific hook'), and mechanism ('Connects to the Zhook WebSocket'), distinguishing it from sibling tools like get_event or list_events which retrieve existing events rather than waiting for new ones.

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

  Usage Guidelines3/5

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

  The description implies usage by specifying it waits for the next event on a hook, suggesting it's for real-time monitoring rather than historical queries. However, it lacks explicit guidance on when to use this versus alternatives like get_event or trigger_webhook, and doesn't mention prerequisites such as needing an existing hook.

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