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

No annotations are provided, so the description carries the full burden. It discloses the unit conversion behavior (MWh→kWh, tonne→kg, gallon→litre, mile→km) and the output structure (emissions with working, GHG Protocol scope, source). This is transparent for a calculation tool with no side effects. It does not mention error handling or rate limits, but that is not critical here.

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

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

The description is two sentences, front-loaded with the core purpose and formula. It packs essential details (unit conversions, output, factor lookup) without redundancy. Every sentence earns its place, and it is highly scannable.

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

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

Given the tool's simplicity (2 params, no output schema), the description fully covers what an agent needs: what it does, how to provide inputs, unit conversion logic, and what it returns. It also includes a prerequisite step (find factor key) and directs to appropriate tools. Without an output schema, it adequately explains return values.

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% (both parameters described), so baseline is 3. The description adds extra meaning by explaining the unit handling (converting to factor basis) and the output fields, which goes beyond just listing parameter names. It clarifies that activity is an object with value and unit, and factor_key is canonical, complementing the schema.

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

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

The description clearly states its purpose: converting activity data into greenhouse-gas emissions using the formula emissions = activity × factor. It also details the unit conversion and what is returned (working, scope, source), distinguishing it from generic tools. The mention of finding factor keys via search_factors/lookup_factor differentiates it from specific calculation tools like calculate_electricity or calculate_freight.

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 provides clear usage guidance: give an amount + unit and a factor key, and explicitly instructs to use search_factors or lookup_factor to find the key. It implies this is the generic activity calculator, but does not explicitly exclude specialized alternatives like calculate_electricity or calculate_freight. Still, the workflow is well-defined.

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

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

With no annotations, the description must convey behavior. It mentions the formula, factor variants (with_rf/without_rf), and dependency on search_factors, but does not disclose output format, potential errors, or any side effects. It's a read-only calculation implied, but not stated, and edge cases like missing factors are not addressed.

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 sentences, each earning its place. The first sentence states purpose and formula; the second gives critical factor-context and lookup guidance. 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 calculation tool with full schema coverage, the description covers the core formula, factor sourcing, and scope. It lacks explicit output details, but given no output schema and that the result is an emissions estimate, the description is sufficiently complete for a competent agent.

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

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

Schema coverage is 100%, providing baseline 3. The description adds value by explaining factor_key variants (with_rf/without_rf) and directing users to search_factors for valid keys, which goes beyond schema basics. It also clarifies the distance unit combinations via the formula.

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

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

The description clearly states the tool's purpose: calculating business travel emissions (Scope 3 Cat 6) using the distance method, including the formula. It distinguishes itself from sibling tools by naming the specific category and method, making it unambiguous which tool to choose.

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

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

The description implies usage context by naming the distance method and pointing to search_factors for factor lookups, but it doesn't explicitly state when to avoid this tool or mention alternatives for other categories. It provides clear context but lacks explicit exclusions.

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

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

No annotations are provided, so the description carries the full burden. It transparently discloses that location-based is always returned and market-based is conditional, and even gives an example (green tariff/REC=0). However, it doesn't explicitly state precedence behavior (supplier_factor wins over market_factor_key), which is only in the schema description.

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

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

The description is three sentences, front-loaded with the core purpose, then covering behavior, alternatives, and a pointer to a related tool. Every sentence adds value with no redundancy or fluff.

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 4 parameters, no output schema, and no annotations; the description covers the purpose, behavior, and how to source factor keys. It lacks explicit details about output format, but that isn't required given the absence of an output schema. It adequately addresses the complexity of the tool.

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

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

Schema coverage is 100%, so baseline is 3. The description adds meaningful context by explaining that location_factor_key is grid-average, market_factor_key is residual-mix, and supplier_factor can be a contractual value like a green tariff/REC=0. This goes beyond simply repeating parameter names.

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

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

The description clearly states the tool calculates GHG Protocol Scope 2 for purchased electricity and explicitly identifies both methods (location-based and market-based). It distinguishes itself from sibling tools like calculate_activity and calculate_embodied by specifying the exact resource and metric.

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 explicit guidance on when market-based results are available (when supplier_factor or market_factor_key is supplied) and clarifies that location-based is always returned. It also directs users to search_factors for finding grid keys, providing a clear path to obtaining necessary inputs.

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

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

With no annotations, the description carries the burden. It discloses key behavioral traits: assembles lifecycle modules, reports module D separately, and flags missing stages as 'not-assessed' (never zero). It does not mention side effects or authentication, but for a calculation tool these are likely negligible and the core behavior is well explained.

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

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

The description is two sentences, front-loads the purpose, and packs necessary details (modules, boundary, missing-stage behavior, key lookup) without redundancy. 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 single-parameter tool with a well-documented schema and no output schema, the description covers the behavior, output logic, and usage thoroughly. It explains what the tool does with inputs and its output conventions (e.g., module D separately, missing stages flagged), making it complete for an agent.

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

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

The schema already describes the materials array structure fully (100% coverage), but the description adds the boundary options and directs the agent to search_factors for valid material keys—useful context beyond the schema. This meaningfully aids correct invocation.

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

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

The description clearly states the tool calculates whole-life embodied carbon for materials per EN 15978, with specific details on module assembly and boundary handling. It implicitly distinguishes itself from siblings like calculate_pcaf by focusing on materials and using the EN standard.

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

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

Provides concrete usage guidance: tells the agent to find material keys via search_factors, and lists optional boundary choices (A1-A3, A1-A4, etc.). It does not explicitly state when not to use this tool, but the material-specific framing and reference to search_factors give adequate context.

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

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

No annotations are provided, so the description carries the behavioral disclosure burden. It transparently reveals the calculation model (emissions = tonnes × km × factor), the GLEC methodology, and the dependency on factor_key lookup. It does not describe output units or error behavior, but the formula is the core behavioral trait for this calculator.

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 sentences, front-loaded with purpose, and no filler. The formula and factor-lookup guidance are packed efficiently into a compact description.

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

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

The tool has no output schema and no annotations, so the description must cover both inputs and behavior. It explains the input semantics via the formula and points to the factor source, but it stops short of explicitly stating the output emission unit or result format. Overall, it is complete enough for a straightforward calculator tool.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds value by showing how mass, distance, and factor combine in the formula and by giving a concrete factor_key example (freight.road_hgv.tonne_km), which clarifies the expected key format beyond the schema.

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

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

The description specifies a clear verb and resource: calculate freight/logistics emissions using the GLEC tonne-km method. It also narrows scope to Scope 3 Categories 4 & 9, which distinguishes it from sibling calculators like calculate_activity and calculate_spend.

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 clear context for when to use this tool: freight & logistics emissions via tonne-km. It proactively directs users to search_factors for factor lookup with a concrete section and example, but it does not explicitly state when not to use this tool versus other calculate_* siblings.

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

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

No annotations are provided, so the description must disclose behavior. It mentions outputs (attribution factors, data quality score, audit trail) but does not state if there are side effects, authentication needs, or limitations. It doesn't clarify whether it mutates data or just reads. Given no annotations, this is insufficient.

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

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

The description is a single sentence that efficiently conveys the tool's purpose and outputs without unnecessary verbosity.

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 provides context about PCAF Part A and outputs, but lacks details on prerequisites, when to use vs other PCAF tools, or any limitations. Given no annotations, it leaves some context to guesswork.

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 'holdings' parameter has a description outlining the structure (outstanding_amount, denominator, emissions or spend data), but the 'asset_class' parameter is undocumented. Schema coverage is only 50%, so some parameters lack clear semantics.

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 specifies the tool's verb ('Compute'), resource ('PCAF Part A financed emissions'), and output details (attribution factor, portfolio total, data-quality score, audit trail). It distinguishes from sibling tools like calculate_embodied or calculate_spend by focusing on the PCAF Part A standard.

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 use for PCAF Part A financed emissions calculation, but it doesn't explicitly state when to use this over alternative calculation tools (e.g., calculate_spend) or provide exclusion criteria. It gives some context but lacks explicit guidance.

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

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

No annotations are provided, so the description carries the burden. It mentions the input constraint (currency/year) but does not explicitly state whether the tool has side effects or read-only status. As a calculation, it's likely safe, but this is not confirmed.

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

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

The description is concise, two sentences that pack the formula, the constraint, and a reference to search_factors. No unnecessary details, well-structured for quick comprehension.

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 there is no output schema, the description adequately explains the calculation context, including the EEIO methodology and how to obtain factor keys. The output (emissions) is implied by the formula, so it's 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?

The schema provides basic descriptions, but the tool description adds significant meaning by explaining the spend format requirement and giving an example factor key. This enriches the understanding of both parameters.

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

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

The description clearly states the tool's purpose: calculating emissions using spend and economic-intensity factor, with the formula explicitly provided. This distinguishes it from sibling tools like calculate_activity or calculate_embodied.

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 explains the spend-based approach, emphasizes the currency/year constraint, and directs users to search_factors for finding factor keys. While it doesn't explicitly contrast with alternatives, the specific method and constraints make usage clear enough.

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

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

With no annotations provided, the description bears the full burden. It transparently discloses that results are 'authored judgements' not derived data, mentions the stale flag, and details the output fields (publisher, route, confidence, review date). This goes beyond surface-level description.

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 verbose, with several sentences repeating the same idea (e.g., 'reasoned counterpart to coverage' and 'authored judgements'). It could be tightened while preserving key details, unlike concise equivalents like the high-scoring example.

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?

Despite verbosity, it is thoroughly complete: explains the purpose, every classification, the output structure, the nature of the data (judgements vs. derived), and the appropriate timing for use. Nothing essential is missing.

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

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

The schema already covers all parameters with descriptions. The tool description adds depth to the 'classification' parameter by explaining each enum value in detail, but does not significantly enhance understanding of the other parameters. Baseline 3 is appropriate.

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

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

The description clearly states the tool's purpose: to explain why a factor is not in the corpus, with detailed classifications. It distinguishes itself by being the 'reasoned counterpart to coverage' and provides specific use cases, making it distinguishable from sibling tools like lookup_factor.

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 explicit guidance on when to use the tool ('Call this before concluding that a gap is permanent...'), but it does not explicitly name alternative tools or state when not to use it. The guidance is implied rather than directly contrasting with siblings.

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

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

With no annotations provided, the description carries the full burden and does so thoroughly. It discloses what is returned (value plus audit envelope), details provenance and verification fields, and explains the missing-key fallback behavior with candidate keys.

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 sentences, each earning its place: operation, return envelope details, and usage guidance. The most important information is front-loaded in the first sentence, and the detail is dense but not bloated.

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?

Despite no output schema and no annotations, the description is complete for a single-parameter lookup tool. It explains the return shape, provenance and verification details, error behavior, and when to use the sibling tool, leaving no critical ambiguity.

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% for the single 'key' parameter, including an example. The description reinforces that the lookup is by 'canonical key' but does not add substantial parameter semantics beyond the schema, so the baseline of 3 is appropriate.

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

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

The description uses a specific verb and resource: 'Look up a single greenhouse-gas emission factor by its canonical key.' It also distinguishes itself from siblings by explicitly directing users to search_factors when the key is unknown, and describes the narrow lookup scope versus broader search/calculation 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?

Explicit guidance is provided: 'Use search_factors first if you do not know the key.' This clearly states when this tool is appropriate and names the alternative, which is exactly the kind of usage guidance expected.

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 present, so the description must carry behavioral disclosure. It does so well by describing the returned audit envelope (provenance, verification) and the non-failing not_found behavior. It stops short of discussing auth or rate limits, but those are not critical for this 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 focused sentences with no filler: first states what it does, second gives usage guidance, third clarifies error handling. The key behavior is front-loaded.

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

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

The description covers purpose, batch behavior, return envelope, and error handling for missing keys. Combined with the schema's key example and max count, an agent has enough to call it correctly. It could additionally point to search_factors for finding valid keys, but that is a minor gap.

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

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

Schema description coverage is 100%, and the parameter description already explains canonical keys, provides examples, and states the max of 25. The description adds context about batch semantics but does not need to expand parameter meaning further.

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

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

Clearly states it looks up several emission factors by key in one call and returns the same audit envelope as lookup_factor. It is explicitly differentiated from the singular sibling lookup_factor.

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?

Directly instructs to use this tool instead of calling lookup_factor in a loop and describes the batch context, e.g., portfolio or multi-country comparison. This gives clear when-to-use guidance and names the alternative.

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 so thoroughly: it explains that geography is parsed from the description, that omitting country yields a 'geo_match':'proxy' result, that 'review' is intentionally over-inclusive, and that absence responses have structural meanings that should stop the agent from retrying. This is far beyond minimal behavioral disclosure.

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

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

The description is long but each paragraph earns its place: scoping, label semantics, and absence handling are all needed for correct invocation. The use of short capitalized hooks ('PUT THE COUNTRY IN THE DESCRIPTION', 'ACT ON THE LABEL', 'A MISS MAY EXPLAIN ITSELF') front-loads key behaviors and makes the density navigable.

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 three parameters, no annotations, and no output schema, the description provides everything needed to use the tool correctly: what it returns, how the main parameter behaves, how to interpret result labels, what absence responses mean, and how to hand off to related tools. No critical guidance appears missing.

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

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

Schema coverage is 100%, so baseline is 3, but the description adds real meaning beyond the schema for the critical 'description' parameter: it emphasizes the country must be embedded in the text and gives concrete examples ('diesel per litre France'). This extra semantic context justifies a 4 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 names a specific operation ('find the best emission-factor key(s)') and a concrete resource ('for a plain-language description'), and explains the tool's distinctive role against the 16,000-key problem. It also positions the output as ranked matches with key/value/unit/confidence, and routes the chosen key onward to calculate_* tools or lookup_factor, which separates it from siblings.

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

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

The description gives explicit usage direction: 'Prefer this over guessing a key', tells the agent to feed the chosen key to calculate_* or lookup_factor, and points to explain_absence for querying absence directly. It also provides actionable when-to-use/when-not-to-use guidance through the 'accept'/'review' labels and the absence classifications.

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

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

With no annotations provided, the description carries the burden of behavioral disclosure. It honestly describes the returned fields and clarifies that full audit details are intentionally deferred to lookup tools. It does not describe match semantics or empty-result/pagination behavior, so it is not quite 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 dense sentences with no filler. The primary purpose is front-loaded, the return contract is summarized, and the routing guidance is placed at the end.

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

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

The description is complete for this tool category: it covers what is searched, what is returned, what is omitted, and which sibling tools cover the omitted case. Since there is no output schema, explicitly naming the returned fields is valuable and 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 100%, so all four parameters are already documented. The description echoes the search modes by mentioning section, key prefix, and free text, but it does not add any meaning beyond the schema.

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

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

The description states a clear verb and resource: 'Find emission factors by section, key prefix, or free text.' It also lists the exact fields returned, which immediately differentiates it from lookup_factor and lookup_factors.

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 explicitly says when to switch to alternatives: 'for one factor's full audit envelope ... call lookup_factor; for several, call lookup_factors.' This gives the agent a concrete routing decision rather than leaving it to infer.

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