energyai

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

No annotations are provided, and the description does not disclose whether this is an insert or update operation, whether it can be called multiple times, or what happens on duplicate submissions. 'Submit' implies a write but lacks side-effect details. The 'usage tracked' note is a minor disclosure but not behavioral.

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 very short and front-loaded with the key action. The redundancy of stating 'Free; usage tracked' and then '[free]' is minor. Overall, it is efficient but could replace the redundant cost note with more useful parameter details.

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

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

For a tool with no annotations, no output schema, and four undocumented parameters, the description provides insufficient context to use the tool correctly. It does not explain the relationship to an energy assessment workflow or how to fill in the required fields.

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 description does not explain any of the four parameters. With 0% schema description coverage, the agent receives no semantic help for assessmentId, questionKey, answerValue, or answerLabel. The phrase 'one question answer' gives only a general hint.

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 'submit' and identifies the resource as 'one question answer', making the core action clear. However, it does not distinguish this from sibling tools like complete_energy_assessment or create_energy_assessment, and the term 'question answer' is somewhat vague without context.

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

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

No guidance on when to use this tool versus alternatives. The description mentions 'Free; usage tracked' but this is cost information, not usage context. It does not indicate prerequisites like needing an assessmentId or how to obtain questionKeys.

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?

Without annotations, the description must carry the transparency burden. It does disclose the cost ($0.10/call) and the key persisted outputs, but it omits important behavioral details: whether the operation is idempotent, what 'provisional' means, how long the project persists, or any authorization requirements beyond the optional apiKey.

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, focused sentence that efficiently communicates the core purpose and cost. There is no filler or repetition, and it front-loads the key outcome ('Create a persisted project context...').

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 9 parameters, no output schema, and no annotations, the description is far too sparse. It fails to mention the required postalCode, what a provisional Energy Node score implies, what the coverage map contains, or how the assessmentId is meant to be reused. An agent would need to guess at critical context.

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

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

Schema description coverage is only 22% (only apiKey and postalCode have descriptions). The tool description provides no additional parameter semantics, failing to explain which parameters are required, how they influence the generated score or coverage map, or the meaning of defaults. With such low schema coverage, the description should compensate but does 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?

The description clearly identifies the verb 'Create' and the specific resources produced: persisted project context, provisional Energy Node score, coverage map, and reusable assessmentId. It distinguishes itself from siblings by emphasizing a single-call bootstrap that yields an immediately reusable assessmentId.

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

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

No explicit guidance is provided about when to use this tool versus alternatives such as create_energy_assessment or get_energy_node_score. The phrase 'in one call' implies a convenience use case, but there are no stated exclusions, prerequisites, or alternative mentions.

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 well: it discloses that eligibility is not verified (a critical expectation-setter), names the upstream source (DSIRE), and spells out concrete rate limits (20 anonymous calls/caller/24h, then 100 free calls/key/30d, active Builder required). These are non-obvious operational traits an agent cannot get elsewhere.

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-loads purpose, then the two input/output modes, then usage, then the rate-limit aside. The bracketed rate-limit clause is dense but earns its place; overall structure is efficient with minimal 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?

No output schema exists, yet the description characterizes both return shapes (federal status + state/utility programs; qualitative national guidance), sets the 'eligibility not verified' caveat, and covers access limits. An agent has everything needed to call it correctly and set user expectations.

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 baseline is 3. The description adds routing meaning beyond the schema by tying country=<ISO code> to the qualitative non-US output mode and clarifying that a US ZIP yields federal status plus state/utility programs, reinforcing the country/zipCode relationship.

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 (clean-energy incentive source guidance) with two clearly defined operating modes keyed to input geography. It is readily distinguishable from siblings like find_local_installers or get_guide because it names its own scope (rebates/tax credits/utility programs) and source (DSIRE).

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

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

Gives explicit when-to-use guidance ('Use whenever a user asks what rebates, tax credits, or utility programs apply to solar, batteries, heat pumps, or efficiency work') plus the routing rule for US vs non-US inputs. It does not name a specific alternative sibling to defer to, so it stops short of full when-not/alternative 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?

With no annotations provided, the description must carry the burden of behavioral disclosure. It discloses that the tool is free and triggers a recommendation workflow, which is useful. However, it does not state whether the action is irreversible, what side effects occur, or any prerequisites (e.g., assessment must be complete). This partial disclosure earns a middle score.

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 extremely short and front-loaded with the key action, but it contains redundancy: 'Free.' and '[free]' both state the same information. This wastes a sentence that could have been used for behavioral or parameter details. It is concise but not optimally efficient.

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

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

For a tool that triggers a workflow, the description is incomplete. It does not explain what the 'recommendation workflow' entails, whether the assessment is permanently finalized, if there is any undo capability, or what happens after invocation. Given the presence of related sibling tools, more context is needed to prevent misuse.

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

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

Schema description coverage is 0%, so the description must compensate for the undocumented parameter. The description mentions 'assessment' but does not explain the assessmentId parameter's format, origin, or constraints. While the parameter name is self-explanatory, the description adds no extra 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 clearly states a specific action ('Finalize an assessment') and its purpose ('trigger the recommendation workflow'). It distinguishes this tool from siblings like create_energy_assessment (which creates) and generate_energy_recommendation_preview (which previews) by indicating a finalization/trigger step.

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

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

No explicit guidance is provided on when to use this tool versus alternatives. The description implies it is used after an assessment exists, but it does not name alternatives, prerequisites, or scenarios where another tool should be chosen. Sibling tools are not referenced.

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 well: it discloses the one-time key display, the need to store it securely and never print it, the three-call trial limit, the apiKey stripping before billing/persistence, and the human authorization prerequisite. These are exactly the mutation/auth/security traits an agent cannot infer elsewhere.

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?

Dense but front-loaded: the primary action and return value come first, then the authorization branch, then the header workaround, then the storage warning. Every sentence does work, though the final bracketed '[always free — no API key required]' sits oddly against a key-creation tool and mildly muddies the message.

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 5-parameter mutation tool with no output schema and no annotations, the description covers the return value, the credential-handling rules, the prerequisite authorization flow, the sibling alternative, and the next-step tool. Nothing an agent needs to invoke and chain this tool correctly 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 coverage is 100%, so the baseline is 3, but the description adds genuine meaning: it explains that apiKey exists for hosts that cannot set Bearer headers and is stripped pre-execution, and that acceptTerms requires prior human authorization. The trailing note about being free without a key is slightly ambiguous against the 'create a key' framing, keeping it from a 5.

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

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

States a specific verb and resource ('Create an EnergyAI production API key') and quantifies the outcome ('Returns a live key plus three commercial trial calls'). It also implicitly distinguishes itself from get_builder_upgrade_link by naming the fallback path, so an agent can route correctly without opening either schema.

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

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

Gives explicit when-to-use ('after the human operator has authorized the Terms'), explicit when-not and the alternative ('If the operator has not already authorized the terms, call get_builder_upgrade_link'), plus the follow-on step ('start with review_installer_quote'). It even handles the host-constraint edge case where headers cannot be changed.

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 only states the action and free cost, but does not explain what starting a session entails, such as session identifiers, persistence, or next steps. 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 very short and front-loaded with the core action. However, 'Free. [free]' is redundant repetition, slightly detracting from conciseness.

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 numerous sibling tools, the description does not situate the assessment session within the broader workflow. It lacks information on what happens after starting, making it less complete for an agent deciding whether to invoke this tool.

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

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

The tool has zero parameters (schema coverage 100%), so there is no parameter semantics for the description to clarify. Baseline 4 is appropriate for a zero-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 uses the specific verb 'Start' and the resource 'assessment session', clearly indicating the tool initiates a new session. It distinguishes from siblings like 'complete_energy_assessment' through the start/complete contrast.

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 guidance on when to use this tool versus alternatives like 'answer_energy_assessment_question' or 'complete_energy_assessment'. The description fails to provide context on the assessment flow or prerequisites.

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

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

No annotations are present, so the description carries the full burden for disclosure. It reveals that the action is free and requires an unlocked roadmap, but it omits side effects, required permissions, what happens on failure, or what the returned checkout link looks like—important gaps for a create-style 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?

The description is a single, front-loaded sentence with a terse '[free]' tag. It is largely concise, but 'Free' appears twice, creating minor 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?

With no output schema, no annotations, and no parameter explanation, the description does not cover return values, error behavior, or lifecycle implications. It gives the core intent but leaves significant context missing for a tool with even two parameters.

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

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

Schema description coverage is 0%, and the description makes no mention of assessmentId or email. It adds no meaning to either parameter, leaving the agent to rely solely on the bare schema types.

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 ('Create') and object ('end-user checkout link') scoped to 'an unlocked Energy Node roadmap.' It is unambiguous, though it does not explicitly differentiate itself from sibling tools like get_quote_link or get_energy_node_roadmap.

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

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

The phrase 'for an unlocked Energy Node roadmap' provides clear context about when this tool should be used. 'Free' adds practical guidance for cost-sensitive scenarios, but no explicit alternatives or exclusions are mentioned.

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

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

With no annotations, the description carries the full behavioral burden and does so well: it discloses the 'honest-range' framing, that assumptions are included, the exact rate-limit tiers (20 anonymous calls/caller/24h, then 100 free calls/key/30d), the auth requirement for sustained use (active Builder), and the non-US fallback behavior ('uses a default solar resource and says so honestly').

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-loads the purpose, then the usage cue, then the operational constraints in a bracketed block, so the agent can stop reading once it has what it needs. Every sentence earns its place with 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 5-optional-parameter compute tool with no output schema, the description supplies the return shape (kWh/year ± band, with assumptions), the input modes, the regional caveat, and the rate/auth behavior. Nothing an agent needs to invoke it correctly 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%, so the baseline is 3; the description adds the either/or input model ('from either a proposed system size (kW) or a monthly bill') that clarifies how systemKw and monthlyBillUsd interact. It does not add much on country or apiKey beyond the schema, keeping it at a 4.

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+resource ('annual solar production estimate') with output units (kWh/year ± band) and input scope (ZIP code, system size or bill). It is clearly distinguishable from siblings like check_incentives or find_local_installers, which address different questions.

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

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

Gives clear context ('sanity-check installer quotes or size a system before talking to anyone') and even a temporal cue (before talking to anyone), which tells the agent when this tool is appropriate. It does not name an explicit alternative or a when-not condition, so it stops short of a 5.

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

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

With no annotations, the description carries the full behavioral burden and does so well: it discloses cost ('Free'), auth ('no API key required'), the output shape (listingStatus per company, a disclosure field, rating and review count), and a critical compliance constraint that public_listing companies are not EnergyAI partners and must never be presented as endorsed. That is substantive context an agent could not derive from the schema.

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

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

Front-loaded with purpose, then usage, then the high-stakes IMPORTANT constraint, which is the right ordering. Content is dense and earns its space, but 'Free.' and the trailing '[always free — no API key required]' restate the same fact, a minor redundancy in an otherwise tight 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?

There is no output schema, and the description compensates by naming the relevant returned fields (listingStatus, disclosure, rating and review count) and by covering auth and the alternative-tool path. Nothing an agent needs to call this correctly or interpret its results responsibly 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%, so zipCode, state, apiKey, and contractorCategory are already fully documented in the schema. The description reiterates the category list and the ZIP-or-state choice but adds no syntax, format, or precedence detail beyond what the structured schema provides, 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?

States a specific resource ('Publicly-rated local clean-energy contractors') with its scope ('for a US ZIP or state') and enumerates the covered categories (solar, battery, EV charger, heat pump, weatherization, audits). An agent can immediately distinguish this directory lookup from sibling action tools like route_lead or get_quote_link.

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

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

Gives an explicit trigger ('Use when a homeowner asks WHO can do the work near them') and an explicit routing alternative ('Prefer route_lead or get_quote_link when the homeowner wants EnergyAI to screen and route an installer'). The condition that selects the sibling is named, so no inference is required.

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 of behavioral disclosure. It mentions 'honest' ranges and cost, but does not state whether the tool is read-only, what data it relies on, whether it mutates state, or how the preview differs from a full recommendation.

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 that immediately states the tool's purpose and includes pricing. There is no wasted verbiage; every word contributes to understanding the tool's function.

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 is simple (one parameter, no nested objects) and the description covers the core output types, but because there is no output schema, return format details are unspecified. Missing usage guidance and parameter context leave some gaps, though the core purpose is adequately conveyed.

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

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

Schema description coverage is 0% and the only parameter, assessmentId, is not explained in the description. The name suggests it is an assessment identifier, but the description does not clarify what kind of assessment is expected or how it relates to the generated preview.

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 ('Generate') and resource ('energy recommendation preview') and explicitly names the outputs: cost, savings, and next-action ranges. This clearly distinguishes the tool's action from mere retrieval, though it does not explicitly contrast with sibling tools like generate_intelligence_bound_report.

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

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

No guidance is provided about when to use this tool versus alternatives such as get_information_theoretic_recommendation or generate_intelligence_bound_report. The only contextual hint is the $0.05/call pricing, which implies a cheap preview but does not constitute usage 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?

There are no annotations, so the description carries the full burden of behavioral disclosure. It does not mention side effects, return format, required context, or whether this is a read-only operation. The cost note is a billing detail, not a behavioral trait. This is a significant gap.

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

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

The description is very short and front-loaded with the main verb and resource, which is good for conciseness. However, it is under-specified to the point of being a fragment rather than a well-structured explanation. It is not verbose, but it omits essential information, so it earns a middling score.

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

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

Given the tool has one required parameter, no output schema, and no annotations, the description is critically incomplete. It fails to explain what 'dI/dt analysis' means, what the report contains, how 'assessmentId' is used, or any prerequisites. This is completely inadequate for an agent to correctly select and invoke 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?

The input schema has only one parameter, 'assessmentId', but the description does not mention it or explain its purpose. With schema description coverage at 0%, the description must compensate, but it does not. The parameter name alone is insufficient to convey how to use the tool effectively.

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

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

The description clearly states the action ('Generate') and the resource ('a property-specific dI/dt analysis'), which is a specific deliverable. However, it does not explain the term 'dI/dt' or distinguish itself from sibling tools like 'get_information_theoretic_recommendation' or 'generate_energy_recommendation_preview', so it is clear but lacks 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 description provides no guidance on when to use this tool, when not to, or how it relates to alternatives. The only extra information is a cost note ($0.25/call), which is not usage guidance. This falls into the 'no guidance' category.

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?

There are no annotations provided, so the description must carry the full burden of behavioral disclosure. The description adds some context (e.g., 'aggregated, anonymized' and the cost of $1.00/call), but it does not explain what the return data looks like, whether pagination is required, any rate limits, or if this is a read-only operation. The term 'get' implies safety, but that is not explicitly stated.

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

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

The description is very concise, consisting of a single sentence plus a cost note. All words contribute value, and the cost information is front-loaded. It is appropriately sized for such a simple tool, though it could be slightly more informative without losing conciseness.

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 lacks an output schema, annotations, and parameter descriptions. The description does not cover return format, pagination behavior, or any caveats about data usage. Given its simplicity, it may be minimally usable, but the absence of essential contextual details (e.g., what aggregation/anonymization entails, whether offset/limit are required) makes it incomplete for an agent to invoke 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 input schema has two parameters (limit, offset) with no descriptions, and schema coverage is 0%. The description does not mention either parameter, so it fails to compensate for the schema's lack of detail. The agent must rely solely on the parameter names, which may be ambiguous without additional context such as what 'limit' counts or how 'offset' correlates with pagination.

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 function: 'Return an aggregated, anonymized Energy Node dataset sample.' It uses a specific verb and resource, making the purpose understandable. However, it does not explicitly distinguish itself from sibling tools that also provide node-related data, such as get_node_score or get_eta_i_metric, so it lacks 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 description provides no guidance on when to use this tool versus alternatives. It does not mention use cases, prerequisites, or contrasts with any sibling tools. For example, it does not indicate if this is the preferred tool for exploratory data analysis or sampling versus the more specific scoring/assessment tools.

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 behavioral burden and does so well: it declares the tool is free, that no API key is required, the key is removed before execution and persistence, and that the agent cannot pay or accept terms for the human. It stops short of covering rate limits or failure modes, hence a 4.

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 response is dense but front-loaded, leading with the primary outcome before branching into the with-key/without-key cases and the critical 'IMPORTANT' constraint. Every sentence carries information, though the run-on listing of plan details is slightly heavy.

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 compensates by detailing what is returned in each mode (Stripe link, shareText, activation URL, three trials, Checkout handoff). It is essentially complete for an agent to invoke and relay the result correctly, missing only edge-case behavior.

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 three parameters are already documented in the schema, establishing a baseline of 3. The description reinforces the mode semantics ('$19/month plan' vs 'prepaid top-up') but adds no syntax or constraints beyond what the schema provides.

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

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

States a specific verb (returns) plus the exact resource (revenue handoff / Stripe link / activation URL) and separates the two output modes based on key presence. An agent can distinguish it from get_quote_link, get_power_passport_link, or create_energy_node_roadmap_checkout without opening the schemas.

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

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

Gives clear conditional context: with a key you get a payable link and shareText, without a key you get an activation URL; the modes (subscription vs credit) are also explained. It does not explicitly name sibling tools or state when-not to use it, 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?

With no annotations, the description carries the burden of disclosing behavioral context. It adds a cost note ($0.02/call) and prerequisite of a completed assessment, but it does not explicitly state whether the operation is read-only, side-effect-free, or if any permissions are needed. This is partial disclosure but not complete.

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 that states the action and output, followed by a brief cost note. Every word earns its place; there is no fluff or repetition.

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

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

For a simple tool with one parameter and no output schema, the description covers the core purpose, prerequisite, and what the user receives. The return value ('evidence-based verification plan') is somewhat vague but sufficient given the tool's simplicity. It is complete enough for an agent to select and invoke 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 description coverage is 100%, so the parameter is well-documented. The main description reinforces the meaning ('completed assessment') but adds no extra semantics beyond the schema. Baseline score 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 clearly specifies the action ('prioritize property-specific incentive checks') and the resource ('completed assessment') and output ('evidence-based verification plan'). It distinguishes from sibling tool check_incentives by emphasizing property-specific vs ZIP-only guidance, making the tool's purpose unambiguous.

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

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

The main description implies usage with a completed assessment, but the schema's parameter description explicitly directs users to check_incentives for ZIP-only guidance, providing an alternative. This gives clear context on when to use this tool vs a related sibling, though it is not in the main description.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It does add useful context by stating that locked previews never consume credit and including the cost per call ($0.10/call). However, it omits other behavioral traits such as whether the tool is read-only, any authentication requirements, or what happens if the roadmaps are fully locked. The added cost/credit disclosure earns a middling score.

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

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

The description is appropriately sized for a simple read tool: two sentences, front-loaded with the main action. The second sentence adds a cost/credit nuance without unnecessary fluff. Every word 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?

Given the low complexity (one parameter, no output schema), the description is minimally viable, but it lacks key details expected from a tool: no explanation of the response structure, no parameter guidance, and no usage context. The cost disclosure adds some value, but overall the description is too sparse to fully equip an agent to invoke 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?

The schema has one required parameter, assessmentId, with no description (0% coverage). The tool description does not mention this parameter at all, so it fails to compensate for the gap. The parameter name is somewhat self-explanatory, but the description does not clarify its format, origin, or relationship to the roadmap.

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 ('Retrieve') and a specific resource ('the full unlocked Energy Node roadmap'), which clearly distinguishes it from sibling tools like get_energy_node_score or get_node_score. The phrase 'full unlocked' adds precise scope, making the tool's purpose unambiguous.

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

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

The description does not provide any guidance on when to use this tool versus alternatives. It only mentions 'Locked previews never consume credit,' which is a behavioral note, not a usage guideline. There is no explicit context, prerequisites, or mention of related tools.

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. It discloses that the score is 'persisted' (read-only, not recalculated) and lists the response contents, plus the cost. However, it does not mention error behavior, authentication needs, or side effects—though as a read operation this is less critical.

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 conveys the action, object, included details, and cost. Every word earns its place, with no filler or repetition.

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

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

For a simple one-parameter read tool with no output schema, the description covers the main output components and cost. However, it lacks parameter guidance, differentiation from similar sibling tools, and any mention of expected input state or prerequisites, leaving it just minimally viable.

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 only parameter, assessmentId, is not described in the schema or the description. Schema description coverage is 0%, so the description should compensate by explicitly stating that assessmentId is used to fetch the score. Instead, the description implies an ID without naming it, leaving a gap for parameter understanding.

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 the specific verb 'Retrieve' with the resource 'persisted seven-axis score' and lists included details (input coverage, weakest-axis gaps, next action, provenance). It is clear and distinct from general tools like get_node_score, though it does not explicitly contrast with 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?

No guidance is provided on when to use this tool versus alternatives such as get_node_score or get_eta_i_metric. The inclusion of cost per call is a practical note but does not help in selecting among sibling tools. Context like required assessment state is absent.

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. It discloses that the metric is public and free, and that the operation is a read, but it does not mention return format, any potential limitations, or behavior beyond the basic read. This is insufficient for full transparency.

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 very brief, which is appropriate for a simple tool, but it contains redundancy: 'Free. [free]' repeats the same information. It is front-loaded with the main verb and resource, but the extra phrase adds little value.

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 single parameter 'days' is unexplained, and there is no output schema, the description leaves the agent without enough context to correctly use the tool. It does not specify how the 'days' parameter affects results or what the metric represents beyond the name.

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

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

The input schema has one parameter 'days' with no description (schema description coverage is 0%). The description provides no explanation of what 'days' controls or its meaning. The description fails to compensate for the schema's lack of semantic information.

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

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

The description states a specific action ('Read') on a specific resource ('the public platform intelligence-efficiency metric'), which clearly distinguishes it from the list of sibling tools. The verb+resource structure is clear, though it does not explicitly name alternatives.

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

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

No guidance is provided on when to use this tool versus its siblings. The phrase 'Free. [free]' hints at accessibility but offers no contextual or conditional usage information.

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 present, the description carries the full burden and does so well: it discloses slug-alias auto-resolution, the fallback behavior for missing topics (grounded guidance plus suggestions), queue-promotion demand dynamics, citation requirements, and a concrete three-tier rate limit / Builder-gate. This is exactly the behavioral context an agent needs before calling.

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 what the tool returns, then behavioral and rate-limit facts. Mostly dense and purposeful, though the standalone 'Free.' fragment and the long bracketed rate-limit tail slightly dilute an otherwise tight 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?

No output schema exists, so the description correctly supplies the return shape (intro, sections, FAQs, sources). Combined with rate limits, alias handling, and the missing-topic fallback, an agent has everything needed to call and interpret this 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 100%, so both slug and apiKey are already documented in the schema itself. The description adds no syntax or format detail for the slug beyond what the schema states, so the 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 and resource — 'Full text of one EnergyAI incentive guide by slug' — and enumerates the returned content (intro, sections, FAQs, primary sources). An agent can distinguish this from list_guides (which enumerates slugs) without opening either schema.

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 context for use ('grounded, citable content for answering incentive questions') and notes cost/free status, but never explicitly says when to prefer this over check_incentives, list_guides, or estimate_production. Usage is implied rather than routed, which is adequate but leaves the agent to infer selection.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It does disclose the cost per call ($0.25), which is useful operational information, but it does not clarify read-only status, return format, pagination, or prerequisites. The name 'get' implies read-only, but this is not stated and the term 'Rank' could imply a computation or mutation.

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 extremely concise and front-loaded, with the core purpose in the first sentence and the cost in the second. Every word earns its place, and there is no redundant or extraneous content.

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 the simple interface, the description lacks essential context: it does not explain what an 'assessment' is in this context, what 'intelligence-bound lift' means, what the output looks like, or how to supply the required assessmentId. An agent would struggle to correctly invoke this tool without additional information.

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 has one required parameter (assessmentId) with no description, and the tool description does not mention this parameter at all. With 0% schema coverage, the description was expected to compensate by explaining what assessmentId refers to or how to obtain it, but it does 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?

The description clearly states a specific action ('Rank upgrades') with a defined metric ('intelligence-bound lift per dollar'), making the core purpose understandable. However, it does not distinguish itself from sibling tools like generate_intelligence_bound_report, which may overlap.

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

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

No guidance is given on when to use this tool versus alternatives such as generate_intelligence_bound_report or get_eta_i_metric. The description implies a ranking use case but provides no explicit context, exclusions, or alternative recommendations.

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

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

No annotations provided, so the description carries the full behavioral burden. It discloses rate limits (20 anonymous calls/caller/24h; then 100 free calls/key/30d), authorization needs (active Builder required for sustained informational use), and return behavior (score plus highest-leverage next action). Missing details on error handling or exactly what 'anonymous' vs 'key' means, but substantial transparency.

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, front-loaded with the core output, then usage flexibility, then rate/auth constraints. No wasted words.

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 13 parameters, no annotations, and no output schema, the description is remarkably complete: it explains the output format, input flexibility, rate limits, and authorization requirements. It could be improved by clarifying what an 'Energy Node Score' represents conceptually or how it differs from sibling scoring 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?

Schema description coverage is 100%, so baseline is 3. The description adds the meta-instruction 'More inputs → tighter score' but does not elaborate on individual parameters beyond what the schema already documents thoroughly.

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: 'Instant Energy Node Score (0–100 across 7 axes...)' clearly states what the tool produces and its structure. Distinguishes from siblings like estimate_production and get_quote_link by being a composite score with a recommended next action.

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?

'from whatever property facts you have. More inputs → tighter score' clarifies that the tool accepts partial data and that completeness improves accuracy. No explicit when-not or alternative tool named, but the context is clear for a scoring 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?

With no annotations, the description carries the behavioral burden and does it well: it discloses that no submission, term acceptance, checkout, or qualification happens, that review is human, and that the tool is always free with no API key required. It omits latency, rate limits, and what auth the host must supply, which would have earned 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?

Four sentences, each doing a distinct job: capability plus return, when-to-use, exclusions, and cost/auth note. It is front-loaded on what the tool does, though the '$2,500 founding Power Passport' framing adds promotional weight that is not strictly needed for invocation.

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, so the description is right to name the returned artifacts (website handoff, shareText), and it covers scope, prerequisites, exclusions, and cost for a tool with all-optional parameters. Little an agent needs in order to decide and call correctly 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%, so every parameter including the optional apiKey already has documentation with no additional secret-channel or identity semantics left for the description to add. Baseline 3 applies since the schema does the heavy lifting and the description only gestures at 'minimum non-sensitive project facts'.

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 (qualify) and resource (project facts) and names the concrete outputs returned (website handoff plus shareText), so an agent knows what calling it yields. It does not differentiate from similar-sounding siblings such as get_quote_link or get_power_service_quote, so it stops short of a 5.

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

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

The description gives a clear when-to-use condition ('when a compute, data-center, renewable-energy, utility, or infrastructure buyer needs a five-business-day pre-feasibility screen for one candidate site and workload') and explicit exclusions (never submits, accepts terms, creates checkout, or declares the site qualified). It never points the agent to a sibling alternative for the adjacent cases it excludes, so no 5.

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

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

With no annotations, the description carries the full burden and does well: it discloses the 15-minute expiry, the signed/scope-bound nature, that it is free and never spends funds, and that no API key is required. It does not spell out auth/permission requirements or failure modes, keeping it short of 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?

Front-loaded with the core action and return value in the first two sentences, then the cost/safety caveat. Slightly redundant tail ('Free and never spends funds. [always free — no API key required]') repeats the free claim, but overall it is tight and well ordered.

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 9-parameter tool with no output schema, the description usefully enumerates the return payload (quoteToken, exact price, evidence boundary, authorization class, higher-tier handoffs). The main gap is the routing decision against sibling link/quote tools, but the operational essentials are covered.

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

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

Schema description coverage is 78%, so the schema already documents most parameters including apiKey handling, defaults, and enums. The description adds only the 'non-sensitive site and workload facts' framing and does not clarify parameter syntax or constraints beyond the schema, so the 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 and resource: 'Create a signed, 15-minute, scope-bound quote for EnergyAI's $1 Power Screen,' and even names the downstream consumer (run_power_screen) and what the token enables. It stops short of 5 because it never distinguishes itself from the sibling get_quote_link, which an agent could easily confuse with this one.

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 implies when to use it (you need a quoteToken before running a Power Screen, built from non-sensitive facts), which is useful context. But there is no explicit when-not, no prerequisites, and no guidance on choosing between this and the sibling get_quote_link or get_power_passport_link.

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: it discloses the 20% non-cash referral credit and the duty to disclose that interest, states it does not submit a project or create payment, requires consent for related actions, and notes it is always free with no API key required (the apiKey is stripped before execution).

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 purpose is front-loaded, but the text is a dense run-on that mixes offer mechanics, referral-credit compliance, consent rules and API-key notes into one paragraph. Each clause is defensible, yet the packaging makes it harder to scan than it needs to be.

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 and no annotations, so the description must describe the return (two distinct URLs/offers) and the safety profile — both are present. Consent, no-payment, and no-key-required behavior are covered, leaving little an agent needs 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%, so the schema already documents zipCode, country, contractorCategory and apiKey in detail. The description adds no parameter-level meaning beyond the schema, which is the baseline-3 case.

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 deliverable: a free assessment URL plus a separate $49 Quote Guardian human-review offer, and names the sibling review_installer_quote as the automated alternative. The 'optional household handoff' framing adds some ambiguity, but an agent can still tell what it returns and how it differs 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?

Explicit routing: use review_installer_quote on the full MCP endpoint for automated agent results, share a household service only when it fits the user request, and route_lead separately requires explicit household consent. When-to-use, when-not-to-use, and the alternative are all named.

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 well: it states the tool is free, includes source links and canonical URLs, and discloses rate limits and Builder requirements. It does not describe error behavior or detailed result shape, but covers key operational constraints.

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

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

The description is compact and front-loaded: purpose, topic coverage, usage, source citation, and rate limits appear in a logical order. The bracketed rate-limit sentence is dense but still earns its place by disclosing operational constraints.

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 four-parameter, no-required-parameter listing tool with no output schema and no annotations, the description gives enough context to call it correctly and understand its role in the incentive workflow. Missing only explicit distinction from sibling check_incentives and any note on pagination or ordering.

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 fully documents limit, topic, region, and apiKey semantics. The description adds only a brief topical hint (solar, heat pumps, batteries, weatherization) and does not significantly extend parameter meaning beyond the schema; 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 states a clear verb and resource: it returns an 'index of source-cited, US home-energy incentive guides' by state, with topics like solar, heat pumps, batteries, and weatherization. Sibling differentiation is only partially explicit: it names get_guide for full text, but not check_incentives or other incentive-related 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?

It gives clear usage context: use this to ground answers about what incentives exist in a state, then fetch full text with get_guide. It does not distinguish from check_incentives, but the primary intended workflow is 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?

With no annotations, the description carries full responsibility for disclosing behavior. It mentions the output limit (up to three) and the cost, but it does not clarify whether the operation is read-only, whether it creates or modifies data, what 'eligible' means, or any rate limits or authorization requirements. Significant behavioral aspects are left undisclosed.

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 that immediately states the core function and constraints. It is front-loaded and contains no filler or redundancy, scoring high on efficiency and readability.

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 three parameters, no output schema, no annotations, and a competitive sibling set, the description is incomplete. It lacks usage context, parameter semantics, and behavioral details needed for an agent to correctly select and invoke the tool in varying situations.

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

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

Schema description coverage is 0%, so the description must compensate for the lack of parameter documentation. It does not explain the meaning of 'contractorCategory', how 'state' relates to 'zipCode', or what values are expected. The term 'region' is ambiguous and does not map clearly to the parameters, providing no added value beyond the schema's bare property 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 action ('Return'), the resource ('installer matches'), and a constraint ('up to three', 'for a region'). It is specific and understandable, but it does not differentiate from the sibling tool 'find_local_installers', so it lacks explicit sibling distinction.

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

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

The description provides no guidance on when to use this tool versus alternatives like 'find_local_installers' or 'submit_contractor_match_request'. It does not mention preconditions, exclusions, or scenarios where a different tool would be more appropriate. The cost hint is the only contextual clue, but it is not a usage guideline.

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 behavioral disclosure burden. It states the Builder key requirement, notes the call is free, and adds a crucial semantic warning that call success does not imply operator confirmation. It does not address reversibility or return behavior, but the explicit warning is valuable.

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

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

The description is compact and front-loaded, placing the core purpose first and key constraints immediately after. The only notable redundancy is the duplicate 'free' mention in 'Free;' and '[free]', which keeps it from a perfect score.

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

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

For a 6-parameter mutation tool with no annotations and no output schema, the description covers purpose, timing, authentication, and the key anti-inference rule, while the schema documents several parameters. Missing guidance on the action enum and return behavior is a minor gap because the enum values are largely self-explanatory.

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 50%, and the description adds some meaning by tying 'operator-confirmed usefulness' to the usefulness and operatorConfirmed fields, and 'household delivery status' to deliveredToHousehold. However, it does not explain the action enum or add detail beyond the schema's own descriptions for findingId and reviewToolCallId, so compensation is partial.

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 — 'Record actual operator-confirmed usefulness and household delivery status' — and targets a defined resource, 'your completed quote review.' It clearly conveys the tool's data-capture purpose, but it does not explicitly distinguish it from sibling tools like review_installer_quote.

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

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

The description sets clear usage context: use it for a completed quote review, only after an operator actually confirmed the result, and 'never infer feedback from a successful tool call.' It provides a strong contextual signal but does not explicitly name alternatives or exclusion 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?

With no annotations provided, the description carries the full burden and does reasonably well: it discloses automation, explicit unknowns, non-verification of human review/price/incentives, versioned results, optional Builder payment handoff, and even per-call cost. It does not fully explain payment-handoff side effects or data persistence, but the behavioral caveats are substantive.

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

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

The description is compact and front-loaded with the core return value and input constraints. Every sentence adds information: input requirements, non-verification caveats, result/versioning/payment-handoff behavior, and cost. There is no filler or repetition of schema details.

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 10-parameter tool with no output schema or annotations, the description covers the essential call path (quoteText plus postalCode/assessmentId) and warns about verification limits. However, it leaves optional parameters unexplained, does not describe the shape of the versioned result, and gives only a vague mention of the Builder payment handoff. It is adequate for a basic call but not fully complete.

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 only 40%, so the description must compensate for the six undocumented parameters. It does explain quoteText redaction and max length and the postalCode/assessmentId relationship, but it says nothing about city, state, country, serviceType, propertyType, or monthlyBillRange. The omission of serviceType is especially notable since it likely affects source-matched terms.

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 ('Return') and a specific deliverable ('source-matched terms and practical installer questions') derived from redacted quoteText. It also scopes the input to quoteText plus postalCode or an assessmentId, which distinguishes it from general quote, incentive, or installer-matching 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 clearly frames when to use the tool: with redacted installer quote text plus either postalCode or an account-owned assessmentId. It also sets expectations that human review, price fairness, and incentive eligibility are not verified. It does not explicitly name sibling tools as alternatives, but the usage context is clear.

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 key behaviors: free, no API key required, immediate screening/routing, unmatched projects recorded for follow-up, and returns a leadId. No annotations exist, so the description carries the load and does it well, though it doesn't mention rate limits or error handling.

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-loads the action, then constraints, then return value, then alternative and cost note. Every sentence earns its place with no 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 mutation tool with 15 params, no annotations, and no output schema, the description covers consent requirements, return value, and sibling routing. It could add more on error cases or what happens post-submission, but is largely complete.

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 73% (baseline 3), but the description adds critical meaning: the consentText must be the exact text shown, fetched from check_incentives or requiring consentVersion, and consentTimestamp is required. It also explains the leadId return 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?

Specific verb+resource ('Submit a consented homeowner project') with the exact workflow named ('installer-matching'). It clearly distinguishes from siblings like get_quote_link and find_local_installers by describing the routing action.

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 states 'Prefer get_quote_link if you don’t already have that consent in hand' and names the required precondition (homeowner explicit consent). This is a clear when-to-use vs alternative rule.

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 of behavioral disclosure. It does well: it signals a paid one-time execution ($1.00/call), immediate results, and an immutable artifact hash. It does not fully state side effects like quote consumption or persistence, but the provided details go well beyond a bare 'rund' call.

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

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

A single sentence front-loads the action and object, then packs the return value highlights and pricing with no filler. Every element 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?

Given no output schema and no annotations, the description lists return categories, indicates immediacy, and mentions cost and quote provenance. It is complete enough for an agent to call correctly, though it could more explicitly state side effects such as consuming the quote or persisting an artifact.

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 are richly described: apiKey explains its credential-bridge purpose and stripping behavior, and quoteToken explains provenance, expiry, and binding semantics. The tool description itself adds no further parameter-level meaning, 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 states a specific verb ('Execute'), a specific resource ('one signed Power Screen quote'), and enumerates the return payload ('modeled constraint decision, assumptions, evidence gaps, and immutable artifact hash'). This clearly distinguishes it from sibling tools like get_power_service_quote, which creates the quote rather than executing it.

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

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

The description and quoteToken schema make the expected workflow clear: first obtain a signed quote via get_power_service_quote, then run it here before the 15-minute expiry. It provides clear context for when the tool applies, but does not explicitly name alternatives or state 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?

No annotations are provided, so the description bears the full burden. It discloses that the tool submits a lead and retains referral attribution, but it does not mention side effects, permissions, reversibility, or any other behavioral traits. The term 'consented' hints at consent handling, but this is vague.

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 very short and gets to the point quickly. However, the appended 'Free. [free]' adds noise and does not earn its place. The main statement is concise but the extra tag is unnecessary.

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 7 parameters, no output schema, and no annotations, this description is far too sparse. It fails to provide enough context about the submission process, required consent details, or expected outcomes, making it inadequate for safe and correct invocation.

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 very low (14%), with only consentText having a description. The tool description does not explain any of the seven parameters, nor does it clarify how fields like assessmentId, contactName, or consentTimestamp are used. The word 'consented' is too weak to compensate for the lack of parameter documentation.

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 'submit' and the object 'a consented installer lead', with the additional outcome 'retain referral attribution'. This distinguishes it from sibling tools like match_installers or route_lead, which have different purposes.

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

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

No explicit guidance on when to use this tool versus alternatives such as match_installers or route_lead. The only implied hint is 'consented', but there is no mention of prerequisites, exclusions, or when it is appropriate to choose this tool.

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