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

With no annotations, the description provides minimal behavioral information, only stating the action without disclosing side effects, permissions, or idempotency.

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, clear sentence with no extraneous information, front-loading the key action.

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

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

For a simple mutation with no output schema, the description is adequate to understand the tool's purpose, though it could optionally mention success/failure behavior.

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 descriptions fully cover all parameters, and the tool description adds no further meaning, so baseline 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 verb 'Add', the object 'fee line item', and the context 'to an existing canned service template', distinguishing it from sibling tools.

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

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

The description implies usage by naming the action, but does not explicitly mention when to use it over alternatives like add_canned_service_labor or add_canned_service_part.

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 transparency burden. It accurately indicates a create/add operation but does not disclose side effects, failure behavior, or whether adding is idempotent.

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 clear sentence with no unnecessary wording 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 straightforward additive operation with fully described parameters and no output schema, the description is largely complete. It could be slightly richer about expected behavior, but the current text plus schema gives adequate 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?

The schema already describes all parameters, and the description adds no meaningful semantic detail beyond what is already in the input schema, so 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 action ('Add'), the object ('labor line item'), and the target ('existing canned service template'), which distinguishes it from related tools like add_canned_service_fee or update_canned_service_labor.

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

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

The description implies the use case by naming the operation, but it does not explicitly contrast it with alternatives such as update_canned_service_labor or remove_canned_service_labor, leaving the agent to infer when this tool should be preferred.

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 present, the description carries the full burden of disclosing side effects, requirements, and side conditions. It only states what the tool does, not whether it modifies the template, what happens on duplicate parts, or any permission requirements. This is a significant gap given the lack of annotations.

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

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

The description is a single, concise sentence that omits unnecessary details. It is front-loaded with the key action and object, making it easy to parse quickly. No redundant information is present.

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

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

The tool is a straightforward CRUD operation, so the description is adequate for basic usage. However, it lacks information about the return value or any error conditions, and there is no output schema. Given the simplicity, a score of 3 is appropriate—it covers the essential purpose but leaves some operational details unspecified.

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 all eight parameters, achieving 100% coverage. The tool description adds no extra meaning beyond the schema definitions, so the baseline score applies. Parameters like 'retailCostCents' and 'wholesaleCostCents' are already clearly explained in the schema.

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

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

The description clearly states the action ('Add') and the object ('a part line item to an existing canned service template'), which is specific and distinguishes it from sibling tools like fee or labor additions. However, it doesn't explicitly name any sibling tools or contrast with them, so it falls short of 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?

No guidance is provided on when to use this tool versus alternatives such as add_canned_service_fee or add_canned_service_labor. The operation name itself is self-explanatory, but the description offers no explicit selection criteria, leaving the agent to infer from context.

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

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

With no annotations provided, the description carries the full burden for behavioral transparency. It states only that a subcontract line item is added, but does not disclose side effects, persistence behavior, validation requirements, failure modes, or whether the canned service must already exist.

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 with no redundant or irrelevant content. It is well structured and immediately communicates the core 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?

For a mutation with 8 parameters and no output schema, the one-sentence description is too sparse. It does not explain what happens when the subcontract is added, how fields like quantity or unitCostCents interact, what 'taxableValueType' means, or what the caller should expect after invocation.

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

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

Schema descriptions cover 100% of the 8 parameters, so the baseline is 3. The description adds no additional meaning beyond the schema, and some properties like 'taxableValueType' remain vague, but the schema does provide basic one-line descriptions for each parameter.

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

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

The description clearly states the action ('Add'), the object ('a subcontract line item'), and the target ('an existing canned service template'). It is easily distinguished from sibling tools like add_canned_service_labor, add_canned_service_part, and add_canned_service_tire.

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

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

The description implies when to use the tool: when adding a subcontract to a canned service. However, it does not explicitly mention alternatives like update_canned_service_subcontract or remove_canned_service_subcontract, so the guidance is only implicit rather than explicit.

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

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

With no annotations, the description must convey behavioral impact. It says 'Add' indicating a write operation, but does not describe side effects, validation, or error conditions. This is minimal.

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

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

Single concise sentence, front-loaded with the action.

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

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

For a simple add operation, the description is sufficient to understand the intent, though it doesn't explain what happens to existing line items. Acceptable.

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

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

Schema covers all 8 parameters with descriptions. The tool description adds no additional meaning. Some descriptions like 'Additional description' are vague but exist. Baseline 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?

States a specific verb 'Add', a specific resource 'tire line item', and target 'canned service template'. Clearly distinguishes from sibling tools like add_canned_service_fee or add_canned_service_part.

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?

Does not explicitly state when to use or not use this tool, though the sibling list implies it. It only says 'Add...' without mentioning alternatives or conditions.

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 states the action (add a service) but does not mention side effects such as whether the order is modified in place, whether it appends or replaces existing services, any permission requirements, or potential impacts on order totals. The mutation nature is implied but not elaborated, leaving significant gaps for a tool that alters an order.

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, with two sentences that are front-loaded with the core purpose. The first sentence states the action, and the second explains the two usage patterns. There is no redundant or filler content, making it efficient for an agent to parse quickly.

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 without an output schema, the description adequately covers the essential invocation logic: the two modes and their associated parameters. It does not explain what happens after the call (e.g., whether the order totals are recalculated) or any prerequisites like order status, but these are not strictly required for a basic call. The absence of behavioral details lowers the score slightly, but the description is otherwise complete for selecting and calling the tool.

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

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

While the schema covers 100% of parameter descriptions, the description adds semantic value by grouping parameters into two usage modes. It explains that fromCannedServiceId triggers a template copy including labor/parts/fees, whereas name/note/pricing creates a custom service. This goes beyond the raw schema and helps the agent understand the interplay between parameters.

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

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

The description clearly states the verb 'Add' and the resource 'a service to a work order', with a specific and unambiguous purpose. It also distinguishes two modes of operation (canned template vs. custom), making it easy for an agent to understand what the tool accomplishes. It stands apart from sibling tools that operate on canned services rather than orders.

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

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

The description provides explicit guidance on when to use each parameter path: passing fromCannedServiceId for copying a template, or name/note/pricing for a custom service. This helps the agent decide how to invoke the tool. It does not explicitly contrast with alternative tools, but there is no direct sibling that adds a service to an order, so the guidance is sufficient.

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 says 'assign an existing label', which implies mutation but does not state whether the assignment is idempotent, whether it overwrites existing label associations, what happens if the label or entity does not exist, or any permission requirements. The description gives no information about side effects, return values, or error handling, which is a significant gap 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 sentence with no redundant words. It front-loads the action ('Assign') and includes the valuable hint about list_labels in parentheses. Every word earns its place, and there is no filler or unnecessary detail.

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

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

Given that this is a mutation tool with no annotations and no output schema, the description should provide more context about behavior, results, and prerequisites. It only covers the prerequisite of using list_labels, but omits what happens on success, whether the action is reversible, and any permission requirements. The description is incomplete for an agent to fully anticipate the tool's effects.

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 has 100% description coverage for all three parameters, including a clear enum for entity and descriptions for labelId and entityId. The description adds minimal extra meaning beyond the schema—only a brief mention that entity can be 'such as an Order or Customer', which is already in the schema. The schema already does the heavy lifting, so a baseline 3 is appropriate.

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

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

The description clearly states the action: assign an existing label to an entity. It names the resource (label) and the target (entity) and even hints at how to find labels (via list_labels). It distinguishes itself from sibling tools like list_labels and get_label by focusing on the assignment action, leaving no ambiguity about what it does.

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

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

The description provides a clear prerequisite: the label must already exist and be found via list_labels. It implies the tool is for assigning, not creating labels. There is no alternative assign-label sibling, so no explicit when-not-to-use is needed, but the prerequisite guidance is helpful and gives context on when to invoke this tool.

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

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

With no annotations, the description carries the full burden for behavioral disclosure. It states the assignment action but does not mention whether an existing assignment will be replaced, what happens on invalid IDs, or any response/return 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 two sentences and contains no redundant or extraneous information. The workflow guidance is compact and directly relevant.

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

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

It includes necessary prerequisite lookup steps and correctly identifies all required inputs. It lacks explicit postcondition or output information, but given the simplicity of the action, it is reasonably complete.

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

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

The schema provides basic descriptions for all three parameters, and the tool description adds useful context by explaining how to obtain orderId, laborIds, and technicianId through related tools. This goes beyond the schema but does not deeply detail each parameter.

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 ('Assign') and clearly identifies the resource ('technician') and target ('one or more labor line items on a work order'). It is distinct from sibling tools like add_service_to_order and list_labor.

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

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

The description explicitly tells the agent which lookup tools to use for each input parameter (list_services, list_labor, list_users), providing a clear workflow before calling this tool.

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 provided, forcing the description to carry full disclosure burden. However, it reveals nothing about side effects, conflict handling (e.g., double-booked slots), return values, or whether notifications are sent. Only states the basic creation action.

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

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

Single sentence with zero redundancy. However, for an 8-parameter creation tool with zero annotations, this brevity may be insufficient rather than optimally concise—it leaves critical context unstated.

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?

Inadequate for complexity level. An 8-parameter mutation tool with no annotations and no output schema requires substantial contextual support (prerequisites, side effects, required relationships). The single-sentence description fails to provide this.

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

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

With 100% schema description coverage, the schema adequately documents all 8 parameters (customerId, vehicleId, etc.). The description adds no semantic detail beyond the schema, but baseline 3 applies per rubric for high-coverage schemas.

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 ('Book') with clear resource ('appointment') and context ('Shopmonkey'). It clearly distinguishes from siblings like 'get_appointment', 'update_appointment', and 'list_appointments' by indicating this is a creation operation.

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 provided on when to use this versus 'update_appointment' or prerequisites (e.g., that customerId/vehicleId likely require existing records). No mention of required fields despite all 8 parameters being technically optional in the schema.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It only states the basic create action and defines canned services; it does not mention that this is a mutating operation, potential side effects, permission requirements, or response format. Critical behavioral context is missing.

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: the first states the action and scope, the second provides essential context about what canned services are. It is front-loaded with the action and contains zero fluff 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?

Given the tool's complexity (9 parameters) and absence of an output schema, the description provides adequate context about the purpose and domain but omits details on return values, prerequisites, or behavioral expectations. It is minimal and leaves the agent to infer how the creation result is handled.

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 100% parameter coverage with detailed descriptions for each of the 9 parameters. The tool description adds no additional parameter semantics beyond the schema, so it meets the baseline for high schema coverage. No value beyond schema is added.

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

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

The description clearly states the action (create), the resource (canned service template), and the domain (Shopmonkey). It defines canned services as reusable bundles, distinguishing it from update/delete siblings. The purpose is unambiguous and specific.

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 makes clear this is for creating new templates, which implies when to use it, but it does not explicitly exclude alternatives or mention conditions like updating existing templates. The context is clear but lacks explicit when-not guidance or alternative references.

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 alone must convey behavioral expectations. It only states 'Create' with no mention of side effects, validation, error conditions, or idempotency, offering minimal transparency beyond the action itself.

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, direct sentence that is perfectly concise. It uses no unnecessary words and immediately conveys 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?

For such a simple create operation, the description is adequate but lacks details about the expected response (e.g., created customer ID) and any prerequisites such as uniqueness checks. The absence of an output schema increases the need for this context, which is not provided.

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

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

All six parameters are described in the schema (100% coverage), so the baseline is 3. The description adds no extra meaning to the parameters, relying entirely on the already clear field names and short descriptions.

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

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

The description clearly states the action (Create), the target resource (a new customer), and the context (in Shopmonkey). It effectively distinguishes this from sibling tools like update_customer and search_customers.

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

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

No guidance is provided on when to use this tool versus alternatives. It does not mention checking for existing customers before creating, nor when to prefer create over update, leaving the agent without explicit usage direction.

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

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

The description discloses that the tool creates a new order, which implies a write operation. With no annotations to indicate side effects, this basic behavioral transparency is sufficient for the simple action, though it does not detail any potential implications (e.g., defaults or related records).

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

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

The description is a single, focused sentence that directly states the purpose without any unnecessary words or tangential details. It is concise and front-loaded.

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

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

For a simple create operation with no output schema, the description is complete. It correctly identifies the action and object, and the schema provides all necessary parameter details. No critical context is missing.

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 all five parameters, covering 100% of them. The individual descriptions (e.g., locationId default) add clear meaning, so the tool description itself does not need to elaborate 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 action ('Create a new work order') and the context ('in Shopmonkey'), making the tool's purpose unambiguous and easily distinguishable from sibling tools that operate on other resources (e.g., customers, vehicles).

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

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

The description does not explicitly mention when to use this tool versus alternatives, but since there is no other create-order tool among the siblings, the usage context is implicit. The clear purpose provides sufficient guidance for an agent to select it appropriately.

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

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

With no annotations, the description carries the full burden. It states that a new payment is recorded, implying a write operation, but does not disclose side effects (e.g., updates to order balance), validation rules, or idempotency. Basic behavior is clear, but deeper consequences are not covered.

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 action ('Record') and the resource ('payment'). It contains no fluff and is efficiently 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?

The tool is a simple create operation, and the description gives the essential purpose. However, the absence of an output schema and annotations leaves the return value and error behavior unspecified, which may require the agent to make assumptions. It is adequate but not fully complete.

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

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

The schema description coverage is 100%: all four parameters (orderId, amountCents, method, notes) have descriptions. The tool description adds no additional semantic value 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 'Record a new payment in Shopmonkey' clearly specifies the action (recording/creating) and the resource (payment). It is distinct from sibling tools like get_payment and list_payments, making the purpose unambiguous.

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

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

The description implicitly indicates this tool is for creating new payments, and sibling tools for retrieving payments exist, but it does not explicitly state when to use this tool versus alternatives. The usage is implied rather than explicitly stated.

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 provided, so description carries full burden. States 'Add' indicating mutation, but fails to disclose side effects (what happens on duplicate VIN?), return values, idempotency, or required fields despite schema marking all as optional.

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

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

Single 11-word sentence. Front-loaded with action verb. Zero redundancy. Every word earns its place by conveying core operation, target system, and key optional relationship.

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?

Creation tool with no output schema and no annotations, but benefits from 100% param schema coverage. Adequate for basic invocation but gaps remain: no mention of return payload (created object ID?), validation behavior, or conflict resolution.

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%, establishing baseline 3. Description adds 'optionally linked' which reinforces the optional nature of customerId parameter, but otherwise doesn't expand on parameter semantics, formats, or validation rules beyond schema.

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

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

Clear verb 'Add' with specific resource 'vehicle' and system context 'Shopmonkey'. Mentions optional customer linking which adds scope detail. Lacks explicit differentiation from sibling 'update_vehicle' (create vs modify).

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?

Implies usage context via 'optionally linked to a customer', suggesting when to include customerId. However, lacks explicit prerequisites (e.g., 'create customer first') or 'when-not-to-use' guidance versus update_vehicle.

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 burden. It clearly indicates a write operation ('Create' and 'register') and implies the creation of a new webhook resource, which is transparent for a typical create action. It doesn't mention side effects, but they are not necessary for this simple 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 two concise sentences with no fluff. It efficiently conveys the purpose and a common use case, 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?

The description is comprehensive for a create operation. It doesn't mention output schema (none exists), but it provides enough context about the resource and intended usage. The required parameters are in the schema, so the description is adequate.

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 covers 100% of parameters, and the description does not add any extra meaning beyond what the schema already explains. The baseline is 3 because it relies fully on the schema, which is sufficient.

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

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

The description clearly states the action ('Create') and resource ('webhook in Shopmonkey'), and specifies the intended use of registering endpoint URLs for receiving event notifications. It distinguishes itself from sibling tools like list_webhooks, update_webhook, and delete_webhook.

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?

Provides explicit guidance on when to use this tool (to register Make.com or other endpoint URLs for event notifications). It doesn't explicitly say when not to use it, but the purpose is clear enough that an agent can infer alternatives like listing or updating webhooks.

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

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

The description only states that deletion occurs, with no mention of irreversibility, side effects, permissions, or impact on related data such as associated fees, labor, parts, or subcontracts. Since no annotations are present, this lack of behavioral detail leaves important safety information undocumented.

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, clear sentence with no unnecessary words. It directly communicates the action and target.

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

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

For a simple delete operation with one parameter and no output schema, the description is mostly sufficient. However, it omits any indication of what happens after deletion (e.g., confirmation behavior) and does not address potential constraints or dependencies, leaving some contextual 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?

The single parameter 'id' is fully covered by its schema description ('The canned service ID to delete'), and the description aligns with it. The description adds little beyond what the schema already states, so the baseline score 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 a specific action ('Delete') and a specific resource ('canned service template') with an identifier. This distinguishes it from sibling tools like create_canned_service, update_canned_service, and list_canned_services.

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

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

The description implies the intended use: deleting a canned service template by ID. However, it does not explicitly mention when to prefer this tool over alternatives or provide any 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, the description must convey destructive behavior. 'Delete' clearly indicates a destructive action, but it does not mention permanence, side effects, or whether the operation is idempotent. It provides basic transparency but lacks detail.

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, clear sentence with no unnecessary words. It is appropriately sized for a simple delete operation and front-loads the key action.

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 sibling tools, the purpose is clear, and no extra context is strictly required for a simple delete. However, it does not mention any prerequisites (e.g., the webhook must exist) or expected result (e.g., success/failure response), leaving a minor gap.

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

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

The schema already documents the 'id' parameter as 'The webhook ID to delete', and the description repeats this nearly verbatim. It adds no new meaning or context, such as format, constraints, or validation rules, though coverage is complete.

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

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

The description uses the specific verb 'Delete' with the resource 'webhook', clearly identifying the action. It distinguishes itself from sibling tools like create_webhook, update_webhook, and get_webhook by focusing solely on 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 gives no explicit guidance on when to use this tool versus alternatives. It does not mention that this is the only tool for deleting webhooks or that list/get should be used to find the ID first. Usage must be inferred from the action name.

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 provided, so description carries full disclosure burden. Adds 'detailed information' to distinguish depth from summary listings, but fails to disclose read-only safety (implied but not stated), error behavior if ID invalid, or authorization requirements.

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

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

Single sentence of 9 words. Front-loaded action verb, zero redundancy, every word earns its place. Appropriate length for simple retrieval operation.

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?

Adequate for a simple 1-parameter retrieval tool without output schema. Describes the lookup mechanism and depth of return ('detailed'). Could improve by noting error behavior (e.g., 404 if ID not found) but satisfies core requirements.

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% with 'id' parameter fully described as 'The appointment ID'. Description mentions 'by its ID' confirming the parameter's identifying purpose, but adds no syntax guidance or validation rules beyond schema. Baseline 3 appropriate 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?

Excellent clarity: specific verb 'Get', resource 'appointment', and scope 'single appointment by its ID' clearly distinguishes from sibling list_appointments (plural listing) and update_appointment (mutation).

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?

Provides implied usage through 'by its ID', signaling this requires a specific identifier rather than browsing. However, lacks explicit contrast with list_appointments alternative or guidance on when to use each (e.g., 'Use this when you have a specific appointment ID; use list_appointments to search broadly').

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 provided, so description must carry full behavioral disclosure burden. Fails to disclose: read-only nature (implied but not explicit), error behavior for invalid IDs, rate limits, or what 'detailed information' encompasses. Provides minimal safety/operational context beyond the action verb.

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

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

Single sentence, front-loaded with no redundant words. Every element earns its place: verb, resource, scope qualifier, and key parameter reference. Appropriately compact for a simple getter.

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?

Adequate for a single-parameter tool with complete schema coverage, but gaps remain given no output schema exists. Description does not hint at return value structure, payload size, or what fields constitute 'detailed information'. Sufficient but minimal.

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%, establishing baseline 3. Description references 'by its ID' which aligns with the parameter, but adds no additional semantic context such as ID format constraints, where to obtain valid IDs, or validation rules beyond the schema's basic 'The canned service ID'.

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 ('Get'), specific resource ('canned service template'), and scope ('single' + 'by its ID'). Distinguishes implicitly from sibling 'list_canned_services' by emphasizing the singular lookup pattern, though it does not explicitly name the alternative.

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

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

No explicit guidance on when to use this tool versus alternatives. While 'by its ID' implies you must have a specific identifier, it does not state when to use this versus 'list_canned_services' for browsing, nor does it mention prerequisites like ID discovery.

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, 'Get' implies a safe read-only operation, but the description omits error handling, authorization requirements, and what constitutes 'detailed' information.

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

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

Single sentence, front-loaded with action verb, no redundancy. Every word earns its place in defining scope and resource.

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?

Adequate for a simple single-parameter getter, but given the lack of output schema and annotations, the description should ideally specify error behavior or the structure of the 'detailed information' returned.

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% and the parameter is already well-described. The description mentions 'by their ID' which aligns with the schema but adds no additional semantic clarity beyond the schema definition.

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

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

States specific action (Get), resource (customer), and scope (single by ID). The 'single' qualifier distinguishes it from the sibling list_customers tool, though it doesn't explicitly name the alternative.

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?

Implies usage context (when you have a specific ID) through 'by their ID', but lacks explicit guidance on when to prefer list_customers or error scenarios like 'customer not found'.

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 provided, so description carries full burden. States 'Get' implying read-only safety, but lacks disclosure of error behavior (e.g., 404 if ID not found), return structure, or what 'detailed information' encompasses.

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

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

Single 11-word sentence with no redundancy. Front-loaded with action verb, every word earns its place.

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

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

Adequate for a low-complexity single-parameter tool, though absence of output schema and annotations leaves gaps around return value structure and error states that a complete description should ideally address.

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

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

With 100% schema coverage (parameter 'id' fully documented), baseline is appropriately met. Description reinforces the ID parameter with 'by its ID', but adds no syntax specifics, format constraints, or examples beyond the schema.

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

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

Clear verb (Get), resource (inventory part), and scope (single item by ID). The phrase 'by its ID' distinguishes this from the sibling 'list_inventory_parts', though it does not explicitly reference sibling tools.

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

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

No guidance provided on when to use this tool versus siblings like 'search_parts' or 'list_inventory_parts'. Agents must infer that ID-based lookup is the intended 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 the full burden. It only states the core operation and does not disclose potential error behavior, response format, permissions, or side effects. For a read operation, this is a notable gap.

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

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

The description is a single, focused sentence that immediately states the purpose. There is no fluff or redundant information, making it highly efficient for an agent 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?

For a simple get-by-ID tool, the description is minimally adequate. However, it lacks context about when to use this tool versus list_labels or assign_label, and does not mention error handling or output expectations, which could confuse an agent in a large sibling set.

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 'id' parameter is already documented. The description merely repeats 'by its ID' without adding any new meaning, aligning with the baseline of 3 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 action (get), the resource (label), and the scope (single by ID). It distinguishes from list_labels (which retrieves multiple) and assign_label (which performs an action) through the explicit 'single' and 'by its ID' phrasing.

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?

Usage context is implied by the description and the tool's name—use when you have a specific label ID. However, there is no explicit guidance contrasting it with list_labels or assign_label, so the agent must infer when this tool is the right choice.

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 provided, so description carries full burden. States 'Get' implying read-only safety, but provides no details on error behavior (e.g., 404 for invalid ID), cache behavior, or what constitutes 'detailed' information beyond the order ID parameter.

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

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

Single front-loaded sentence of 10 words with zero redundancy. Every word earns its place: verb, resource scope, and key parameter reference.

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?

Adequate for a single-parameter retrieval tool with complete schema coverage. Acceptable given no output schema exists, though could benefit from noting that the ID must be known (likely from list_orders) and hinting at the data richness expected.

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 has 100% description coverage ('The work order ID'), so baseline is met. Description mentions 'by its ID' but adds no additional semantics regarding ID format, constraints, or lookup requirements beyond the schema definition.

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 'Get' with specific resource 'work order'. Scope qualifiers 'single' and 'by its ID' effectively distinguish this from sibling list_orders, though 'detailed information' is vague about what data is returned.

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?

Implicitly signals ID-based lookup via 'by its ID', distinguishing from list/search siblings. However, lacks explicit guidance on when to use list_orders first to find IDs, or error handling if ID is unknown.

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 provided, so the description carries full burden of behavioral disclosure. Fails to specify error behavior (e.g., invalid ID), authentication requirements, rate limits, or what constitutes 'detailed information'. Only implies read-only access through the verb 'Get'.

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

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

Single efficient sentence with zero redundancy. Information is front-loaded and appropriately sized for the tool's simplicity; every word earns its place.

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

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

Adequate for a simple retrieval tool with complete parameter schema. Lacks description of return values and error scenarios (compounded by missing output schema and annotations), but meets minimum viable standards for a single-parameter lookup 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 coverage is 100% with the 'id' parameter fully documented as 'The payment ID'. The description reinforces this with 'by its ID' but adds no additional semantic details, examples, or format constraints beyond what the schema provides. Baseline 3 is appropriate 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?

States specific action (Get) and resource (payment), and clarifies scope (single by ID). Implicitly distinguishes from list_payments by specifying 'single' and 'by its ID', though it doesn't explicitly name the sibling alternative.

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?

Lacks explicit when-to-use guidance; only implies an ID is required via 'by its ID'. Does not mention list_payments as the alternative when the payment ID is unknown, nor does it state prerequisites 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 provided, the description carries the full burden. It adds the detail that the information is 'detailed,' suggesting comprehensive data return, but lacks disclosure on error behavior (e.g., what happens if ID is invalid), authentication requirements, or rate limits.

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 (11 words) that front-loads the verb and resource. Every word earns its place; there is no redundancy or filler content.

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

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

Given this is a simple single-parameter lookup tool with no output schema, the description is sufficiently complete. It appropriately clarifies the domain context ('shop') and role equivalence ('user or technician') without over-specifying.

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% with the 'id' parameter fully described as 'The user/technician ID'. The description references the ID ('by their ID'), confirming the parameter's purpose, but does not add syntax constraints, format examples, or validation rules beyond the schema definition.

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

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

The description clearly states the action (get detailed information), resource (shop user or technician), and scope (single entity by ID). The word 'single' implicitly distinguishes this from the sibling 'list_users', though it does not explicitly name that alternative.

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 an ID is required ('by their ID'), but provides no explicit guidance on when to use this specific retrieval tool versus 'list_users' or 'search_parts'. It states the mechanism but not the selection criteria.

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

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

No annotations are provided, so the description must carry the full burden. While 'Get' implies a read-only operation, the description lacks details about error behavior (e.g., invalid ID), authentication requirements, or what specific 'detailed information' 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, efficient sentence with no filler. It immediately communicates the core purpose and required parameter without unnecessary words.

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

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

For a simple retrieval tool with one parameter and no output schema, the description is minimally adequate. However, given the lack of annotations and output schema, it should ideally mention error cases (e.g., vehicle not found) or the nature of the returned details.

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

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

With 100% schema coverage, the input parameter 'id' is already well-documented as 'The vehicle ID'. The description mentions 'by its ID' which aligns with the parameter usage but doesn't add significant semantic value beyond what the schema already provides, warranting 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 operation (Get), resource (vehicle), scope (single), and retrieval method (by ID). The phrase 'single vehicle' effectively distinguishes this from the sibling 'list_vehicles' tool, though it doesn't explicitly name that alternative.

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?

While 'by its ID' implies you need a specific identifier, there is no explicit guidance on when to use this versus 'list_vehicles' for searching, or what to do if the ID is unknown. No prerequisites or error conditions are mentioned.

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 implies a read-only operation but does not explicitly state side effects, error cases, or what happens if the webhook does not exist.

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 with no unnecessary details, perfectly matching the simplicity of the 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?

The description sufficiently conveys the purpose for a simple get operation. It could mention the return format or error behavior, but given the minimal complexity, it is nearly complete.

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

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

The schema already provides a clear description for the single parameter 'id' ('The webhook ID'), and the description adds no additional meaning. Since schema coverage is 100%, 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 action ('Get details'), the resource ('webhook'), and the scope ('single webhook by ID'), which distinguishes it from list_webhooks and other webhook 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?

No explicit guidance on when to use this tool over alternatives like list_webhooks, though the unique ID parameter implies its use case. The description is adequate but lacks explicit differentiation.

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 conveying behavioral transparency. It only states that the tool lists appointments, implying a read-only operation, but it does not explicitly confirm that it is side-effect-free, nor does it mention any authentication, rate limits, or potential failure modes. This lack of explicit behavioral detail is a significant gap.

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

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

The description is brief and to the point, consisting of two sentences with no redundant information. It avoids vague marketing language and directly states what the tool does and a key implementation nuance, making it easy to parse quickly.

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 covers the core functionality but omits some contextual details that would help an agent fully understand the tool. For example, it does not mention what the response structure looks like, whether the list is ordered, or how pagination variables interact (e.g., whether skip/limit are mandatory for large result sets). Given the absence of an output schema, this lack of return-shape information leaves a moderate gap.

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

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

Although the schema already provides descriptions for all six parameters, the description adds meaningful context by explaining that date-filtered queries are routed to a specific endpoint and that the range is applied server-side. This clarifies the behavior of the startDate and endDate parameters, going beyond the schema's simple 'Filter by...' descriptions. The other parameters (skip, limit, customerId, locationId) are adequately described by the schema and need no extra explanation.

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

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

The description clearly states the action ('List') and the resource ('appointments from Shopmonkey'), making the tool's purpose unambiguous. It also mentions filtering and pagination, which are key features that distinguish it from single-item retrieval tools like get_appointment.

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 explains that filtering and pagination are supported, and it gives a specific implementation detail about date-filtered queries going through the /appointment/search endpoint. However, it does not explicitly mention when to use this tool versus alternatives such as get_appointment for a single appointment or create/update for mutations, leaving the agent to infer the collection-focused 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?

With no annotations, the description carries the transparency burden. It states the operation lists templates but does not mention that it is read-only, pagination behavior, or that it returns a list. Basic but not exhaustive.

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

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

The description is two sentences with no redundant wording. It efficiently conveys the purpose and nature of the templates.

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 list operation, the description gives sufficient context about what the tool does and the nature of the items. It does not explain return format, but that is acceptable without an output schema.

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

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

The schema provides descriptions for all three parameters (skip, limit, locationId), so coverage is 100%. The description adds no extra parameter context, so baseline of 3 is appropriate.

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

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

The description clearly states the verb 'List' and the resource 'pre-built canned service templates from Shopmonkey', adding context that these are reusable templates for work orders. This is specific and unambiguous.

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

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

The description does not explicitly contrast with sibling tools like get_canned_service or create_canned_service. While it implies a listing operation, it lacks direct guidance on when to choose this over 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?

With no annotations, the description carries the burden. It implicitly signals a safe read operation via 'List' and defines the concept of deferred services, but does not explicitly mention side effects, output format, or ordering.

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

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

Two concise sentences with no filler. The definition and use case are front-loaded, making the purpose immediately clear.

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

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

The description is sufficiently complete for a simple read-only list operation. It defines the domain concept and use case, though it does not specify return fields or default ordering; these are not strictly required for basic correct invocation.

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

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

The input schema already covers all three parameters with clear descriptions. The tool description adds no additional parameter-level detail, 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?

States a specific verb ('list'), a specific resource ('deferred services for a customer'), and clarifies that deferred services are recommended-but-not-yet-performed work, distinguishing it from generic service listing tools.

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

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

Provides clear context by scoping to a customer and mentioning the intended use case ('revenue-opportunity surfacing in chat'), though it does not explicitly contrast with sibling tools like list_services or list_canned_services.

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 only mentions 'List parts' and 'Supports pagination' – it does not explicitly state that this is a read-only operation, nor does it disclose any side effects or return characteristics beyond pagination. The description adds little beyond what the schema already conveys.

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 short sentences, front-loaded with the core purpose and then a note on pagination. It is appropriately concise and easy to scan, though it could optionally mention the location filter or default behavior for slightly more completeness without losing conciseness.

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

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

For a simple listing tool, the description is adequate: it states the resource and pagination. However, it does not mention the locationId filter (covered in schema) or any ordering/defaults, and there is no output schema to clarify return structure. Given its simplicity, the description is acceptable but could be more complete by noting that it returns a list of parts.

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 all three parameters (skip, limit, locationId) already described in the schema. The description's mention of pagination reinforces the skip/limit parameters but adds no new meaning. Since the schema handles parameter documentation, a baseline of 3 is appropriate.

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

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

The description clearly states the action (list) and the resource (parts from Shopmonkey inventory). It also notes pagination support, which adds context. However, it does not explicitly distinguish this from sibling tools like list_inventory_tires or search_parts, though the distinction is somewhat implied.

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. It does not mention that search_parts is for filtering or that list_inventory_tires is for tires. The only context is the pagination note, which is more about parameters than usage. There is no explicit when/when-not 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 carries the full burden of disclosing behavior. It states it lists tires and supports pagination but does not explicitly confirm read-only side effects, result ordering, or error behavior. The description is too minimal to fully inform the agent about runtime implications.

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 short sentences conveying the essential purpose and a key capability. No redundant or irrelevant information is present, making it efficient and well-structured.

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

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

The tool has no output schema, so the description should compensate by explaining return values or result structure. It does not mention what the response contains (e.g., tire objects, total count, or next-page tokens). Without that context, the agent is left guessing about the output format, making the description incomplete for full contextual understanding.

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

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

All three parameters (skip, limit, locationId) have descriptions in the schema, providing full coverage. The description itself does not add extra meaning beyond the schema, so it meets the baseline for parameter clarity without enhancement.

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

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

The description clearly states the action ('List tires') and the resource ('Shopmonkey inventory'), which is specific and distinguishes it from sibling tools like list_inventory_parts. No ambiguity about what the tool does.

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 mentions pagination support but provides no guidance on when to use this tool versus alternatives (e.g., search_parts or list_inventory_parts). It does not state scenarios for using the locationId filter or any exclusions, leaving the agent without explicit usage context.

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

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

No annotations are provided, so the description carries the burden. The verb 'List' implies a read-only operation with no side effects, which is appropriate for this tool. It does not explicitly state read-only behavior, but given the nature of the action, the disclosure is adequate for typical usage.

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 consists of two concise sentences: the first states the core function, and the second explains a key use case. There is no redundancy or unnecessary detail, making it efficient and well-structured.

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

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

The description covers the tool's purpose and a practical use case. There is no output schema, but for a list operation, the response format is typically implied. The description does not specify pagination behavior or return fields, but the schema already documents skip and limit parameters, and the tool's purpose is straightforward, so it is sufficiently complete.

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

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

All four parameters are fully described in the schema (100% coverage), so the baseline is 3. The description adds context by framing the 'name' parameter as a filter to 'find a label ID before assigning it,' which helps the agent understand why they would use this parameter. However, the description adds little beyond the schema for skip, limit, and entity, so a 4 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?

Clearly states the verb 'List' and the resource 'labels defined in Shopmonkey' with context about custom tags. The description distinguishes from sibling tools like get_label (which retrieves a single label) and assign_label (which assigns a label), making the purpose unambiguous.

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

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

Provides a clear use case: 'Filter by exact name to find a label ID before assigning it.' This signals when to use the tool, but it does not explicitly mention alternatives such as get_label for cases where the ID is already known, so it falls slightly short of explicit when/when-not guidance.

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

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

The verb 'list' unambiguously implies a read-only operation with no side effects, conveying the behavioral profile effectively.

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

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

Two concise sentences deliver all necessary information without any fluff 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?

The description covers the object being operated on, the required parameters, and the prerequisite action, making it self-sufficient for the agent.

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

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

Both orderId and serviceId have clear descriptive definitions that explain their roles in the operation.

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

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

Clearly states the tool lists labor line items on a service, with the specific context of Shopmonkey's nesting under order > service.

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?

Provides a direct prerequisite hint to call list_services first to obtain the serviceId, which is practical usage guidance.

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

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

The verb 'List' implies a read-only operation, but no explicit mention of side effects or side effects absence. Given no annotations, it's reasonably transparent but could be more explicit about non-destructiveness.

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

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

Two concise sentences with no fluff, front-loading the primary purpose and then adding context.

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?

Provides sufficient context for when it would be used and why the returned location IDs matter. No output schema is provided, but the description covers the essential purpose.

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 covers both parameters with descriptions. Description adds no extra meaning beyond the schema, so baseline 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?

Clearly states it lists all shop locations, with a specific verb and resource. Unambiguous and distinct from any sibling tool.

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?

Provides a concrete use case (multi-location shops needing location IDs for filtering), though it doesn't explicitly state when not to use it or contrast with alternatives.

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

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

The word 'List' implies a read-only operation, but with no annotations and no mention of side effects, pagination behavior, or response shape, the behavioral transparency is average. It does not contradict any annotations because none are present.

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, but it includes an inaccurate reference to date range filtering that is not supported by the schema. It is short and front-loaded but not entirely accurate.

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

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

With no output schema and no annotations, the description is thin. It gives the basic purpose and filter hints, but omits pagination defaults, result shape, and the fact that date range filtering is not actually available. An agent could be misled into expecting a date range parameter.

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 descriptions fully cover the parameters, so the baseline is 3, but the description adds no extra value beyond the schema and introduces a misleading 'date range' filter that does not exist in the input schema. This detracts from clarity.

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

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

Clearly states a specific verb and resource: 'List work orders from Shopmonkey.' This distinguishes it from single-order tools like get_order and mutation tools like create_order/update_order. Minor deduction because the description mentions filtering by date range, but no date range parameters exist in the schema.

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

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

The description implies this tool is for listing multiple work orders, and the name contrasts with get_order, but it does not explicitly state when to use this tool versus alternatives. No when-not or alternative guidance is provided.

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 adds that filtering and pagination are supported, which is useful, but it does not mention return format, ordering, or any prerequisites. It also doesn't state that it is read-only, though 'list' implies it.

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

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

The description is two short sentences, front-loading the purpose ('List payments from Shopmonkey') and then adding the key capability. No unnecessary words.

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

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

For a simple list tool with fully documented parameters and no output schema, the description is sufficient to understand what the tool does. However, it omits details about the response structure and any limits, but these are not critical for a basic list 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 all four parameters (100% coverage), so the description adds little beyond the general statement of filtering and pagination. The defaults and env var behavior are already in the schema.

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

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

The description uses the specific verb 'List' with the resource 'payments' from Shopmonkey, clearly distinguishing it from the sibling tool get_payment (singular). It also notes support for filtering and pagination, which further clarifies its role as a collection-retrieval tool.

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 context that the tool supports filtering and pagination, implying it is for retrieving multiple payments with optional constraints. However, it does not explicitly state when to prefer this over get_payment or other list tools, nor does it mention 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?

No annotations are provided, so the description carries the full burden. It discloses the nesting behavior (services are nested under orders), which is useful structural context. However, it does not mention pagination behavior, response format, or any side effects. For a read-only list operation, this is somewhat minimal but not misleading.

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 action and immediately explains the key constraint. There is no wasted verbiage, and the structure is clear and efficient.

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

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

For a simple list tool with pagination parameters and no output schema, the description provides enough context: it states the purpose, the required parameter, and the data model. It could optionally mention pagination defaults, but those are already in the schema. The description is complete enough for an agent to call the tool correctly.

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

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

The schema already covers all three parameters (100% coverage), so the baseline is 3. The description adds semantic value by explaining why orderId is required and how the data is structured, which goes beyond the schema's simple field descriptions. This enhances the agent's understanding of the parameter's role.

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 lists services on a work order, with a specific verb, resource, and scope. It also explains the nesting context, which distinguishes it from other list tools in the sibling set. The purpose is unambiguous and differentiates it from tools like list_canned_services or list_labor.

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

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

The description explicitly states that orderId is required and explains why (services are nested under orders, no flat list). This gives clear context for when to use the tool and the necessary precondition. While it doesn't mention alternatives or when not to use, the guidance is adequate for this simple tool.

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 implies a read-only list operation but does not explicitly state the absence of side effects or any authorization requirements. The verb 'list' suggests non-mutating behavior, but it is not stated explicitly.

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

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

The description is a single concise sentence that directly states the tool's function without any redundant information. It is well-structured 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?

For a simple list operation, the description is sufficient even without an explicit return format. It could mention what fields are returned, but the absence is minor given the tool's simplicity and the parameter clarity.

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 descriptions fully cover all six parameters (pagination, filters, location default), so the tool description adds no additional meaning beyond what is already in the input schema. This is exactly the baseline 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 lists technician time clock events and tracks clock-in/clock-out for shop staff, using a specific verb ('list') and resource ('technician time clock events'). It leaves no ambiguity about the tool's 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 guidance on when to use this tool versus alternatives, though no direct sibling for timeclock events exists. It does not elaborate on filtering or pagination, relying instead on parameter descriptions.

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 relies on 'List' to imply read-only behavior, but it does not explicitly mention side effects, authorization, or pagination 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?

Single, front-loaded sentence; concise and 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?

Description plus schema is sufficient for a simple list operation, though no output shape is described; not a major gap.

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

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

All three parameters are documented in the schema with descriptions and defaults; the description adds no extra semantic detail.

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

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

Description states the verb ('List') and resource ('shop users and technicians') clearly, but does not explicitly differentiate from sibling tools like get_user.

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

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

No guidance on when to use this tool instead of get_user or other list tools; the only implication is from the tool name.

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 only states the action without mentioning whether it is read-only, what the output looks like (e.g., full customer objects vs. IDs), or any semantics around 'associated' (e.g., historical vs. current owners). These are gaps for a list operation with zero annotation coverage.

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

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

The description is a single sentence that gets straight to the point. It uses the imperative 'List' and front-loads the action and resource, with zero filler or redundant phrasing.

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

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

For a simple one-parameter list tool, the description covers the core purpose but leaves some gaps. It does not specify the shape of the returned customers (e.g., full objects, references), nor clarify what 'associated' means (current vs. historical). Without an output schema, a bit more detail on the return value would improve completeness.

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

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

The schema already describes the sole parameter (vehicleId) with a matching description ('The vehicle ID to list owners for'). The tool description adds no additional meaning beyond that, so it meets the baseline of 3 given 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 action (list) and the resource (customers), scoped to 'a specific vehicle'. It is distinct from sibling tools like list_vehicles_for_customer, which does the reverse. The verb and object are specific and unambiguous.

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

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

The description provides no guidance on when to use this tool versus alternatives such as list_vehicles_for_customer or get_customer. It does not mention any exclusions, prerequisites, or conditions that would steer an agent toward or away from this tool.

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 present, the description carries the full behavioral burden, but it only states the listing action and does not disclose pagination behavior, read-only nature, or potential edge cases.

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, clear sentence with no unnecessary words or repetition.

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

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

For a simple list operation with a well-defined parameter set, the description is adequate, though it does not mention output shape or pagination details beyond the schema defaults.

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 already provides descriptions for all three parameters, so the description adds no additional semantic value beyond what is already in the input schema.

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

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

The description clearly states the action ('List') and the resource ('vehicles associated with a specific customer'), distinguishing it from sibling tools like get_vehicle or lookup_vehicle_by_vin.

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

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

The description implies when to use the tool (when needing all vehicles for a customer) but does not explicitly contrast it with alternatives such as get_vehicle or lookup_vehicle_by_vin.

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

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

With no annotations, the description carries the full burden of disclosing side effects. It only says 'List', which implies a read-only operation, but does not explicitly state that no modifications occur or that authentication is required. The absence of any side-effect disclosure is a minor gap.

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

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

The description is a single, concise sentence that immediately conveys the tool's purpose. It is front-loaded with the verb and resource, with no fluff 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 simple list operation, the description is complete enough. It does not require an output schema explanation, and the pagination parameters are already documented. It could mention whether the list is ordered or includes archived webhooks, but such details are beyond the minimal context needed to invoke the tool successfully.

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 already provides descriptions for both skip and limit parameters (100% coverage). The description adds no additional meaning about how these parameters affect the listing, such as sorting or default pagination behavior, so it neither enhances nor detracts from the schema.

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

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

The description clearly states the action (list) and resource (all registered webhooks in Shopmonkey), and naturally distinguishes itself from the sibling get_webhook, which retrieves a single webhook.

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?

While the description implies its use for retrieving all webhooks, it does not explicitly mention when to use this tool versus get_webhook, create_webhook, update_webhook, or delete_webhook. No direct alternative guidance is provided.

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 provided, so description carries full burden. It explains what data represents (progression stages) but discloses no API behavior: no mention of idempotency, caching, rate limits, error handling, or return structure. 'List' implies read-only but doesn't confirm safety or scope.

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 front-loaded sentences with minimal redundancy. 'Workflow/pipeline' is slightly redundant, and 'Shows' is weaker than 'Returns,' but overall efficient and appropriately sized for the tool's complexity. No structural waste.

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?

Adequate for a single-parameter read tool with complete schema coverage. Explains the domain concept (workflow statuses) but misses the location filtering aspect and lacks output description (though no output schema exists to constrain it). Acceptable 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 coverage is 100%, establishing a baseline of 3. The description adds no parameter-specific context (doesn't mention locationId or the env var fallback), but the schema adequately documents the single optional parameter without requiring supplementary description.

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

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

Clear verb 'List' and specific resource 'workflow/pipeline status stages'. The phrase 'progression stages work orders move through' effectively clarifies this returns status taxonomy/metadata rather than actual orders, distinguishing it from sibling tools like list_orders. Deducts one point for not explicitly naming the distinction from order-listing tools.

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

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

Provides no guidance on when to invoke this tool versus alternatives. Does not explain typical use cases (e.g., fetching statuses to populate a dropdown filter) or prerequisites (e.g., needing location context). Purely descriptive without prescriptive 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?

No annotations are provided, and the description does not disclose any behavioral details such as read-only nature, potential errors, or side effects. It only states the basic action without elaboration, so the description carries the full burden and falls short.

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 immediately states the verb and resource. It is front-loaded, contains no unnecessary words, and effectively communicates the tool's core function.

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

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

For a simple lookup operation, the description adequately conveys what the tool does and the inputs it requires. It does not mention output format, but the absence of an output schema and the straightforward nature of the lookup make this acceptable.

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

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

The schema already provides descriptions for both parameters ('License plate number' and 'Region/state code'), so the coverage is 100%. The tool description adds no extra meaning beyond repeating the purpose, so it does not enhance the parameter understanding beyond the schema.

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

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

The description clearly states the tool's function: looking up a vehicle by license plate and region. It identifies the resource (vehicle) and the specific identifiers (plate and region), and it is easily distinguishable from sibling tools like lookup_vehicle_by_vin.

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 explains what the tool does but does not explicitly mention when to prefer it over alternatives (e.g., lookup_vehicle_by_vin). It provides no conditions or context for use, leaving the agent to infer when this lookup is appropriate.

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

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

No annotations are provided, so the description carries the full burden. It only states the action and resource, without disclosing behavior such as read-only nature, error handling, or what happens if the VIN is not found. It does not contradict annotations (none exist).

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. It efficiently communicates the tool's purpose without unnecessary detail.

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

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

For a simple single-parameter lookup, the description is minimally adequate but lacks return format information and any note about uniqueness or error cases. With no output schema, an agent might be uncertain about what the response contains.

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%, and the schema already documents the 'vin' parameter. The description merely restates 'by its VIN', adding no new semantic meaning beyond the schema. Baseline 3 is appropriate.

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

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

The description states a specific verb ('Look up'), a specific resource ('vehicle'), and the exact key ('VIN'), which clearly distinguishes it from sibling tools like lookup_vehicle_by_plate and get_vehicle. The scope is unambiguous.

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

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

No guidance is provided on when to use this tool versus alternatives such as get_vehicle (by ID) or lookup_vehicle_by_plate. The description does not mention any exclusions or selection criteria.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states 'Remove' but does not disclose side effects such as whether removal is permanent, whether it requires specific permissions, or what happens if the fee item does not exist. This is a destructive operation with no transparency beyond the verb.

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

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

The description is a single, focused sentence with no redundant words or information. It is appropriately concise for the tool's simple 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?

For a straightforward removal operation with two fully documented parameters, the description is minimally adequate. However, it omits any mention of prerequisites (e.g., whether the canned service must exist) or error behavior, and it does not reference the family of canned-service fee tools. Given the tool's simplicity, a 3 reflects the lack of additional useful 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?

The input schema fully describes both parameters (itemId and cannedServiceId) with clear descriptions, and schema coverage is 100%. The tool description adds no additional parameter context, so 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 uses a specific verb ('Remove') and a clear resource ('fee line item from a canned service template'). It unambiguously distinguishes from sibling tools like update_canned_service_fee or remove_canned_service_labor, which operate on different entities.

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

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

No guidance is provided on when to use this tool versus alternatives, such as update_canned_service_fee for modifying a fee or add_canned_service_fee for adding one. The description only states what it does, leaving the agent to infer appropriate usage context.

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

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

Without annotations, the description carries the full burden. It only says 'Remove' without disclosing side effects, permanence, permission requirements, or behavior when the item does not exist. This lack of detail leaves behavioral ambiguity for a destructive 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 a single, clear sentence with no unnecessary words or repetition. It is structurally efficient and immediately understandable.

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 covers the basic intent but lacks contextual details such as whether the removal is permanent, whether it affects existing orders using the template, or what the expected return value is. For a destructive operation, this additional context would be valuable but is absent.

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

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

The schema provides descriptions for both parameters (cannedServiceId and itemId), so the description does not add new meaning. It simply echoes the schema's own descriptions, resulting in no additional semantic value beyond what is already structured.

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

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

The description clearly states the action (remove) and the resource (a labor line item from a canned service template). It is specific enough to distinguish from sibling removal tools like remove_canned_service_fee or remove_canned_service_part.

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 by naming the exact resource, but it does not explicitly contrast with other removal tools or provide conditions for when to choose this tool over alternatives. No additional guidance such as prerequisites 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?

No annotations are provided, so the description carries full responsibility for behavioral disclosure. It states the action 'Remove' which implies mutation, but does not disclose whether the removal is permanent, if it cascades to other items, or any side effects. This is a minimal disclosure for a destructive 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?

A single, concise sentence that states the action clearly without unnecessary words. It is appropriately sized and front-loaded with the verb, making it easy to parse quickly.

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

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

For a simple removal tool with two well-documented parameters and no output schema, the description covers the core action. It doesn't mention return values or error conditions, but these are often implicit for removal operations. The tool's simplicity means this is largely complete.

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

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

The schema descriptions for both parameters are explicit ('The part line item ID to remove' and 'The canned service ID'), covering 100% of parameters. The description adds no additional meaning beyond these, so it provides no extra value for parameter understanding. Baseline 3 is appropriate given 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 uses a specific verb 'Remove' and clearly identifies the resource as 'a part line item from a canned service template'. This distinguishes it from sibling tools like remove_canned_service_fee or remove_canned_service_labor by explicitly naming the part line item, making the purpose unambiguous.

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

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

The description provides no explicit guidance on when to use this tool versus alternatives. The implied usage is clear from the tool name and description, but there is no mention of alternatives or exclusions. An agent must infer that this tool is for removing parts specifically, as opposed to fees, labor, or tires.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It only restates the operation without any details on side effects, idempotency, error handling, or whether the deletion is permanent. This is minimal 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 directly communicates the tool's purpose without unnecessary words or repetition.

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

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

The tool is simple, with no output schema. The description sufficiently explains the action, though it could benefit from noting whether the operation is idempotent or what happens if the subcontract item does not exist. Overall, the context is adequately covered for an agent to use the tool correctly.

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

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

The schema already provides descriptions for both parameters, so coverage is 100%. The description adds no additional meaning about how the parameters relate or any constraints, keeping it at 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 action (remove) and the specific resource (subcontract line item from a canned service template), distinguishing it from other removal tools like remove_canned_service_fee or remove_canned_service_part.

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 usage is implied by the action description rather than explicitly stated. It does not mention when to prefer this tool over alternatives, nor does it provide any exclusions or conditions. However, the purpose is specific enough that an agent could infer when 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?

No annotations are provided, so the description carries the full burden. It states a removal action but does not disclose side effects, reversibility, idempotency, or error behavior. The minimal description leaves behavioral aspects transparent but insufficiently detailed.

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 with no unnecessary detail. It is well-structured and front-loaded with the primary action.

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 adequate for a simple removal operation, but it lacks context about preconditions (e.g., whether the item must exist) or consequences (e.g., whether it permanently deletes or soft-deletes). Given the absence of an output schema, some assumptions remain unstated.

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

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

The input schema already provides descriptions for both parameters (itemId and cannedServiceId), covering 100% of the fields. The description adds no extra semantic meaning beyond what the schema already provides, so the baseline of 3 is appropriate.

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

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

The description clearly states the action: removing a tire line item from a canned service template. It specifies the resource (canned service) and the item type (tire), distinguishing it from other removal tools like remove_canned_service_part or remove_canned_service_fee.

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 is clear about what it does but does not explicitly mention when to use it over alternatives (e.g., update_canned_service_tire). It implies usage for removing tire items from canned templates, but lacks explicit guidance on selection criteria.

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

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

With no annotations provided, the description carries the full burden. It transparently states that it generates a summary, counts by status, and uses the /appointment/search endpoint with server-side date filtering. It implies a read-only operation with no side effects, which is adequate. It does not explicitly mention that no data is modified, but the language 'generate' and 'counts' strongly suggests that.

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

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

The description is two sentences with no redundant words. It front-loads the core purpose, then adds a relevant implementation detail. Every sentence contributes meaningful 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 simple summary tool, the description covers the essential context: what it does, the status categories, and that filtering is server-side. It does not specify the exact return format (e.g., JSON structure), but that is likely evident from the tool's name and typical usage. The absence of an output schema is not a critical gap given the clear summary nature of the tool.

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

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

The schema descriptions already cover startDate, endDate, and locationId with clear meanings (ISO 8601, filter by location, default to env var). The description adds minimal extra semantic value beyond noting server-side filtering, which is already implied by the date parameters. Since schema coverage is 100%, a 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 action ('Generate an appointment summary'), the resource ('appointment summary'), and the specific output ('Counts appointments by confirmation status (Confirmed/Declined/NoResponse)'). This distinguishes it from sibling tools like list_appointments, which would return raw appointment objects, and report_revenue_summary, which focuses on revenue.

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 implicit usage guidance by indicating that it produces a summary count rather than individual appointments, so an agent would infer to use this when needing aggregated counts by status. It also notes that filtering happens server-side via /appointment/search, which is a useful behavioral hint. However, it does not explicitly name alternative tools or contrast when to use them.

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

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

With no annotations, the description carries the transparency burden. It discloses pagination behavior and the returned `truncated` flag, which is important for large result sets. It implies a read-only listing operation but does not explicitly state side effects or data freshness.

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 three sentences, front-loaded with the primary purpose, and contains no redundant or filler content. It efficiently adds usage context and pagination warnings.

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 output schema, the description adequately covers the key return concept (estimates with age in days) and the pagination/truncation behavior. It could mention sort order or additional returned fields, but the core information needed for the stated use case is present.

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, `locationId`, is fully described in the schema including its default behavior. The tool description adds no additional parameter-specific meaning, so the baseline 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 lists open (unauthorized) estimates and includes their age in days, making the resource and action unambiguous. It distinguishes estimates from other order- and report-related siblings.

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

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

The description provides a specific use case ('follow-up on stale estimates'), giving clear context for when to use the tool. It does not explicitly name alternative report tools or state when not to use it, but the intended scenario is clear.

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

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

With no annotations provided, the description carries the full burden of behavioral transparency. It discloses that the tool pages through the full order list, returns a truncated flag for large shops, and aggregates by status while splitting paid/unpaid revenue. It does not explicitly state that it is read-only, but the 'generate a summary' phrasing implies no side effects. Overall, it provides adequate behavioral insight without exhaustive detail.

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. It starts with the primary purpose, then provides relevant details about filtering, aggregation, and pagination in a clear, logical order. No unnecessary words or redundancy are present, making it efficient for an agent 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?

The description gives sufficient context for an agent to use the tool correctly, including the specific date filter, aggregation criteria, and pagination behavior with the truncated flag. It does not describe the exact output schema, but that is acceptable given the absence of an output schema. The description could be slightly more explicit about the response structure, but it is complete enough for typical 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?

The schema descriptions cover all three parameters (startDate, endDate, locationId) at 100% coverage. The tool description adds no additional parameter semantics beyond what is already in the schema. For example, it does not explain that locationId defaults to an environment variable, but that is already in the schema. Therefore, the description provides no extra value for parameter understanding, warranting the baseline score of 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's function: generating a revenue summary for orders invoiced within a date range. It specifies the key filter (invoicedDate) and distinguishes it from order creation date, making the purpose unambiguous. It also differentiates from sibling report tools by focusing on revenue aggregation.

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 implicit usage guidance by emphasizing the invoicedDate filter, which tells an agent when to use this tool instead of other order-related reports. It also mentions pagination and the truncated flag, which helps in handling large result sets. However, it does not explicitly compare to alternative report tools or state conditions for selection, so a minor gap remains.

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