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

With no annotations, the description carries the burden and does well: it discloses the user-visible side effect (a browser window opens), the blocking wait bounded by wait_seconds, the partial-success return shape (waiting: true), and the 5-minute continuation window. It stops short of saying what happens on hard failure or whether the window is closed afterwards.

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?

Four short lines, front-loaded with the action, then the wait semantics, then the trigger condition. No filler; each sentence adds operational 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?

There is no output schema, but the description compensates by naming the one returned field the agent must branch on (waiting: true) and the required follow-up call. Minor gap: no statement about failure modes or whether an already-valid session short-circuits.

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 0%, so the description must explain the single parameter — and it does: wait_seconds is a timeout after which control returns even though sign-in continues. That 'continues for up to 5 minutes' nuance is genuinely unavailable from the schema, including the default of 45.

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 concrete action (open a browser window) and its goal (one-time user sign-in), which is unmistakably distinct from the sibling auth_status, which it explicitly names as the follow-up step.

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?

Gives an explicit trigger ('Use when a write tool returns AUTH_EXPIRED') and an explicit exclusion ('Read-only tools (catalog, quote, read_price_list) never need this'), naming concrete siblings. An agent can decide whether to call this without any further inference.

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 exist, so the description carries the full burden. It does disclose the return payload (account mask, browser, cookie names) and a cost-relevant guideline that read-only flows can skip it. It omits what happens when unauthenticated (error vs. signed-in=false) and how that state should be handled.

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?

One compact sentence plus a usage caveat, front-loaded with the core purpose. Slightly telegraphic parenthetical, but no wasted sentences.

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 parameters, no annotations, and no output schema, the description covers both what the call returns and when it can be skipped. The main remaining gap is the unauthenticated outcome and the handoff to auth_login, which is minor for a zero-arg status probe.

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

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

The tool takes zero parameters and the schema confirms an empty object, so there is nothing parameter-wise to explain. Baseline 4 applies; the description correctly adds no noise about arguments.

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 check (whether the browser profile is signed in) and even names the returned fields (account mask, browser, cookie names). It's distinguishable from auth_login by implication (status vs. login), but it never names that sibling explicitly, so it falls short of a 5.

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

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

"Read-only tools never need it" is a useful negative rule that implicitly scopes the tool to pre-flight checks before mutating operations. But it never says explicitly when to call it, nor does it point to auth_login as the remedy when the status shows signed out.

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 exist, so the description carries the full burden. It does disclose output content ('cost per mode and the saving vs on-demand') and that modes are ondemand/monthly/yearly, which is valuable since there is no output schema. It omits that this is a non-mutating calculation and says nothing about whether region/currency affect which prices are used.

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?

Three short lines, front-loaded with the core action, followed by item format, return values, and valid modes. No filler, though the backtick/newline formatting makes it slightly clipped.

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 annotations and no output schema, the description must explain both behavior and returns. It covers the return content at a high level but not its structure (e.g., keys per mode, currency of the saving), and gives no guidance on how region/currency interact with the comparison.

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 0%, so the description must compensate. It documents the `items` element shape ([{service, spec, quantity, size, usage_*}]) and enumerates the mode strings, but leaves `region` and `currency` unexplained beyond their schema defaults — their accepted formats and effect on results are unstated.

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 (compare) and resource (bill of materials across billing modes), plus what is returned. It implicitly differentiates from sibling compare_regions by scoping to modes, though it never names that sibling.

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 is implied: use it to evaluate the same BOM under ondemand/monthly/yearly pricing. There is no explicit when-to-use guidance, no prerequisites (e.g., do you need auth or a price list first), and no named alternative such as compare_regions.

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. "Price" implies a read-only computation, and "Friendly names accepted" hints at tolerant input, but there is no mention of return format, whether results are persisted, auth needs, or error 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?

Two short, front-loaded sentences with no waste. The second sentence is a terse fragment, but it adds a genuinely useful input nuance.

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 3-parameter tool with zero annotations and no output schema, the description is thin: it omits what the comparison result looks like, how billing applies across regions, and whether the call has 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 description coverage is 0% across 3 parameters. Only the regions parameter gets any elucidation (friendly names rather than codes); the items object shape and the billing enum (ondemand/monthly/yearly) are not explained in the description, leaving most semantics to be inferred.

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 ("Price") and resource ("bill of materials in several regions"), making clear it's a multi-region pricing comparison. It implicitly separates itself from compare_modes and list_regions, but never names them, so sibling differentiation is only partial.

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 (compare prices across regions) but gives no conditions for choosing this over compare_modes, quote, or list_regions, and no exclusions or prerequisites.

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 usefully discloses that the rate comes from Huawei Cloud's own published rate rather than a market feed, which matters for quoting. It says nothing about rate freshness, rounding/precision, or what happens for unsupported currency codes.

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 front-loaded sentence with the key constraint (USD amount, published rate) first and two concrete examples that earn their place. No filler.

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, the description should ideally hint at what comes back (converted amount, rate used), and it does not. Otherwise, for a simple two-parameter calculation tool with no annotations or nested objects, the essential information 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?

Schema description coverage is 0%, so the description must compensate: it clarifies amount_usd is in USD and gives example currency codes (BRL, EUR), which adds real value. It still omits that currency is presumably an ISO code, its case sensitivity, and the set of supported values.

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 (convert) and the exact resource (a USD amount) plus the rate source, so an agent knows precisely what this does. It is clearly distinct from every sibling in the list (quote, pricing, auth tools), though it never states the inverse direction is unsupported.

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 phrase 'Convert a USD amount' implies the direction (USD in, foreign currency out), which is a real usage constraint. But there is no explicit when-to-use, no note on when to call this versus just reading a price list, and no guidance on which currencies are accepted.

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 and does well: it discloses authentication requirement and irreversibility ('this cannot be undone'). It omits behavior for missing/unauthorized ids, which keeps it from a 5.

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?

Three tight sentences: what it does, prerequisite, safety instruction. Front-loaded and every sentence 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?

For a one-parameter, no-annotation, no-output-schema mutation, the description covers auth, irreversibility, and confirmation. Only the identifier format is left uncovered.

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 0% and the single parameter 'url_or_id' is undocumented, so the description must compensate. Saying 'by url or id' only echoes the parameter name and gives no format guidance for what an id looks like.

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 (Delete) and resource (saved price list) plus the two accepted identifier forms. It clearly distinguishes itself from read-only siblings like read_price_list, though it doesn't explicitly name them.

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?

Gives an explicit prerequisite ('Needs a login') and a mandatory workflow step ('Confirm with the user before calling'). It doesn't name alternatives, but the destructive framing makes the when-to-use condition obvious.

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 behavioral burden. It usefully signals that specs are only 'a sample' (not exhaustive) and that the tool is a read/discovery lookup, but it says nothing about auth requirements or response shape.

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 short sentences with the capability stated first and the usage cue second; nothing is wasted. The phrasing 'so the agent knows the valid options' is slightly redundant but harmless.

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 discovery tool with no annotations and no output schema, the description gives a decent sense of what comes back (modes, groups, sample specs) and when to call it. But parameter details and the incomplete-coverage caveats leave gaps an agent would need filled.

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 0%, so the description must compensate. It does reference both concepts (service and region), but provides no format guidance, no mention that region defaults to 'sa-brazil-1', and no indication that service is the only required 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?

States a specific verb and resource: it describes what a service supports in a region (modes, groups, sample of specs). This is more informative than the bare name suggest, though it does not explicitly name the sibling tools (supported_services, list_services, compare_modes) it differs from.

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?

'Use before building a list' gives a clear trigger for when to call it, which is genuinely actionable. However, no alternatives or exclusions are named, so the agent must infer that list_services/supported_services are the follow-up rather than substitutes.

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 behavioral burden well: it discloses auto-confirmation of exact matches, candidate presentation for non-exact requirements, and the important side effect that nothing is saved on the website. It also specifies units for sizes and bandwidth. It does not mention authentication or error behavior, but the key behavioral traits for this tool are 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 compact and front-loads the core action before defining the requirements structure. Every sentence carries useful information about fields, matching behavior, or units. The inline JSON-like requirement format is dense but necessary, though it could be slightly easier to scan if structured more formally.

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

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

For a tool with an output schema, no annotations, and a required nested requirements array, the description covers the important operational context: requirement fields, automatic confirmation, user review flow, non-persistence, and units. It is nearly complete, with the only notable omission being the meaning or format of the customer 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?

Schema description coverage is 0%, so the description must compensate, and it largely does: it defines the requirement object fields, including id, service, region, billing values, optional quantity, needs with vcpus and memory_gb, spec, and options. It also explains that options are listed by supported_services and gives units for sizes and bandwidth. The customer parameter remains unexplained, which is the main gap.

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 gives a specific verb and resource: starting a quote with a structured requirements list. It distinguishes itself from revise_quote by explaining that exact matches are confirmed automatically while non-exact matches require user review and revise_quote. It is clear, though the opening 'Start a quote' alone would be vague without the requirement details that follow.

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?

It clearly states the expected workflow: exact matches are auto-confirmed, and non-exact matches should be shown to the user and followed by revise_quote. It also clarifies that nothing is saved on the website, which helps distinguish drafting from publishing. It does not explicitly mention when to use draft_quote versus other quote-related siblings beyond revise_quote, keeping it just short of a 5.

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 does disclose two behavioral facts: an auth requirement and that the operation produces a copy (leaving the source list intact). It does not say what is returned (new list ID/URL), where the copy appears, or whether the copy inherits sharing settings — meaningful gaps for a mutation tool.

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

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

Two short sentences, front-loaded with the action and followed by the auth prerequisite; nothing is wasted. The fragment "Needs a login" is terse to the point of being abrupt but costs no clarity.

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

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

For a mutation tool with no annotations and no output schema, the description is too thin: an agent still cannot tell what it gets back, how to identify the new list, or what format url_or_id takes. It covers the auth and optional-name basics but leaves the critical call-shaping details unaddressed.

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 0%, so the description must carry parameter meaning. It clarifies that new_name is optional and overrides the name only, but says nothing about url_or_id — whether it accepts a URL, a numeric ID, or both — leaving the required parameter undocumented in both places.

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?

"Copy a saved price list (optionally with a new name)" gives a specific verb (copy) and resource (saved price list), which distinguishes it from rename_price_list or read_price_list by implication. It is clear but never names those siblings explicitly, so the differentiation relies on the reader inferring it.

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 prerequisite "Needs a login" is stated, which is useful context for when the call can succeed. However, there is no guidance on when to prefer duplicate over rename_price_list or read_price_list, and no explicit exclusions, so usage is only implied.

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 and does substantial work: it discloses anonymous read access, that `path` is overwritten, and the atomic all-or-nothing guarantee ('Nothing is written if any list cannot be read'). These are exactly the side-effect and failure semantics an agent needs before a write 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?

Front-loaded with the purpose and output sheets, then constraints. Dense but nearly every clause carries information; the awkward line breaks and trailing parenthetical 'kept in this order' add minor noise but no real 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?

For a no-annotation, no-output-schema tool, the description covers the produced artifact, auth model, and failure behavior. It stops short of describing error reporting or how unreadable lists are signalled, but an agent has enough to invoke it 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?

Schema coverage is 0%, so the description must compensate, and it does: it defines the row object shape (env, list as share url or id, optional draft_id), the ordering guarantee, and the `.xlsx` suffix requirement for `path`. Both parameters gain meaning that the bare schema does not provide.

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 and resource — 'Write a workbook of price lists, one row per environment' — and enumerates the four sheets produced. The agent knows exactly what artifact this creates without opening the schema, and the publish_quote cross-reference distinguishes it from read_price_list.

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?

Explains the draft_id condition ('a list saved by publish_quote finds its decisions by itself; draft_id is for any other'), which is real usage guidance. However, it never states when to choose this export over sibling readers like read_price_list, nor any prerequisite or exclusion beyond the input format.

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 behavioral burden. It usefully discloses the authentication requirement and the fields returned, but it does not mention pagination, ordering, or what happens with no saved lists.

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 with no waste. The core purpose is front-loaded, and the login prerequisite follows immediately.

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 zero-parameter list operation with no output schema, the description gives the essential context: account scope, authentication requirement, and returned fields. It could be stronger by routing the agent away from read_price_list when detailed inspection is needed.

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

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

The tool has zero parameters, so there is no parameter semantics to compensate for; baseline 4 applies. The description does not need to explain any inputs.

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 and resource: list saved price lists on the user's calculator account. It also names the returned fields (name, id, url, total), but it does not explicitly distinguish this tool from siblings such as read_price_list.

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 only usage guidance is the prerequisite 'Needs a login.' There is no explicit when-to-use guidance relative to read_price_list, auth_status, or auth_login, so the agent must infer that this is the lightweight listing endpoint.

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 exist, so the description carries the full disclosure burden; it covers filter behavior and the mapping result, which is the core behavior. It says nothing about authentication requirements, whether the region set is static or dynamic, or the concrete return shape (map vs. list of pairs). Adequate but with clear gaps for an unannotated 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?

Three very short sentences, front-loaded with the return mapping before the filter detail and the negative hint. Nothing is padded, though the closing clause 'there is nothing to resolve here' is slightly oblique in 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?

The tool has one optional param, no output schema, and no annotations, so the description must supply output shape and argument format. It gives the conceptual output (ids to display names) and filter behavior, but leaves the valid `service` value space and the exact return structure implicit.

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 0% — the single `service` param has only a type and default, no description. The description compensates by explaining the filter semantics for `service`, but never says what form the value takes (a service id from list_services, a display name, etc.), which is the main ambiguity an agent faces.

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 resource and output semantics ('Region ids -> display names'), which is precise about what the tool returns. It does not name or differentiate itself from the nearest sibling (compare_regions), so it stops short of a 5.

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

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

It gives an explicit conditional: with `service`, only regions where it is sold are returned. It also supplies a rare and valuable negative hint — that other tools accept friendly names directly, so there is nothing to resolve here — telling the agent when not to call it. No sibling tool is named as the alternative for region comparison, so not a 5.

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 makes clear this is a read-only enumeration over a restricted set of services. It says nothing about authentication requirements, pagination, or result size limits, which matters for a catalog-listing call.

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?

Three short sentences, front-loaded with the scope, then the follow-on usage, then the filter semantics. Nothing is redundant or padded.

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?

An output schema exists, so return values need not be spelled out, and the description still names the returned fields. For a one-parameter read-only lookup it is nearly complete, missing only auth or result-size context.

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

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

Schema coverage is 0%, so the description must compensate, and it does: it explains that `query` filters by substring on id/name/category, which is more than the bare schema reveals. That is the only parameter and it is fully characterized.

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 gives a specific verb and resource ('List Huawei Cloud services') plus a scoping qualifier ('that have a price calculator') and enumerates the returned fields, so the agent knows exactly what it gets. It doesn't explicitly distinguish itself from the close sibling supported_services, which an agent might confuse it with.

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?

It clearly states the downstream use: 'Use the returned `service` id ... in the other tools', with concrete example ids, which tells an agent when this tool is the starting point. It stops short of naming exclusions or alternatives such as supported_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?

With no annotations, the description carries the burden and discloses important behavior: it builds cards, saves a list, verifies on the website, returns a link, requires login, and notably warns that a failed check deletes the list. It stops short of covering permissions beyond login, idempotency, 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?

Three tight sentences. The core action and workflow come first, followed by the prerequisite and destructive-failure warning. There is no wasted text.

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 output schema likely covers the returned link, and the description adequately explains the publish workflow, login need, and destructive failure mode. However, for a four-parameter mutation tool with no annotations and 0% schema description coverage, the missing parameter semantics leave a meaningful completeness 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?

Schema description coverage is 0% and the description does not explain draft_id, name, currency, or settlement. 'Draft' and 'totals' provide only faint contextual hints, leaving all four parameter meanings undocumented in natural language.

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 and resource: 'Publish a fully decided draft', and summarizes the workflow (builds cards, saves list, verifies, returns link). It does not explicitly contrast with siblings like draft_quote or revise_quote, but the phrase 'fully decided draft' implies the post-drafting stage.

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?

It gives clear prerequisites ('Needs a login (auth_login)') and a user-interaction rule ('Confirm the totals with the user first'). It does not explicitly say when to use this versus draft_quote or revise_quote, so there is room for stronger sibling routing.

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 behavioral burden. It helpfully discloses that pricing uses the official rating engine, is denominated in USD, treats 730 hours as one month for ondemand, and applies the official yearly discount, but it does not describe return format, authentication needs, or failure 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 compact and front-loaded: the main purpose comes first, followed by item structure and billing-mode semantics. The bullet-style formatting makes the parameter notes easy to scan without wasted prose.

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

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

For a tool with no annotations, no output schema, and 0% schema description coverage, the description covers the core pricing behavior and many item semantics. It still leaves gaps around region, expected return values, and how this fits into the quoting workflow with draft_quote and publish_quote.

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 0%, so the description must compensate for five undocumented parameters. It does well for items, size, usage_value, hours, periods, and billing modes, but it never explains the required region parameter or the full expected shape of each item.

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 and resource: pricing a bill of materials via Huawei Cloud's official rating engine in USD. It is clear what the tool does, though it does not explicitly distinguish itself from quoting-related siblings such as compare_modes or draft_quote.

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?

It gives useful prerequisite guidance that spec comes from search_skus and explains when to use ondemand versus monthly/yearly billing. However, it does not say when to use this tool instead of siblings like compare_modes, compare_regions, or draft_quote.

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 exist, so the description carries the full burden; it does disclose that access is anonymous and that URLs from other users are accepted, which is genuinely useful. It omits error behavior (invalid id, revoked link, non-shared list), any size/pagination limits on large lists, and whether an id must come from your own account. The return-shape sentence compensates partially for the absent output schema.

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 short sentences, zero filler, with the access scope front-loaded and the return shape second. Each sentence 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?

With no annotations, no output schema, and a single undocumented parameter, the description covers purpose and rough return shape but leaves the agent without error handling, list-size expectations, or ID format. Adequate to call the tool successfully in the happy path, thin for anything else.

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 0%, so the description must add meaning to url_or_id, and it does minimally: it clarifies that either a URL or an ID is acceptable and that shared links from others work. It gives no format guidance (what an ID looks like, whether full URLs with query params are tolerated).

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 and resource ('Read any shared price list') plus a precise access scope ('by url or id', 'anonymous; works for links others send'). The 'shared / links others send' qualifier implicitly separates it from list_my_price_lists, though no sibling is named explicitly.

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?

'Works for links others send' and 'anonymous' imply when this tool is the right choice versus list_my_price_lists, but the agent must infer that routing. No explicit when-not, no stated failure conditions for private or expired links.

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, yet it only discloses the login requirement. For a mutation it omits whether the rename is reversible, whether the old name is preserved, and what happens on name collisions — behavioral gaps an untrusted write tool needs 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?

Two short sentences with the purpose front-loaded and no filler; the login note is compact and relevant. Brevity comes at the cost of detail, but no sentence is wasted.

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

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

For a mutation tool with no annotations, no output schema, and zero parameter documentation, the definition is too thin — an agent cannot tell how to form url_or_id or what success/failure looks like. Only the auth prerequisite is covered.

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 0%, so both parameters are undocumented structurally; the description only implies a target list and a replacement name. It never explains whether url_or_id accepts a URL, an ID, or both, nor any naming constraints on new_name.

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?

"Rename a saved price list" is a specific verb plus resource, and the verb naturally distinguishes it from sibling mutations like delete_price_list and duplicate_price_list. It stops short of naming any sibling explicitly, so an agent must infer the boundary from the verb alone.

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?

"Needs a login" is a prerequisite, not usage guidance: it says nothing about when to prefer rename_price_list over duplicate_price_list (e.g., renaming vs. copying with a new name). No when-not conditions or alternatives are offered.

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 carry the full behavioral burden. It usefully discloses that the result reports pending items, but for a mutating 'record choices' operation it says nothing about whether prior decisions are replaced or appended, whether changes are reversible, permissions, or failure 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?

Extremely concise and front-loaded: two short sentences with no filler. The brevity serves efficiency, though it is arguably terse enough to slide into under-specification rather than true economy.

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 output schema exists, so return format needn't be detailed, but the description still omits the draft_id meaning, the relationship to the surrounding quote lifecycle tools, and mutation semantics such as append vs. replace. For a required-param mutating tool with no annotations, this is a significant completeness 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?

Schema coverage is 0%, so the description must compensate. It meaningfully documents the complex 'decisions' parameter as objects containing requirement_id, spec, and justification—going well beyond the schema's bare additionalProperties:string—but leaves draft_id entirely unexplained.

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?

State a verb+resource: 'Record the user's choices' tied to a decisions array. However, it never mentions the quote or draft being revised, and it doesn't distinguish itself from siblings like draft_quote, quote, or publish_quote beyond an implicit role in a decision loop.

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 when-to-use or when-not-to-use guidance, and no alternatives are named. The note 'Returns what is still pending' hints at an iterative decision loop but does not state when an agent should call this versus draft_quote or publish_quote.

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 behavioral burden. It usefully discloses sorting ('cheapest first'), return contents, billing-mode units, and query matching semantics, but it omits limit/pagination behavior, permissions, and whether limits are enforced on the result set.

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 short and front-loaded: purpose and sort order first, then parameter and return-value clarifications. Every sentence adds useful information without 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 description covers the basic search contract and return shape, which is helpful because there is no output schema. However, for a 7-parameter tool with no annotations and 0% schema description coverage, it does not fully document the filtering and limiting parameters.

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 0%, so the description must compensate. It explains `region` friendly names, `query` all-terms matching, and implies `service`, but it leaves `limit`, `min_vcpus`, `min_memory_gb`, and the `billing` filter unexplained.

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 and resource: search the official price list of a service in a region, sorted cheapest first. It is clear what the tool does, but it does not distinguish itself from nearby siblings such as read_price_list, compare_modes, or compare_regions.

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 context for what is being searched but does not state when to use this tool instead of alternatives. There are no named alternatives, exclusions, or prerequisites to guide tool 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?

No annotations exist, so the description carries the burden. The wording 'which services autocalc can build a saved list for' implies a side-effect-free lookup, but read-only status is never stated explicitly, nor is any auth or cost context. The output schema covers return values, so the description does not need to.

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

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

A single sentence with no filler, front-loading the resource identity ('The capability matrix') before the content detail. It is efficient, though leaning terse for a tool whose siblings occupy overlapping semantic space.

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 zero-argument read tool with an output schema, the description supplies what the schema cannot: the semantic content of the matrix (services and their modes). The only real gap is the absence of any routing guidance against the many adjacent sibling tools.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate. Baseline of 4 applies; no parameter-level claims are made or needed.

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 names a specific resource ('capability matrix') and states what it contains: which services autocalc can build a saved list for, plus their modes. This separates it reasonably well from list_services (plain enumeration) and compare_modes (mode comparison), though neither sibling is named and the 'capability matrix' framing is jargon the agent must decode.

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?

There is no statement of when to call this versus list_services, describe_service, or compare_modes, all of which sit in adjacent territory. The agent must infer from the description alone that this is a pre-flight check before building a saved list. No exclusions or prerequisites are given.

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