energyai

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

No annotations provided; description only states 'Free; usage tracked' and 'Submit one question answer,' lacking details on side effects, idempotency, or error conditions.

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

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

Extremely brief but at the expense of clarity. The single-line description with '[free]' is too terse for a tool with four parameters and no structured metadata.

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

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

Given the tool's complexity (multiple required parameters, no output schema, no annotations), the description fails to provide essential context about answering assessment questions, expected input formats, or return 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?

With 0% schema description coverage, the description adds no meaning to the four parameters (assessmentId, questionKey, answerValue, answerLabel). The agent gets no help understanding what each parameter represents.

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 'Submit one question answer' clearly indicates the action ('submit') and the resource ('one question answer'), differentiating it from sibling tools like complete_energy_assessment.

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 (e.g., complete_energy_assessment). Only mentions 'Free; usage tracked,' which hints at cost but not usage context.

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

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

Annotations are absent, so the description must convey behavioral traits. It mentions triggering autopilot, a notable side effect, but fails to disclose whether the action is destructive, reversible, or requires authorization. Details about the finalization process itself are missing.

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 exceptionally short with two distinct clauses. While it could benefit from structured presentation (e.g., bullets), every sentence provides unique information without 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 one-parameter tool with no output schema, the description is incomplete. It omits the meaning of assessmentId, what happens after finalization (beyond autopilot), and the response format. The '[free]' note is useful but insufficient.

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 adds no meaning to the single parameter 'assessmentId'. With 0% schema description coverage, the agent receives no guidance on the parameter's purpose, format, or source. This is a critical gap.

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

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

The description clearly states the tool's action 'Finalize assessment' with a specific verb and resource. It also adds context 'triggers autopilot' which distinguishes it from sibling tools like create_energy_assessment or answer_energy_assessment_question. The purpose is unmistakable.

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 prerequisites (e.g., assessment must exist) or situations where it should not be used. The '[free]' hint is cost-related, not usage context.

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

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

With no annotations, the description carries the full burden. It only mentions 'Free' and 'Start a new assessment session,' with no disclosure of side effects, authentication needs, or what happens after creation. This is insufficient for a state-changing action.

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 (one sentence) and to the point. It is efficient but could benefit from slightly more context without becoming verbose.

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

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

Given no parameters and no output schema, the description is adequate for a simple action. However, it does not explain what a session entails or how it relates to sibling tools, leaving gaps in the overall workflow understanding.

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 zero parameters, so schema description coverage is 100%. The description adds no parameter info, but there are none to document. Baseline 4 is appropriate.

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

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

The description clearly states 'Start a new assessment session,' which is a specific verb+resource. It distinguishes from sibling tools that involve answering questions or generating reports, but does not explicitly differentiate itself.

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 like answer_energy_assessment_question or complete_energy_assessment. The description lacks context about prerequisites or workflow order.

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 description bears full burden. Only discloses price and payment direction; lacks details on side effects (e.g., creating Stripe session), idempotency, required prior steps (e.g., assessmentId must exist), or auth requirements.

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?

Very concise single sentence with '[free]' tag, but excessive brevity sacrifices parameter and usage context. No bullet points or structure; front-loaded with purpose but missing organized 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?

Lacks output schema, annotations, and parameter descriptions. Does not mention prerequisites (e.g., existing assessment from create_energy_assessment) or expected response format beyond the URL. For a tool in a workflow, this is insufficient.

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 description adds no meaning beyond schema. Both 'email' and 'assessmentId' are unexplained; agent cannot infer what assessmentId refers to or why email is optional.

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

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

Clearly states it gets a Stripe Checkout URL for the $19 paid roadmap, distinguishing it from the free roadmap tool (get_energy_node_roadmap) in the siblings list. The verb 'Get' and resource 'Stripe Checkout URL' are specific.

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?

Implies use when user wants to pay $19 for the roadmap (end user pays Viridis directly). Lacks explicit 'when not to use' or alternative names, but sibling 'get_energy_node_roadmap' provides context for free version.

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. It implies a read-only preview, but does not explicitly state that it does not modify data, nor does it disclose any side effects, permissions, or limitations beyond pricing.

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 (two sentences) and front-loaded with key points (free-tier, ranges, next best action, cost). However, it sacrifices completeness for brevity.

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 and lack of output schema or annotations, the description should provide more context on return values, usage context, and expected behavior. It only covers preview type and pricing, leaving significant gaps.

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 has one parameter 'assessmentId' with 0% description coverage. The description adds no semantic information about the parameter, such as its source, format, or constraints. It only hints at 'ranges, next best action' without linking to the input.

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 mentions 'Free-tier preview (ranges, next best action)' which gives some indication of what the tool produces, but it lacks a clear verb-active-resource structure. It does not differentiate from siblings like 'get_information_theoretic_recommendation' or 'get_energy_incentives'.

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 alternative tools. The description only notes it is a free-tier preview and states a cost, but does not specify conditions for use or exclusions.

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

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

No annotations are provided, so the description must compensate. It discloses the cost ($0.50 per call), but does not mention whether the tool is read-only, destructive, or any other behavioral traits like rate limits or side effects.

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

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

The description is concise (two sentences) with no fluff, but it lacks necessary details. It is adequately structured for brevity but at the expense of completeness.

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 does not explain the report's return format, content, or any additional context needed for an agent to correctly invoke and use 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?

Only parameter 'assessmentId' is defined in schema with 0% description coverage. The tool description does not explain what assessmentId represents or how to obtain it, leaving the agent uninformed.

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?

Description mentions 'Property-specific dI/dt analysis with current and post-roadmap projection', which gives some idea of the tool's output but lacks a clear action verb (e.g., 'generates', 'produces'). The purpose is somewhat clear but could be more precise.

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 vs. siblings like 'generate_energy_recommendation_preview' or 'get_energy_node_roadmap'. No prerequisites or context are provided.

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 of behavioral disclosure. Other than pricing, it does not disclose read-only or destructive nature, auth requirements, rate limits, or response behavior. The pricing info is helpful but 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 brief at two sentences, but the first sentence front-loads the purpose while the second adds pricing. It is concise but omits critical details about parameters and behavior, making it less effective.

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 absence of output schema and annotations, and the low schema coverage, the description is incomplete. It covers pricing and eligibility but fails to describe the return format, pagination via limit/offset, or any usage constraints for a tool with 0 required 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 does not mention the two parameters (limit, offset). It fails to explain their meaning or usage, providing no added value beyond the schema's basic structure.

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 'Anonymized aggregated Energy Node profiles for research,' which clearly identifies the resource and its purpose. The tool name includes 'get', implying retrieval, but the description lacks an explicit verb. It is distinct from sibling tools which focus on assessments and roadmaps.

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 eligibility and pricing: 'Free for verified .edu merchants. $2.00/call commercial.' This gives context on when to use based on user type, but no guidance on when not to use or alternatives among the many sibling 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?

The description adds transparency by noting the data is 'Honest, 2026-accurate' and 'DSIRE-grounded', which informs quality and source. However, no annotations exist, so it should disclose more (e.g., read-only, no side effects). Partial coverage.

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

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

Extremely concise at 18 words, front-loaded with key action and data source. Every sentence earns its place.

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

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

With no output schema and only two params defined, the description is insufficient. It omits details about return format, prerequisites, and the role of assessmentId.

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

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

Schema coverage is 0%. The description only mentions 'by ZIP', but the schema includes 'assessmentId' with no explanation. The description fails to add meaning for the second parameter.

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

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

The description clearly states the tool returns a state/utility incentive checklist by ZIP code, which is a specific verb+resource. It distinguishes from sibling tools like create_energy_assessment or get_energy_node_score, as this one focuses on incentives.

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 cost ($0.10/call) but does not explain prerequisites or exclusions.

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

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

No annotations are provided, so the description carries the full burden. It notes the cost and payment condition but fails to disclose response format, error behavior, side effects, or authentication needs. The phrase 'full unlocked' hints at state dependency but lacks detail.

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 short (two sentences) but information-dense with pricing and condition. However, it lacks explanatory structure and misses crucial parameter and behavioral details, making it less 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 with no output schema and low schema coverage, the description should be more comprehensive. It only covers payment and cost, ignoring what a 'roadmap' entails, what the response contains, and how to handle failures, leaving the agent under-informed.

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 0% description coverage for its only parameter 'assessmentId'. The description does not mention this parameter, adding no meaning beyond the schema. With low 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 'Full unlocked roadmap' combined with the tool name implies retrieving a comprehensive roadmap. It distinguishes from siblings like 'get_energy_node_score' and 'get_energy_incentives'. However, the verb is not explicit (e.g., 'retrieves' or 'gets'), relying on the tool name.

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 mentions a precondition ('after end-user $19 payment') and a cost per call, providing some usage context. However, it does not explicitly state when to use vs alternatives like 'create_energy_node_roadmap_checkout' or when not to use.

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. The description mentions cost ($0.15 per call), which is a useful behavioral detail, but does not disclose other traits like data freshness, authentication needs, or side effects.

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 (two sentences, one of which repeats pricing), but it sacrifices critical information for brevity, making it under-specified rather than concise.

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 minimal input schema (1 param, no output schema) and lack of annotations, the description is severely incomplete; it does not explain the output format or provide enough context for 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 description coverage is 0% and the description does not explain the 'assessmentId' parameter (e.g., what it represents or how to obtain it), leaving the agent without needed context.

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 '7-axis Energy Node Score breakdown', which implies retrieval of a score breakdown, but uses no verb and does not distinguish from sibling tools like '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?

No guidance is provided on when to use this tool versus the many sibling tools (e.g., get_eta_i_metric, get_energy_node_roadmap). The only extra info is pricing, which 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?

No annotations provided, and the description adds minimal behavioral context. It mentions 'Free' implying no cost, but does not disclose rate limits, data freshness, idempotency, or other traits.

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 short but includes redundant '[free]'. It is generally concise but could be more informative without adding length.

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 simplicity of the tool (one optional parameter, no output schema), the description is incomplete. It fails to explain the metric's return format, how 'days' affects results, or any other usage details.

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 'days' is not mentioned in the description. With 0% schema coverage, the description completely fails to explain its purpose or valid range.

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 identifies the resource as a public metric, clearly distinguishing it from sibling tools like get_energy_node_score. However, 'intelligence-efficiency metric' is somewhat vague and does not specify what the metric represents.

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 vs alternatives. The description only states it is 'Public' and 'Free' but does not provide context for appropriate usage scenarios.

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 the cost ($1.00 per call) which is a useful behavioral trait. However, no annotations exist, so the description must fully cover behavioral aspects like whether it is read-only, authentication requirements, or side effects. It does not mention these, leaving significant gaps.

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

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

Extremely concise with only two brief sentences. While concise, it sacrifices important details, making it less useful. The cost note is redundant with the previous sentence.

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 minimal input schema documentation, the description should explain the output format or metric definition. It fails to define 'intelligence-bound lift per dollar' or describe what the tool returns, leaving the agent without sufficient context to invoke it correctly.

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

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

The single required parameter 'assessmentId' is not explained in the description. With 0% schema description coverage, the description should clarify what an assessmentId is or how to obtain it, but it provides no additional meaning beyond the schema.

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

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

The description states it ranks upgrades by a specific metric ('intelligence-bound lift per dollar'), which is a clear and specific purpose. It differentiates from siblings like 'generate_intelligence_bound_report' by focusing on ranking per dollar. However, the tool name uses 'get' while description says 'ranks', causing slight ambiguity.

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 vs alternatives such as 'generate_intelligence_bound_report' or 'get_energy_node_score'. The phrase 'V2 recommendation' is vague and does not provide context for when this is appropriate.

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 disclose behaviors. It mentions a limit of 3 matches and a cost of $0.50 per call, but does not state whether it is read-only, if it modifies data, or any other side effects. This is insufficient for a tool that incurs cost.

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, consisting of two phrases. While concise, it lacks essential information about usage and parameters. It is not structured in a way that helps an agent quickly understand 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?

For a 3-parameter tool with no output schema and no annotations, the description is severely incomplete. It does not cover return format, error conditions, or how to specify the region. This leaves significant gaps for an agent to correctly 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 description does not explain any parameters despite 0% schema coverage. It mentions 'region' but does not clarify how zipCode or state relate. The required parameter 'contractorCategory' is not described at all, leaving the agent with no guidance on valid values.

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

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

The description clearly states that the tool matches installers, with a limit of up to 3 matches per region. The verb 'match' and resource 'installers' are specified, and the mention of region and cost provides additional context. However, it does not distinguish itself from sibling tools like 'submit_contractor_match_request'.

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

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

The description implies usage when needing installer matches, but it does not provide explicit guidance on when to use this tool versus alternatives. The mention of cost may hint at cautious usage, but no exclusions or alternatives 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?

No annotations are provided, so the description bears the full burden. It discloses the cost ($0.25/call) and indicates the tool flags issues without modifying data. However, it does not mention side effects, required authorization, or whether it is read-only.

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

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

The description is concise with two clear sentences covering purpose and cost. The nickname 'Quote Guardian' adds flair without bulk. The repeated cost note in brackets is minor redundancy, but overall it is well-structured and front-loaded.

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

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

Given no output schema and two parameters, the description provides the core functionality and cost. However, it lacks details on return format, error handling, or how the per-home estimate is identified. The context is adequate for basic use but not exhaustive.

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 describes one parameter (quoteText) but leaves assessmentId undescribed. The description adds no further detail about what assessmentId is, despite 50% schema coverage. The purpose of assessmentId is implied but not clarified, which limits the agent's ability to correctly supply it.

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 that the tool benchmarks an installer quote against a per-home estimate and flags overcharge, undersizing, or missing warranty. The verb 'benchmark' and 'flag' combined with the resource 'installer quote' make the purpose specific and distinct from sibling 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?

The description implies usage when you have an installer quote to review against a home estimate, but it does not explicitly state when not to use it or compare it to alternatives like match_installers. The cost hint is provided, but no exclusions or prerequisites 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?

No annotations provided; description only reveals it is free and requires consent, but lacks details on side effects (e.g., submission creates a lead), authorization requirements, or response behavior.

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

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

Very concise, two sentences plus tag, no wasted words. However, could benefit from a structured list of parameters or usage steps.

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 several sibling tools, the description lacks context on prerequisites (e.g., existing assessment), error handling, and return value format. Incomplete for reliable agent use.

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 14% (only consentText described). Description mentions consentText and consentTimestamp but adds no meaning for 5 other parameters (assessmentId, contactName, contactEmail, contactPhone, consentVersion).

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?

Description clearly states 'Submit a consented installer lead' with verb and resource, and 'FREE' and affiliate model distinguish it from siblings like match_installers which likely perform different matching functions.

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 vs alternatives like match_installers; only implies consent is required but does not clarify conditions or exclusions.

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