EcoCheck

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds useful return-content detail (it yields links to the pricing page, case studies, and contact page), which matters since there is no output schema, but it says nothing about auth, rate limits, or truncation.

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 that identifies the resource and enumerates the returned links with no wasted filler. The parenthetical list is slightly run-on but remains tight.

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, read-only info tool whose annotations carry the safety profile, the description adequately covers what the resource is and what content comes back. The only real gap is the absence of routing guidance against sibling lookup 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 the baseline of 4 applies; there is no parameter semantics for the description to clarify.

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 clear verb-less but specific resource: what EcoCheck is as a company, product, and services, plus the linked pages it returns. It is distinguishable from most siblings, though it overlaps conceptually with list_services and get_pricing without explicitly drawing the line.

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 when-to-use guidance and no alternatives named, despite siblings like search_ecocheck, list_services, and get_pricing that could easily be confused with this. Usage is only loosely implied by the name and content.

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?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), yet the description adds real behavioural context: biogenic CO2 is reported separately, uncertainty is optional, IPCC 2006 tier-1 defaults are applied for fuels, the official grid factor is used unless overridden, and ambiguous string quantities are refused. It stops short of describing the response shape or how multi-line results are aggregated.

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 content is dense and largely front-loaded, but it is delivered as one sprawling sentence with deeply nested parentheses, which makes it harder to scan than it needs to be. Almost every clause carries information, so little is wasted, but the structure could be broken into distinct sentences for legibility.

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 compute tool with no output schema, the description does the necessary work: it names the reporting dimensions of the result (ISO category, scope, gas, biogenic CO2 separately) and the optional uncertainty. It is close to complete, though it does not say how multiple lines are combined or what the returned structure looks like.

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 80%, so the baseline is 3, but the description genuinely extends it: it explains the Vietnam grid factor default (2024 = 0.6187 tCO2/MWh, CV 1232/BNNMT-BĐKH), that Scope 3 is routed through scope3_category on custom lines, and that GWP defaults to AR5. These add decision-relevant meaning beyond the per-field schema text.

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 precise verb and resource ('GHG inventory from activity data'), and pins down the output framing: reported by ISO 14064-1 category 1-6, GHG Protocol scope and gas. It also enumerates the input families (fuels, electricity, refrigerants, custom lines), which clearly separates it from sibling tools like ghg_emission_factors (factor lookup) or check_ghg_inventory_obligation (obligation check).

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 rather than stated: an agent can infer this is the tool to call when it holds activity data, and the description notes you may either use the built-in Viet Nam grid factor or 'give your own'. But it never names an alternative tool or an explicit when-not condition, so routing must be inferred.

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?

Annotations already cover read-only/idempotent/non-destructive safety, so the bar is lower. The description adds substantive behavior: the legal instrument and its correction, the year-dependent mark-up schedule (10%/20%/30%, fertilisers 1%), and the fallback return of candidate codes when no exact row exists.

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 purpose and unit, then the legal citation, mark-up schedule, and fallback in two tight sentences. Dense but every clause earns its place; no filler or restatement of the title.

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 carries the return-value burden and does describe the unit (tCO2e per tonne) and the degraded return mode (candidate codes with descriptions). It could go slightly further on the candidate-code shape, but it is complete enough to call 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 100%, so the baseline is 3, but the description quantifies the mark-up that the 'year' parameter drives (10% 2026 through 30% from 2028, fertilisers 1%), which the schema only labels as 'mark-up'. That meaning is not otherwise available 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?

States a precise verb+resource: returns the EU CBAM default value (tCO2e per tonne) for a CN8 code and country of production, including the legal source and mark-up regime. This clearly distinguishes it from siblings like estimate_cbam_cost or cbam_scope_check.

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 frames usage by naming the input keys (CN8 code, country) and describing the fallback path when the exact code has no row. However, it does not say when to prefer this tool over estimate_cbam_cost or cbam_scope_check, nor does it state prerequisites such as needing an importing year.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safe read-only profile is covered without the description. The description adds the 'partial answer at 4/6 digits' behavior for the input, which is useful, but says nothing about permissions, caching, or response shape beyond listing the fields.

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 tight sentences; the output facets are front-loaded followed by the actionable input rule. No redundant padding and nothing that can be dropped without losing 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?

With only two well-documented parameters and no output schema, the description usefully enumerates the returned information (scope, category, indirect emissions, default value), compensating for the absent output schema. It is nearly complete, though a note on how country defaults when omitted would close the last 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 100%, so the baseline is 3, but the description adds genuine meaning beyond the schema: it ties cn_code to the customs declaration and explains that 4/6 digits yield only a partial answer, and it frames the country parameter as driving the EU default value. That extra operational nuance lifts it above baseline.

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+resource (check EU CBAM scope of a CN code) and enumerates the exact facets returned: in-scope status, aggregated goods category, indirect-emissions counting, and EU default value. It is clearly more than a restatement of the name, though it doesn't explicitly distinguish itself from the sibling cbam_default_value, which overlaps on the default-value facet.

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 guidance is 'Use the 8-digit CN code of the customs declaration (4/6 digits give a partial answer)', which is input-format advice rather than when-to-use guidance. It offers no explicit conditions for choosing this tool over cbam_default_value or estimate_cbam_cost, 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?

Read-only, idempotent, closed-world behavior is already fully declared by annotations, so the description's marginal job is to explain the decision logic. It does add the three thresholds (3,000 tCO2e, 1,000 TOE, 65,000 t waste/yr) and the legal instruments applied, which is genuine context. It stops short of saying what happens when inputs are missing or contradictory (e.g., only sector supplied) or how the verdict is reported.

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 compact sentences with zero waste: the action and jurisdiction come first, the legal basis second, the decisive thresholds last. Nothing is repeated from the schema or annotations.

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?

No output schema exists, and the description does not indicate what the result looks like (obligated/not obligated, which threshold was triggered, confidence when inputs are absent). For a determination tool with five optional inputs and a single required one, that omission leaves the agent guessing about return semantics.

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

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

Schema coverage is 100%, so the schema already documents each parameter, including the TOE/kWh conversion. The description adds value by stating the threshold values each parameter is measured against, letting an agent reason about which inputs are decisive before calling.

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?

Specific verb and resource ('Check whether a Vietnamese facility must do a mandatory GHG inventory'), jurisdiction, and named legal basis (Decree 06/2022 as amended by 119/2025, Decision 42/2026/QĐ-TTg). It is clearly distinguishable from siblings like calculate_ghg_inventory (which computes emissions) and get_ghg_regulations (which retrieves text).

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: you call it to obtain a yes/no obligation determination for a facility. However, the description never explicitly says when to prefer it over get_ghg_regulations or calculate_ghg_inventory, and gives no prerequisites (e.g., which combination of inputs is needed for a reliable determination).

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?

Annotations already declare readOnly, idempotent, non-destructive and closed-world behavior, so the safety profile is covered. The description adds genuinely useful domain context beyond that: the result is explicitly 'indicative', it discloses the regulatory basis (Reg 2025/2620 benchmark, CBAM factor 97.5% in 2026, CSCF) and that it shows the saving when actual data is supplied.

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 dense sentences, front-loaded with the cost scope before the formula detail. No filler, though the parenthetical formula stack is heavy enough to require careful parsing.

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 8 parameters (2 required) and no output schema, the description still covers the formula, the optional-input defaults and the indicative nature of the result, which is what an agent needs to call it correctly. Return-value shape is the only thing not described, and the 'Shows the saving with actual data' line signals the output direction.

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 baseline is 3 even without parameter prose. The description goes further by explaining how the key optional inputs interact with the calculation — default-value mark-up versus the producer's verified actual SEE, and the latest official quarterly price unless a price is provided — giving semantics the bare schema strings do not.

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 (estimate) and resource (CBAM certificate cost) and spells out the exact computation the tool performs: embedded emissions minus free-allocation adjustment, times certificate price. This is clearly distinguishable from siblings such as cbam_default_value, cbam_scope_check and get_pricing.

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 frames usage through its defaults ('default value with mark-up, or the producer's actual SEE', 'latest quarterly price unless given'), which tells the agent when to supply actual_see or certificate_price_eur. However, it never states when to use this tool versus siblings like cbam_default_value or get_pricing, nor any 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?

Annotations already declare readOnly, idempotent, non-destructive and closed-world behavior, so the safety profile is covered. The description adds the useful detail that content is returned as Markdown, but says nothing about truncation, size limits, or what happens on an unknown id.

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 sentence, no filler, and the payload (what you get) is front-loaded ahead of the routing hint. Nothing could be cut without losing 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 single-parameter read tool with full annotation coverage and no output schema, the description is nearly sufficient: it says what is returned and how to obtain the key. Only error/edge behavior for invalid ids is 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?

With one parameter at 100% schema coverage, the schema already documents the single 'id' field. The description's 'numeric id or slug' largely restates the schema, adding only the word 'numeric' as a mild refinement. 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?

States a specific verb (get/read one), resource (EcoCheck article), output format (Markdown), and accepted key types (numeric id or slug). The singular 'one' plus the reference to list_articles/search_ecocheck cleanly separates it from those collection 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?

Naming list_articles and search_ecocheck as the sources of the id implies the correct workflow (search first, then fetch), but the description never states the condition for choosing this tool over those siblings. Usage is inferable 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?

Annotations already declare the full safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower; the description still adds meaningful context by characterizing the payload as 'verified' facts and stating that each item links to an EcoCheck explainer, which tells the agent what kind of artifact it will get back.

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 dense sentence, front-loaded with the subject and year, followed by a parenthetical enumeration of covered rules and a closing note on item structure. Every clause carries factual scope; nothing is redundant, though the enumeration is heavy enough to be skimmable rather than 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?

With no output schema and no parameters, the description must convey what comes back — it does, via 'key verified facts' and 'each item links to an EcoCheck explainer'. Coverage of the regulatory domains is broad. Minor gap: no note on how current the facts are kept beyond the '2026' framing.

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?

Zero parameters, so per the rubric the baseline is 4. The description correctly needs no argument semantics and adds nothing misleading about 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?

States a specific retrieval purpose — verified Vietnam GHG compliance facts for 2026 — and enumerates the covered domains (Decision 42 facility list, ETS surrender rules, Decree 29/2026, CBAM dates). An agent can tell this is a curated knowledge-retrieval tool. It does not, however, name or contrast itself with siblings such as get_article, cbam_scope_check, or check_ghg_inventory_obligation.

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 by the content scope: it's the tool for high-level Vietnam GHG/carbon-market/CBAM regulatory facts. There is no explicit when-to-use statement, no exclusions, and no routing to alternatives like cbam_scope_check (per-case CBAM determination) or get_article (detail retrieval).

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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered and the bar is lower. The description adds only content scope, not behavior — no note about whether prices are cached, static, or versioned.

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 resource leading. Inlining the actual price figures is slightly unusual (arguably return-value data), but it is compact and does not bloat the definition.

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 parameterless, read-only informational tool with no output schema, the description conveys enough about what comes back (plan tiers, prices, cost-range location) to call it correctly. Missing only explicit usage routing, which the sibling list would otherwise require.

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 document; baseline 4 applies. No parameter meaning is lost because there are no 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 identifies the resource: EcoCheck software plans with specific tier names and prices, plus a pointer to inventory-service cost ranges. An agent can tell it apart from transactional siblings like calculate_ghg_inventory or estimate_cbam_cost, though it never frames the action as a retrieval ('returns', 'lists').

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 alternatives such as list_services, about_ecocheck, or estimate_cbam_cost. The phrase 'where to find inventory-service cost ranges' hints at scope but gives no condition for selecting 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?

The annotations already declare this as a read-only, idempotent, closed-world lookup, so safety is covered. The description adds genuinely new behavioral context: data provenance (IPCC 2006, AR5/AR6), official Viet Nam grid values with the specific 2024 figure, and the regulatory citation — all of which tell the agent the data is authoritative and citable rather than a computed result.

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 tight sentences with the resource and its contents front-loaded, followed by the intended action (cite in the report). The parenthetical enumerations are dense but each item is informative; the only mildly expendable content is the very specific document citation string.

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 reasonably characterizes the returned data by listing the factor fields and their standard references, and it tells the agent what to do with the result. It does not describe the response shape or organization by category, but for a static reference lookup the coverage is nearly sufficient.

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% for the single enum parameter, so the description carries the burden. It enumerates the categories (fuels, refrigerants, grid) that map to the enum values, which is partial compensation, but it never explains what `kind` does, what `all` returns, or what happens when it is omitted (0 required 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 names a specific resource (built-in default emission factors) and enumerates its contents: fuels with NCV/CO2/CH4/N2O/density, refrigerant GWPs for AR5/AR6, and Viet Nam grid factors by year. It also establishes the relationship to calculate_ghg_inventory. It stops short of distinguishing itself from the sibling cbam_default_value, which is also a default-value lookup.

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?

"Built-in default factors used by calculate_ghg_inventory" and "Cite them in the report" imply the context of use: retrieve these when populating or documenting an inventory. However, there is no explicit when-to-use versus cbam_default_value or versus user-supplied factors, and no stated conditions 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?

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint=false, so the safety profile is covered. The description adds genuinely useful behavioral context: the content is paraphrased rather than authoritative standard text, and it spans regulatory artefacts (ISO 14064-3 verification evidence, Vietnam Decree 06 / Decision 42/2026). That expectation-setting goes beyond the structured fields.

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 that opens with the core purpose before the topic list, with no filler. The trailing list is dense and slightly run-on, but every element corresponds to a real capability rather than padding.

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 read-only, single-enum-parameter guide with no output schema, the description gives an agent enough to decide and invoke correctly, including the important caveat that content is paraphrased. The main residual gap is that it does not state the return shape (prose guidance vs. structured checklist), which matters for a documentation-retrieval 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 description coverage is 0% and there is one enum parameter, so the description must carry the meaning. The comma-separated topics map almost one-to-one onto the enum values and expand them ('vietnam' → Vietnam Decree 06 / Decision 42/2026, 'categories' → boundaries with Scope 1/2/3 cross-walk), which is real added value over the bare enum strings, though the mapping is not labelled explicitly key-to-value.

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 resource (ISO 14064-1 organization inventory guidance) and qualifies its nature as 'paraphrased, not the standard text', which cleanly separates it from article/standard-text siblings like get_article and list_articles. It enumerates the covered topics, so an agent knows what it will get. It stops short of naming a sibling to route away from, keeping it at 4 rather than 5.

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

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

The topic enumeration implicitly tells the agent when to reach for this tool (e.g., scope 1/2/3 categories, base-year recalculation), but there is no explicit when-to-use/when-not statement and no routing to alternatives such as get_ghg_regulations or check_ghg_inventory_obligation. Usage is inferable rather than 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?

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely new behavior — results are Vietnamese-language and ordered newest first — but says nothing about result count defaults, truncation at the limit cap, or matching semantics for the keyword.

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 tight sentence with the sort-order and language facts front-loaded; every clause carries information and there is no boilerplate.

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 no-required-param read tool with full annotation coverage, this is nearly adequate, but the absence of any limit/size guidance and keyword-match semantics leaves gaps that the schema alone does not resolve.

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% for both parameters. The description only glosses the query parameter as a "keyword" filter and never mentions the limit parameter at all, so an agent must read the raw schema constraints (1–50) to understand result sizing.

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?

Specific verb+resource ("List EcoCheck articles") plus useful qualifiers: content language (Vietnamese) and sort order (newest first). It does not, however, distinguish itself from siblings like get_article (single-item fetch) or search_ecocheck (broader search), which an agent could plausibly 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?

"Optionally filtered by keyword" implies when to supply the query parameter, but there is no explicit statement about when to prefer this over search_ecocheck or get_article, and no guidance on default page size or how to page through results.

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?

Annotations already declare readOnly=true, idempotent=true, destructive=false, and openWorld=false, so the safety profile is covered. The description adds a useful non-obvious enumeration of the returned service names, but does not discuss return shape or any behavioral nuance beyond that list.

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 that opens with the verb and resource and then spends its remaining words enumerating concrete return content. No filler or redundancy.

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

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

For a zero-parameter read-only listing tool with no output schema, the description gives an agent enough to call it and anticipate the result contents. It stops short of stating the exact return format, but that is a minor gap for this simplicity level.

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 schema description coverage is 100%, so there is nothing for the description to clarify on the parameter front. The baseline of 4 for a zero-parameter tool 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 states a clear verb ('List') and resource ('EcoCheck services') and enumerates the specific services returned, so an agent knows exactly what this tool surfaces. It does not, however, explicitly differentiate itself from near-siblings like about_ecocheck or search_ecocheck, which also touch on EcoCheck offerings.

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: this is the discovery tool for available EcoCheck services, which suggests calling it when an agent needs to know what the platform offers. There is no explicit when-to-use or when-not-to-use guidance relative to siblings such as about_ecocheck or list_articles.

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?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context by stating that results are ranked matches with URLs, which goes beyond the 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?

Two tightly written sentences. The content scope is front-loaded and the return behavior is stated immediately after, with 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?

For a simple two-parameter search tool with rich annotations, the description covers purpose, content coverage, and return format. It is only slightly incomplete because it does not mention the limit parameter or how result ranking works.

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 implies that 'query' is a search string over the listed domains but says nothing about the 'limit' parameter, result caps, or query constraints such as maxLength.

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 ('Search') and enumerates the resources covered (services, regulations, Vietnamese articles) along with topic domains. It is clearly a search tool, but it does not explicitly differentiate itself from siblings like list_articles, list_services, or get_article.

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 by the verb 'Search' and the content scope, so an agent can infer this is the right tool for keyword discovery. However, there is no explicit guidance on when to prefer this over list_articles, get_article, or get_ghg_regulations.

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