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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds the valuable behavioral context that the call is free, which is not captured by annotations. It also clarifies the scope ('for this account'), adding practical meaning beyond the structured metadata.

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

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

The description is a single, front-loaded sentence with no unnecessary words. The main action and resource appear immediately, and the cost note is a minor parenthetical that adds value without bloating the 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 zero-parameter, read-only, idempotent tool, the description is fully adequate. It states what the tool does, for which account, and that it is free. No output schema exists, but the expected result (the remaining balance) is clearly implied by the description.

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, and the schema describes an empty properties object with 100% coverage. The description does not need to explain parameters because there are none. The baseline of 4 for no-parameter tools is appropriate.

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

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

The description states a specific verb ('Show') and a clear resource ('remaining dVeracity API credit balance for this account'), which makes the tool's purpose unambiguous. It is easily distinguished from its siblings, none of which relate to credit balance. The parenthetical '(free)' adds a useful note that the endpoint is free of charge.

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

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

The description makes the context clear: use this to check the available API credit balance for the current account. There are no direct sibling alternatives for this function, so explicit exclusions are unnecessary. However, it does not explicitly state when to use it versus other account-quota or billing tools, though none appear among the 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?

The description adds useful context beyond the readOnlyHint annotation: the tool is free and, in KERI mode, metered calls are attributed to this identity in the audit trail. It also implies that if KERI mode is not configured, identity information may not be available. No contradiction with 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 sentences, each earning its place: the first provides the operation, resource, and condition; the second explains the cost and attribution behavior. The key information is front-loaded and 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?

For a simple zero-parameter read-only lookup, the description covers what will be returned, when it applies, and the cost implication. Although there is no output schema, the description lists the main output components (agent AID, LEI, scopes), which is sufficient for an agent 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?

The tool accepts zero parameters and schema coverage is 100%, so there is no parameter ambiguity. The description correctly focuses on the identity data returned rather than input details; this matches the baseline for a 0-parameter tool.

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 action ('Show'), a clear resource (this agent's verified vLEI identity), and enumerates the returned fields (agent AID, Legal Entity LEI, authorized scopes). This makes it clearly distinguishable from sibling tools, which concern credits, policies, models, or semantic queries.

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 conditions use on KERI mode being configured and notes that calls are free, which tells an agent when this tool is relevant. It does not name alternatives or exclusions, but none of the sibling tools clearly compete with an identity lookup, so the context is sufficient.

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

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

The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the 'free' detail and the scope of what is listed, but reveals no additional behavioral traits such as output format, pagination, or rate considerations.

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

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

The description is a single, front-loaded sentence with no filler. Every element—verb, object, scope, and pricing qualifier—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 no-argument, read-only list operation with strong annotations and no output schema requirements, the description is complete. An agent knows exactly what will happen when invoking it and has enough information to make the correct call.

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 burden. The description does not need to explain input semantics; the 'standards' scope is clear from the description itself.

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 ('List'), a clear resource ('sustainability data standards'), and the relevant scope ('dVeracity can validate against'). It also adds a useful qualifier ('free'), making the tool's purpose immediately distinguishable from validation or policy tools among its 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 implies usage: call this tool when you need to know which standards dVeracity can validate against. However, it does not explicitly state when to use it versus alternatives like validate_data, nor does it mention 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 establish read-only, idempotent, non-destructive behavior. The description adds valuable behavioral context beyond annotations: specifically, that ambiguous entity names cause the call to fail rather than the tool guessing a domain. This is useful failure-mode information that helps the agent avoid errors.

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 carry exactly the necessary information: the first defines the tool's function and output, the second highlights a critical usage caveat. It is tightly written with no filler, and the most actionable instruction is placed prominently.

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 has only two parameters, full schema coverage, and no output schema, the description supplies what an agent needs to call it correctly: what it returns, the domain ambiguity issue, and the required name parameter. The failure-mode warning closes the main gap. Nothing essential for correct invocation appears to be 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 describes both parameters with examples, so baseline coverage is 100%. The description adds meaningful guidance above the schema: the importance of `domain`, the existence of 48 ambiguous entity names, and the specific consequence of omitting it. This enriches the agent's understanding of parameter usage beyond the raw field descriptions.

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

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

The description clearly states a specific verb and resource: 'Get one canonical entity in full', and enumerates the returned content (fields, primary key, relationships, physical table). It is clear and unambiguous, though it does not explicitly differentiate itself from sibling tools like ofp_search_entities beyond the word 'canonical' and 'one entity in full'.

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 usage rule: pass `domain` whenever you know it, and warns that ambiguous names fail rather than being guessed. This provides clear context for selecting parameters and helps the agent decide how to call the tool. It does not explicitly describe when to use this tool over siblings, but the purpose is narrow enough that the guidance is adequate.

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 communicate readOnlyHint, idempotentHint, and destructiveHint=false. The description adds useful context about deployment scoping and the 'free' aspect, but does not go further into behavior like rate limits, freshness guarantees, or what happens if the model is unavailable. This is adequate given 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 sentences with no waste. The first sentence states what it returns, and the second gives the usage scenario. Key information 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?

Given zero parameters, rich annotations, and no output schema, the description fully covers what the tool returns and why to use it. There are no obvious missing pieces for an agent to call it successfully.

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

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

The tool has zero parameters and schema coverage is 100%, so the baseline is 4. The description adds no parameter details because none are needed; it correctly focuses on output meaning instead.

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 starts with a specific verb ('Show') and a specific resource ('which snapshot of the Open Footprint standard this deployment serves'), and lists concrete outputs: source commit, date, entity/sector counts. This clearly distinguishes it from sibling tools like ofp_models or list_standards by focusing on deployment provenance rather than model listing.

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 usage condition: 'Use it when you need to know how current the model you are designing against is.' This provides clear context for when to call the tool, though it does not mention alternatives or when not to use it.

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

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

Annotations already establish readOnly, idempotent, and non-destructive behavior. The description adds useful context beyond annotations: the exact scope of the return (eight domains, DDL dialect availability) and the fact that the content is 'free.' It does not contradict annotations and enriches the agent's expectations of the tool's output content.

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 precisely defines the function, the second gives a meaningful usage cue. No fluff, no repetition of annotations, and the key scope detail 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 tells the agent what the output covers (domains and DDL dialects) and when to use it, which is sufficient for a zero-parameter list overview. It does not describe the exact output structure, but the absence of an output schema and the simple list-like nature make this a minor gap rather than a critical one.

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 parameter documentation is unnecessary. The description correctly focuses on output scope rather than inputs, and the 100% schema coverage baseline for parameters is trivially satisfied.

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

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

States a specific verb ('List'), a precise resource ('the eight Open Footprint canonical model domains'), and adds a distinctive detail ('which database dialects have published DDL'). The sibling context includes entity- and sector-specific tools, so this description clearly sets the tool apart as a model-level overview rather than an entity 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?

Explicitly instructs 'Start here when building an app on the Open Footprint standard' and positions the tool as a preface to looking up individual entities. This provides a clear when-to-use context and an implicit when-not (for individual entity details), though it does not name an alternative sibling tool explicitly.

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 non-destructive behavior. The description adds significant behavioral detail: the return shape, the e-ledger versus canonical field naming nuance, the unevaluable payload consequence, and the meaning of published:false. No contradiction with annotations.

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

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

The description is dense but well-structured, front-loading the core operation and then layering necessary caveats. Each sentence carries meaningful content and 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?

There is no output schema, so the description compensates by explaining the return format (Rego source, policies[].inputs), the field naming expectation, and the non-error published:false case. This is sufficient for an agent to call and interpret the tool correctly.

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

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

Schema coverage is 100%; the single id parameter is already described with an example ('extractives'). The description adds no new parameter-specific semantics beyond calling it a sector, so the 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?

States a concrete operation ('Get a sector's policy guardrails as Rego source') and clarifies the result's role by mentioning how ofp_validate uses it. This distinguishes it from sibling tools like ofp_sectors or ofp_validate.

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?

Clearly implies when to use it: when sector policy guardrails are needed. It provides important usage warnings about published:false and about not inventing guardrails, and references ofp_validate as the downstream validator. It does not explicitly enumerate alternatives or when-not-to-use conditions.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is established. The description adds behavioral detail: it matches names, descriptions, and field names, and the 'free' concept search indicates natural-language style queries.

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 brief sentences, front-loaded with the main verb/resource, then matching scope, then workflow. Every sentence earns its place with no 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 description, annotations, and 100% schema coverage together cover the tool's use case and safety profile. It does not describe result structure, but no output schema exists and a search tool's output is implied; the missing details are minor.

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

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

Schema coverage is 100%, with each property having a description and example. The description adds only a general note that matching covers field names, which links q to search scope, but does not meaningfully go 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 names the exact action ('Search the 239 canonical Open Footprint entities by concept'), states the match scope ('names, descriptions and field names'), and distinguishes it from sibling ofp_entity by positioning it as the lookup step before full-definition fetch. This is a specific verb + resource with clear differentiation.

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?

Explicitly says when to use: 'Use this to find the right entity before fetching its full definition with ofp_entity.' It names an alternative (ofp_entity) and the sequencing. It does not list explicit exclusion criteria, but the workflow guidance is 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds the 'free' cost signal and the returned content categories, which is useful but not a rich behavioral disclosure 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 sentences with no filler. The main purpose and return contents are front-loaded, followed by the prerequisite for finding the id. 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 read-only tool, this is complete: it states the return contents, notes that it is free, and explains how to find the required id. The annotations cover safety and idempotency, so 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?

Schema description coverage is 100%, and the id parameter already has a description and examples. The description reinforces how to obtain the id via ofp_sectors, but it does not add substantial new parameter semantics beyond the schema.

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

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

The description clearly states the verb 'Get' and the resource 'one sector in full', and enumerates what is included: classification, status, reference artifacts, and nested industries. It also differentiates from the sibling tool ofp_sectors by framing this as the singular full-detail counterpart.

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

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

The description explicitly instructs to use ofp_sectors first to find the sector id, which gives clear routing context and names the relevant sibling. It does not spell out when not to use the tool, but the prerequisite is strong guidance for correct usage.

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, and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavior beyond that: sectors can be 'implemented', 'planned', or 'placeholder', and only 'implemented' indicates published reference content. This helps the agent avoid assuming every listed sector is actionable.

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 with the core action first and the status semantics second. Every sentence contributes necessary meaning and there is 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?

For a simple tool with one optional parameter, complete schema coverage, and strong annotations, the description fully conveys how to interpret results and the caveat around placeholder sectors. No output schema is present, but the description supplies the key return concept: each sector carries a status.

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 only parameter, axis, already has an enum and a descriptive line. The tool description adds no extra parameter-level detail, 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 opens with a specific verb and resource: 'List industry sectors and their reference implementations', which makes the tool's basic purpose clear. It does not explicitly contrast itself with the sibling ofp_sector, so it stops short of full sibling differentiation.

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 instruction 'Check the status before assuming a sector has content' gives concrete guidance on how to interpret results and avoid acting on empty taxonomy entries. It does not mention when to prefer this list tool over ofp_sector or ofp_models, so it lacks explicit alternative 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds valuable behavioral context by disclosing that codes carried by more than ten fields return an explicit caution, which helps the agent interpret results appropriately.

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 carry all necessary information with no wasted words. The core behavior is front-loaded, followed by a concise use-case explanation and a meaningful caveat.

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

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

For a simple single-parameter, read-only lookup tool, the description adequately covers purpose, usage context, and a behavioral caution. It does not detail the output format, but its absence is minor given the low complexity and strong annotation coverage.

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 schema already documents the 'code' parameter with an example. The description frames the code's purpose and orienting use case, but it does not add significant meaning beyond what the schema and example already 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?

The description uses a specific verb ('Show') and states the exact resource ('canonical fields carry one O-DEF semantic code'). It further clarifies the purpose as a reverse lookup for connectors, which sharply differentiates it from sibling tools like ofp_semantics or semantic_query.

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 clearly gives the usage context: 'given a field in a source system, find where in the Open Footprint model it belongs.' However, it does not explicitly name sibling alternatives or state when not to use this tool, so it stops short of full exclusionary 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?

Annotations already mark the tool as read-only, idempotent, and non-destructive, so the bar is lower. The description adds useful behavioral context: every code includes fieldCount, a high count signals a generic fallback, and maxFieldCount filters to more specific alignment targets. This goes beyond the annotations without contradicting them.

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: the first states the action, the second provides the use case, and the third explains the key parameter with a concrete recommendation. Front-loaded and free of 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?

For a small tool with one optional parameter and no output schema, the description covers purpose, use case, return-field meaning, and filtering strategy. It doesn't fully enumerate the response shape, but it gives enough for an agent to call it correctly in the intended scenario.

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 maxFieldCount, so the baseline is 3, but the description adds significant meaning: it explains why a high fieldCount is undesirable, recommends '10 is a good start,' and frames the parameter as a way to get codes specific enough to be real alignment targets. This is actionable guidance beyond the raw 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 specific action ('List the O-DEF semantic codes carried by the canonical model') with a clear resource target. The use case (mapping external systems like SAP or ERP feeds onto Open Footprint) further distinguishes it from sibling tools, especially ofp_semantic_code, which is likely for a single code.

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?

Explicitly says when to use: 'Use this when mapping fields from another system — SAP, an ERP, a supplier feed — onto Open Footprint.' It gives clear context but does not explicitly state when not to use it or name an alternative 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?

Annotations only indicate a read-only, non-destructive operation; the description adds substantial behavior: API credit costs, four mutually exclusive outcomes, the not_applicable and unevaluable cases, schema.coverage meaning, and valid being null when evaluation didn't occur. This is far beyond what the annotations convey and directly shapes how an agent should interpret results.

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 dense but every sentence carries essential information, starting with the main purpose and then the outcome taxonomy and compliance caveat. It avoids repetition of schema fields and does not pad the 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?

With no output schema, the description carries the burden of explaining return behavior, and it does so thoroughly: the outcome enum, policy.missingInputs, schema.coverage, policy.ran, and valid semantics. For a five-parameter tool with nested payloads and no declared output schema, this is a complete and safely actionable description.

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 important behavioral semantics beyond field names: entityType defaults to the entity name and typically yields not_applicable, and canonical entities lack the e-ledger fields the guardrail rules test. This materially helps the agent provide a useful payload and interpret results.

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 action ('Check a data payload against the canonical Open Footprint model') and clarifies scope by adding sector guardrails when a sector is named. It clearly distinguishes the tool from generic validation siblings like validate_data by anchoring it to the canonical Open Footprint model and policy outcomes.

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 the tool applies (canonical Open Footprint validation, optional sector guardrails) and includes a hard usage rule: do not report compliance if policy.ran is false or outcome is unevaluable. It does not explicitly name alternatives or state when-not-to-use it in favor of a sibling, so it falls 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?

Discloses non-obvious behavior beyond the readOnlyHint annotation: each call costs API credits and a payment-required error means a human must top up credits. This is exactly the kind of context that helps an agent act correctly. No contradiction with 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?

Three concise sentences, each carrying distinct information: the action/scope, the cost/error behavior, and query-quality guidance. Front-loaded and free of 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 two-parameter read-only query tool with no output schema, the description covers purpose, cost, error handling, and query shaping. A mention of session continuation is missing, but the schema already documents that, so nothing critical is absent.

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

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

Schema description coverage is 100%, and both parameters already have clear descriptions. The description's guidance to prefer specific questions adds marginal value for the query parameter, but it does not meaningfully extend the schema, so 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 identifies the action ('Ask a natural-language question') and the resource ('verified emissions data' across three specified knowledge graphs). It is specific about scope, but does not explicitly differentiate from sibling tools like ofp_semantics or semantic_templates, so it misses the top score.

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

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

Provides useful guidance on how to phrase queries ('Prefer specific questions... over broad ones') and how to handle the payment-required error, but does not state when to use this tool versus alternatives or give any exclusion criteria. Usage is implied 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 readOnlyHint, idempotentHint, and no destructiveness. The description adds a useful behavioral detail not present in annotations: the tool is free and will not consume credits. It also clarifies the value of the operation (learning about query capabilities) without contradicting 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?

The description is a single well-structured sentence. The primary action and resource are front-loaded, and the added guidance about being free and useful before semantic_query earns its place by helping the agent choose correctly.

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

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

For a simple listing tool with no parameters and a clear purpose, the description is nearly complete. It explains what is returned (query templates), the reason to call it, and the benefit. It does not describe the exact format of the template list, but that is acceptable for a low-complexity tool with no output schema.

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

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

The tool has zero parameters, so the schema imposes no burden. The description does not need to explain parameter semantics, and there is nothing here that is left ambiguous; baseline 4 is appropriate for a no-parameter tool.

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 ('List'), a clear resource ('the query templates the semantic layer supports'), and its purpose. It also distinguishes the tool from semantic_query by noting it is free and meant for learning before spending credits.

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 the tool: before calling semantic_query, to learn what questions the knowledge graph can answer. It names the related paid sibling implicitly, but does not explicitly describe when not to use it other than that implied cost distinction.

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

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

The description adds a billing-relevant behavior not present in annotations: 'Costs API credits per call.' This is valuable operational context on top of the readOnlyHint and destructiveHint fields. There is no contradiction; validating data is consistent with a read-only mutation profile.

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 with no filler: purpose, cost warning, and prerequisite are each clearly separated. The most important operational cautions are front-loaded.

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

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

For a validation tool with no output schema, the description explains the core operation, the prerequisite discovery step, and the credit cost, which are the most important missing pieces. It could go further by describing the validation response shape or error behavior, but the current coverage is strong for the tool's complexity.

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 schema already documents all five parameters. The description adds some extra meaning by emphasizing that standards and versions come from list_standards, but it does not elaborate beyond that 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 clearly states a specific action ('Validate a data payload') against a named resource ('supported sustainability standard') and adds the Validation-as-a-Service framing. It is not a tautology and reads distinctly from list_standards, though it does not explicitly differentiate itself from the sibling ofp_validate.

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 concrete usage context by telling the agent to call list_standards first to learn supported standards and versions. It implies when this tool is appropriate, but it does not state exclusions or directly compare with sibling validation-related tools.

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