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

No annotations provided, so description carries full burden. States 'automatic' creation but fails to disclose critical behavioral traits: whether this creates a binding financial commitment, if it's reversible (cancel order sibling exists), rate limits, or what success/failure looks like. For a transactional mutation tool, this is a significant gap.

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

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

Contains grammatical error ('需要需要' - repeated word). Structure is run-on with poor punctuation usage. Information is front-loaded but parameter listing is awkward. Not efficiently structured despite being short.

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 2-parameter creation tool with no output schema, the description covers the prerequisite workflow (price calculation) but omits what the tool returns (likely order ID/details) and lacks safety warnings appropriate for order creation operations.

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, baseline is 3. The description adds valuable workflow context that price_token must come from the price calculation interface, which aids parameter understanding beyond the schema's type information.

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 '自动创建订单' (automatically create order) which clearly identifies the action and resource. Mentions the price_token prerequisite which implicitly distinguishes this from the sibling '订单询价' (price inquiry) tool, though it could explicitly name that 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?

Implies workflow sequence by noting price_token must come from the price calculation interface, but lacks explicit when-to-use guidance (e.g., 'Use this after getting a price quote') or exclusions (e.g., 'Do not use if price is not confirmed').

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. While '取消' implies a write/mutation operation, the description fails to disclose consequences (refunds, fees), reversibility, or state transitions. No mention of rate limits 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 structure with action front-loaded. Appropriately brief for the tool complexity, though contains a typo ('需要需要'). No wasted words otherwise.

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 2-parameter tool but missing lifecycle context crucial for cancellations (e.g., 'can only cancel pending orders'). Does not compensate for lack of output schema with explanation of return values or side 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?

Schema coverage is 100%, establishing baseline 3. Description mentions order_code but entirely omits the required 'reason' parameter. Adds no semantic context beyond schema (e.g., no format details, constraints, or examples beyond what's in 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?

States specific verb (取消/cancel) and resource (订单/order) clearly. However, lacks explicit differentiation from siblings (e.g., when to cancel vs. when to create or query), though the action itself 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?

Provides minimal guidance - only mentions that order_code is required. Contains no information about when cancellation is appropriate (e.g., order states), timing restrictions, or prerequisites. No 'when-not' guidance 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 fails to mention whether this is a read-only operation, what happens if the order_code is invalid/not found, return value structure, or any rate limiting concerns. Only the basic input requirement is stated.

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

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

The description is appropriately brief and front-loaded with the action verb. However, it contains a repetition typo ('需要需要') and redundant phrasing that reduces clarity. Despite the brevity, the quality issues prevent a higher score.

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 single-parameter lookup tool without an output schema, the description meets minimum viability by identifying the required input. However, it lacks completeness regarding error scenarios, the nature of the 'details' returned, or authentication requirements, leaving significant gaps for an unannotated 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 input schema has 100% description coverage with clear titles and descriptions. The description text repeats the parameter name ('订单编号order_code') but adds minimal semantic value beyond what the schema already provides, meeting the baseline expectation 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 clearly states the action ('获取订单详情' - get order details) and the required resource. However, it does not explicitly differentiate from sibling tools like '取消订单' (cancel) or '订单询价' (inquiry) within the text itself, relying instead on the tool name for distinction.

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

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

The description provides no guidance on when to use this tool versus alternatives such as '订单询价' (inquiry) or '跑男信息查询' (runner query). It states what input is needed but not the contextual conditions or prerequisites for selection.

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

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

With no annotations provided, the description carries full burden but discloses nothing about side effects (whether this creates a temporary quote ID), idempotency, rate limits, or response format. Only input requirements are mentioned.

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

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

Single sentence is appropriately front-loaded (purpose first), though marred by a typo ('需要需要'). No structural waste, but the typo slightly undermines professionalism.

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?

Lacks output schema coverage, so description should explain return values (price structure, validity period). Also fails to mention the required city_name parameter, leaving the description incomplete for the 3-parameter 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?

Schema coverage is 100%, establishing baseline 3. The description mentions start/end addresses but entirely omits the required 'city_name' parameter, adding no additional syntax guidance beyond what the schema already provides.

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

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

The description states the core function ('查询订单价格') with specific verb and resource, but fails to distinguish from sibling '智能发单-创建订单' (e.g., clarifying this is a pre-creation price check vs. actual booking).

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 versus alternatives. Missing critical workflow context that this should be called before '创建订单' to determine pricing, or when to skip 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 provided, so description carries full burden. It does not disclose what runner data is returned (location, contact, status), whether it's real-time (implied by name only), or any latency/caching behavior. '查询' implies read-only but this is not explicit.

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?

Appropriately brief for a single-parameter tool, but contains wasteful repetition ('需要需要'). The front-loading is correct (action first), but the typo reduces clarity per the 'every sentence earns its place' standard.

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?

Insufficient for the tool ecosystem. With '获取订单详情' as a sibling, the description must clarify whether this returns runner-specific data (location, phone) vs general order metadata. No output schema exists, yet the description doesn't compensate by describing return contents.

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 for the single parameter. The description mentions needing an 'order number' but adds no format details, examples, or semantics beyond what the schema already provides. 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?

States the basic action (query runner information) and required input, but fails to differentiate from sibling '获取订单详情' (Get order details). The name suggests real-time tracking ('实时信息'), but the description omits this key scope detail.

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 use this tool versus '获取订单详情' or other siblings. No mention of prerequisites (e.g., order status requirements) 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.