osint

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, which the description does not contradict. The description adds behavioral context by specifying exactly what aspects are described (filters, groupings, etc.), which goes beyond what annotations provide.

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

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

The description is a single sentence that is front-loaded with the core action and scope. Every word is essential; there is no redundancy or fluff.

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

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

For a tool with no parameters and an output schema, the description is complete in stating what it describes. It could optionally mention it is for discovering valid inputs to the query tool, but the naming and sibling tools make this implicit.

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 no parameters (100% coverage with zero params). The description adds value by listing the types of information the tool returns about the queryable dataset, compensating for the lack of parameters.

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

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

The description clearly states it describes valid filters, groupings, metrics, detail fields, and citation fields for a specific dataset (ai_infrastructure.construction). The verb 'describe' and resource are explicit, and it distinguishes from sibling describe tools which cover different topics like capacity factor or power capacity.

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 usage context is clear from the name and sibling tools: this is a discovery tool for the corresponding query tool (query_ai_infrastructure_construction_v1). While it doesn't explicitly state 'use this before querying', the purpose is evident. No other tool describes the same dataset, so guidance is sufficient.

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

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

Annotations already indicate readOnly, idempotent, and non-destructive behavior. The description adds specific behavioral context by listing what aspects are described (filters, groupings, etc.), providing value beyond annotations.

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

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

The description is a single sentence that is concise, front-loaded, and contains no superfluous words. Every part of the sentence is meaningful.

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, existing output schema, and the tool's simple nature, the description is complete. It clearly communicates what the tool produces without needing additional 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?

There are no parameters, so schema coverage is 100% and the baseline is 4. The description does not need to add parameter information 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?

The description clearly states the tool's purpose: describing valid filters, groupings, metrics, detail fields, and citation fields for ai_infrastructure.employment. It uses specific verb+resource and distinguishes from sibling describe tools for other datasets.

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: before querying employment data, use this tool to discover available fields. However, it does not explicitly state when to use vs. alternatives, but the naming and context make it clear that sibling tools serve different datasets.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds specific context about what the tool describes (filters, groupings, etc.), which goes beyond the annotations. No contradictory information is present.

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 concise sentence that effectively communicates the tool's purpose without unnecessary words. It is front-loaded and 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?

Given the zero parameters and presence of an output schema, the description is adequate. It could optionally mention that it is intended to be used before querying trade data, but the current wording is complete enough.

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 zero parameters and 100% schema description coverage, the description does not need to add parameter information. The baseline score of 4 is appropriate as there is no missing 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 that this tool describes valid filters, groupings, metrics, detail fields, and citation fields for ai_infrastructure.trade. This is a specific verb+resource, and given the sibling tools, it distinguishes itself from other describe tools for different datasets.

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?

While not explicitly stating when to use this tool versus alternatives, the description clearly implies that it provides metadata for the trade dataset, which is a unique resource among siblings. The context of sibling tools (e.g., describe_ai_infrastructure_construction_v1) makes the usage 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?

Annotations already declare safe read-only behavior. Description adds formula and data sources, which is useful context beyond annotations.

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

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

Single sentence, no waste, front-loaded with key information.

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

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

With no parameters, rich annotations, and output schema present, the description provides formula and data sources, which is fully complete for a describe 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?

No parameters to document; schema coverage is 100%. Baseline 4 for zero parameters.

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

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

Clearly states verb 'describe', specific resource 'capacity factor', and provides the formula and data sources. Distinguishes from siblings by being a definition tool.

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 usage via 'describe' vs 'query' sibling distinction, but no explicit when-to-use or when-not-to-use guidance.

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

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

Annotations already indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds that it returns 'valid' elements, but does not disclose additional behavioral details beyond what annotations provide.

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 is front-loaded with the verb 'describe' and immediately states the resource. Every word contributes meaning.

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

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

Given zero parameters, full annotation coverage, and the presence of an output schema, the description is complete: it lists all categories of metadata returned (filters, groupings, metrics, detail fields, citation 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?

There are no parameters, so the baseline is 4. The description does not need to explain parameters, but it does explain that the tool returns metadata about query fields.

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 describes valid filters, groupings, metrics, detail fields, and citation fields for 'power.capacity'. The verb 'describe' and explicit resource distinguish it from sibling tools like describe_capacity_factor_v1.

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 this tool is used to obtain metadata before querying power.capacity, but it does not explicitly state when to use it versus alternatives. The sibling names provide context, but the description itself lacks 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?

Annotations already indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds transparency by enumerating exactly what aspects are described (filters, groupings, etc.), complementing annotations without contradiction.

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?

Single sentence front-loads the core action and includes all necessary details. No filler words, perfectly concise for a zero-parameter tool.

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 parameters, full annotations, and an output schema (implied), the description covers what the tool does and for which dataset. Complete for its role as a metadata discovery 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?

No parameters exist, so the parameter semantics dimension is satisfied by default. Schema description coverage is 100%. 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 uses specific verbs ('Describe valid filters, groupings, metrics, detail fields, and citation fields') and clearly identifies the target resource ('power.demand_rollup'). It distinguishes from siblings like describe_power_demand_v1 and query_power_demand_rollup_v1 by specifying the rollup variant.

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 before query_power_demand_rollup_v1 to understand available fields. The title adds context ('national / region rollup'), but no explicit when-not or alternatives are provided. Still, the purpose is clear for a describe tool.

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

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

Annotations already indicate the tool is read-only, idempotent, and non-destructive. The description adds specific behavioral context by detailing what aspects (filters, groupings, etc.) are described. No contradictions with annotations.

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

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

The description is a single, front-loaded sentence that conveys the tool's purpose efficiently without unnecessary 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?

Given the zero parameter input and presence of an output schema, the description adequately explains what the tool returns. It could be slightly more explicit about the return format, but the output schema likely covers that.

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 zero parameters and 100% schema coverage (empty schema), the description adds meaning by listing the categories of information provided (filters, groupings, metrics, etc.). It compensates for the lack of parameter detail, though could be more precise about the output 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 clearly states that the tool describes valid filters, groupings, metrics, detail fields, and citation fields for power.demand. This explicitly defines the tool's specific resource and action, distinguishing it from sibling describe tools that cover different subjects like capacity factor or power generation.

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 siblings. However, the description implies it is useful as a metadata discovery tool before running query_power_demand_v1. An explicit mention of this usage context would improve clarity.

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

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

Annotations already provide readOnlyHint=true, idempotentHint=true, and destructiveHint=false, making the tool's safety profile clear. The description adds no new behavioral context beyond the annotations, so a score of 3 is appropriate as it neither enriches nor contradicts the structured metadata.

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

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

The description is a single sentence that immediately conveys the tool's purpose without any extraneous information. It is front-loaded and every word contributes to clarity.

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 no parameters and an output schema is present, the description comprehensively lists what the tool describes (filters, groupings, atoms, metrics, detail fields, citation fields). This is sufficient for an agent to understand the tool's role as a metadata provider.

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 no parameters, and schema description coverage is 100%. Per the guidelines, 0 parameters warrants a baseline score of 4. The description does not need to compensate for missing parameter details.

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 explicitly states that the tool describes valid filters, groupings, atoms, metrics, detail fields, and citation fields for power.generation. It uses a specific verb (describe) and resource (power generation metadata), clearly distinguishing it from sibling describe tools targeting other topics.

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 explicitly state when to use this tool versus alternatives, nor does it mention its primary relationship with query_power_generation_v1. The usage is implied (to get metadata before querying), but the lack of explicit guidance and no mention of when not to use it results in a score of 3.

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 provides additional context beyond the annotations by specifying exactly what aspects (filters, groupings, etc.) are described. The annotations already indicate read-only and idempotent behavior, and the description is consistent. No contradiction and adds meaningful detail about the tool's output scope.

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 front-loads the essential information. Every word is necessary, and there is no redundancy or 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?

Given the tool has no parameters and includes an output schema, the description fully covers what the agent needs: it lists the types of fields that will be described. The annotations handle safety and side effects, making the description complete for this metadata 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 zero parameters, so the baseline score is 4 per the rubric. The description does not need to add parameter semantics since none exist, and it correctly omits extraneous 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 clearly states the tool's function: to describe valid filters, groupings, metrics, detail fields, and citation fields for the CAISO interconnection queue. The verb 'describe' and resource 'power.interconnection_queue_caiso' are specific, and the title reinforces the CAISO scope, distinguishing it from sibling tools for other regions.

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 to know available query parameters for the CAISO interconnection queue. However, it does not explicitly indicate when not to use it or how it differs from the generic describe_power_interconnection_queue_v1 or other regional describe tools. The title and name help, but clearer guidance would improve it.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds context about the specific dataset and what aspects are described (filters, groupings, etc.), but does not disclose additional behavioral traits beyond what annotations provide. No contradictions.

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-loaded with the core action ('Describe valid filters...') and efficiently lists all information categories. No redundant words or 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?

Given no parameters and an existing output schema, the description adequately covers what the tool returns. It explicitly names all major information categories. It does not mention that the output is a structured schema, but that is implicit from the tool type. Minor improvement would be to note the output format.

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

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

The tool has zero parameters and 100% schema coverage. With no parameters to document, the baseline is 4. The description accurately reflects that there are no parameters to set, simply naming the categories of information that will be returned.

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: it describes valid filters, groupings, metrics, detail fields, and citation fields for a specific dataset (power.interconnection_queue_ercot). This is a specific verb+resource pairing that distinguishes it from sibling describe tools for other regions or data types.

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 the tool is for exploring the ERCOT interconnection queue schema, but it does not explicitly state when to use it versus alternatives like describe_power_interconnection_queue_caiso_v1. No direct guidance on when-not or prerequisites is 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the description adds no further behavioral context. No contradiction noted.

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 informs the agent of the tool's purpose and scope. No unnecessary 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?

Given no parameters and the presence of an output schema, the description adequately covers what the tool does without needing to explain return values.

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

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

There are zero parameters and schema coverage is 100%, so the description does not need to add parameter information. The lack of parameters is appropriately handled by 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 tool name and description clearly specify the verb 'describe' and the resource 'power.interconnection_queue_isone', listing exactly what it describes: valid filters, groupings, metrics, detail fields, and citation fields. This distinguishes it from sibling describe tools for other regions.

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 this tool should be used to retrieve metadata before querying the corresponding data tool, but it does not explicitly state when to use it vs. alternatives or provide exclusion criteria.

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

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

Annotations already mark this as read-only and non-destructive. The description adds value by detailing exactly what metadata is returned (filters, groupings, etc.), providing behavioral context beyond the annotations.

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

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

The description is a single, front-loaded sentence that conveys all necessary information without redundancy. Every word contributes meaning.

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 describe tool with no parameters and an output schema, the description fully captures the tool's purpose. It is complete given the simplicity and available annotations/schema.

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

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

The tool has zero parameters, so per guidelines baseline is 4. No additional parameter information is needed.

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 explicitly states it describes valid filters, groupings, metrics, detail fields, and citation fields for a specific data source (power.interconnection_queue_nyiso). The verb 'describe' and resource are clear, and it distinguishes from sibling tools (other describe_ tools for different regions/datasets).

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

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

The description implies usage context: use this tool to learn about available filters and fields for the NYISO interconnection queue. No explicit when-not or alternatives are mentioned, but the sibling tools for other regions make the scope 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?

Annotations already declare the tool as read-only, idempotent, and non-destructive. The description adds context about the data source and the categories of information described (filters, groupings, etc.), but does not disclose additional behavioral traits such as authentication requirements, rate limits, or what happens if the dataset is unavailable. With annotations covering safety, the description provides moderate supplementary value.

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

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

The description is a single sentence that is concise and front-loaded with the key action. It clearly communicates the tool's output without extraneous words. However, it could be structured slightly better (e.g., listing categories more explicitly), but overall it is efficient and easy to parse.

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 no parameters, an output schema exists, and the description lists the categories of information it provides (filters, groupings, metrics, detail fields, citation fields), the description is complete enough for an agent to understand its purpose and output. No critical gaps remain.

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 coverage is 100%. The description does not explain parameter meanings (none exist), but it clarifies what the tool returns—valid filters, groupings, metrics, detail fields, and citation fields. This adds semantic value beyond the schema, aligning with the baseline of 4 for zero-parameter tools.

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 explicitly states the tool's purpose: to describe valid filters, groupings, metrics, detail fields, and citation fields for the power.interconnection_queue_pjm_cycle dataset. It uses a specific verb ('describe') and resource, and the name and title clearly differentiate it from siblings that describe other datasets or query 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 does not provide explicit guidance on when to use this tool versus alternatives (e.g., when to use describe vs. query, or when to use this specific dataset describe). While the sibling list implies it is for the PJM cycle dataset, there is no advice on prerequisites, ordering, or exclusions, leaving the agent to infer usage.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the description does not need to add much. It confirms the tool is for querying metadata, which is consistent. No additional behavioral details are needed.

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, concise sentence that front-loads the tool's purpose. Every word is essential, with no redundancy or 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?

Given zero parameters and the presence of an output schema, the description completely and accurately explains what the tool does. It leaves no ambiguity for an AI 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 input schema has zero parameters, so no parameter documentation is required. Schema coverage is 100%, and the description does not need to add parameter semantics. Baseline for 0 parameters is 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?

The description explicitly states it describes valid filters, groupings, metrics, detail fields, and citation fields for a specific resource (power.interconnection_queue_pjm). This clearly identifies the tool's purpose, and the naming distinguishes it from sibling tools for other regions.

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 the tool should be used to understand the schema of the PJM interconnection queue before querying. While it does not explicitly mention alternatives or when not to use it, the naming convention and context make it 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?

Annotations already indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds no further behavioral context, which is acceptable given the annotations cover safety and idempotency.

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

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

The description is a single, front-loaded sentence with no unnecessary words. It efficiently conveys the tool's purpose.

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

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

Given zero parameters, existing annotations, and an output schema, the description is sufficient. It could optionally mention that the tool provides metadata for query_* tools, but it is not required.

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 no parameters, so schema coverage is 100%. Following the baseline rule (0 params = 4), no additional parameter info is needed. The description correctly omits parameter details.

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 verb 'Describe' and specifies the resource 'power.interconnection_queue_spp', clearly identifying the tool's function. It distinguishes itself from sibling describe tools for other RTOs by explicitly naming SPP.

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 states what the tool does but does not provide explicit guidance on when to use it versus alternatives like the generic describe_power_interconnection_queue_v1. However, the name and context imply regional specificity.

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 no behavioral context beyond the annotations already provided (readOnlyHint, idempotentHint, destructiveHint). Annotations sufficiently indicate safe, idempotent behavior, so the description is neutral but not enhancing.

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, clear sentence front-loading the verb and resource. Every word is necessary, and there is no redundancy or fluff.

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

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

Given zero parameters, an existing output schema, and comprehensive annotations, the description fully informs the agent of what the tool returns (filters, groupings, etc.) and is sufficient for a describe tool in this ecosystem.

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

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

The tool has zero parameters, so the description cannot add meaning beyond the empty schema. Baseline is 4 per guidelines, and the description adequately covers that there are no parameters to describe.

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 explicitly states the tool 'describe valid filters, groupings, metrics, detail fields, and citation fields for power.interconnection_queue', clearly identifying the verb, resource, and scope. It distinguishes from sibling tools by the resource name and region (MISO) implied in the title.

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 explicitly state when to use this tool versus alternatives. Usage context is implied by the tool being a describe tool for a specific dataset, which is standard, but no explicit exclusions or prerequisites 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?

Annotations already declare readOnlyHint=true and idempotentHint=true, so the description adds context about the scope of what the tool describes (filters, groupings, etc.), which is consistent and helpful.

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

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

The description is a single sentence that is front-loaded and contains no unnecessary words. It efficiently communicates 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?

Given the low complexity (no parameters, output schema present), the description is complete. It covers what the tool does without needing to explain return values due to output schema.

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

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

The tool has zero parameters and 100% schema coverage, so the description adds no parameter info, which is appropriate. Baseline for 0 params is 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?

The description clearly states the tool describes valid filters, groupings, metrics, detail fields, and citation fields for the specific dataset power.price_ercot. It uses specific verbs and resource, and the sibling tools for other datasets make this one distinct.

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 explicitly state when to use this tool versus alternatives like query_power_price_ercot_v1 or other describe tools. Usage is implied (to get metadata before querying), but no exclusions or when-not context is 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the tool's safety profile is clear. The description adds value by specifying the exact types of information it returns (filters, groupings, etc.), though it does not elaborate on edge cases or output structure.

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

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

The description is a single sentence that clearly and efficiently conveys the tool's purpose without any wasted words. It is front-loaded and easy to scan.

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 that the tool has no parameters, has an output schema (which can explain return values), and the description explicitly lists the categories of information returned (filters, groupings, metrics, detail fields, citation fields), the description is complete enough for this simple metadata 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 no parameters, so the input schema is empty with 100% coverage. The description does not need to add parameter semantics, and the baseline score for zero parameters is 4. The description provides no additional parameter info, which is appropriate.

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

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

The description clearly states the tool's purpose: to describe valid filters, groupings, metrics, detail fields, and citation fields for a specific resource (power.retail_sales). This is a specific verb+resource pair, and it distinguishes itself from sibling describe tools by naming the resource explicitly.

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 as a metadata exploration tool before querying, but it does not explicitly state when to use this tool versus other describe tools for different datasets or when not to use it. No 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?

Beyond annotations (readOnlyHint, idempotentHint), the description reveals SHA-256 verification, no re-query behavior, and that it returns source-header row values, providing comprehensive behavioral context.

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 and front-loaded with the core action, but the middle sentence could be slightly more streamlined without losing clarity.

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 output schema existence, the description covers purpose, input, behavior, and use case adequately, though it omits error scenarios or limitations.

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 coverage, the description compensates by describing the expected input shapes (citation object from query tools) and giving concrete examples, though it does not detail all possible properties.

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 fetches and hash-verifies the raw source row behind a citation, differentiating it from sibling query/describe tools that provide aggregated or descriptive data.

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 explains when to use the tool ('prove an answer from the underlying source row') and how to obtain the input from query tools, but does not explicitly mention when not to use it or alternatives, though none are necessary.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, fully informing the agent this is a safe, idempotent read operation. The description adds that it lists capabilities, but no additional behavioral traits (e.g., response size, caching) are disclosed.

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 of 11 words, with no wasted text. It efficiently conveys purpose and 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 the tool has no parameters, has annotations covering safety and idempotency, and has an output schema (though its contents are unknown), the description provides sufficient context for a listing tool. It clearly states the tool's role in discovery before querying.

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 the baseline is 4. The description does not need to add parameter information, and it correctly omits 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 explicitly states the tool lists available exascale.build data capabilities, using a specific verb (list) and resource (capabilities). It clearly distinguishes from sibling describe/query tools which target specific data topics.

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 says 'for agent discovery before querying,' implying it should be used first to determine what data is available. However, it does not explicitly state when not to use it or mention alternatives, though the sibling tools naturally serve as alternatives for specific queries.

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 beyond annotations: data is monthly, start date, as_of vintage, non-additive nature, and meaning of the two basis types. These are critical for correct interpretation and are not in annotations.

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

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

The description is long but well-organized, front-loading purpose then diving into details. Every sentence adds value; no redundancy. Minor room for more concise phrasing but highly informative.

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?

Covers all necessary context: data source, available filters, grouping, output format (JSON with citations), citation details, exclusions, and important behavioral caveats (non-additivity). No gaps given the existence of an output schema.

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

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

The input schema has only a generic 'params' object with 0% coverage. The description fully compensates by listing all valid keys (category, basis, data_month, etc.), their allowed values, and usage examples with JSON examples.

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 it queries U.S. private construction spending for data centers and semiconductor plants from the Census C30 dataset. It distinguishes itself from sibling tools (e.g., power queries) by focusing on economic construction data.

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 tells when to use the tool (for construction spending questions) and what it does NOT cover (investment, capacity, location, etc.). Provides examples of correct query patterns and warns against invalid aggregations.

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 indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description goes far beyond by detailing suppression (withheld cells as NULL, not zero), non-additivity across levels/quarters, data vintage (back to 2014 Q1, ~6-month lag), and measures semantics. No contradictions.

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

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

The description is long but well-organized with a clear summary, usage instructions, parameter details, measures, supplements, and exclusions. Every sentence adds value; slight verbosity is justified by complexity. It is front-loaded with the main purpose.

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 (many parameters, behavioral rules, and an output schema), the description covers purpose, source, all parameter keys with values, suppression, additivity constraints, time range, and exclusions. It is complete without needing to describe return format due to output schema existence.

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%, but the description fully compensates by enumerating all valid parameter keys (industry_code, own_code, agglvl, state, etc.), explaining their values, giving examples, and specifying grouping and record inclusion. This is comprehensive 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 tool queries U.S. employment, establishments, and wages for data-center and semiconductor industries by geography from BLS QCEW. It specifies the verb, resource, scope, and source, and distinguishes from siblings like query_ai_infrastructure_construction_v1 by focusing on employment, not construction.

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

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

The description explicitly states when to use the tool (e.g., 'how many people work in...') and includes a dedicated list of what it does not determine (e.g., 'AI jobs', occupation detail, MSA figures). It provides clear context for appropriate use despite not naming siblings directly.

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?

Beyond annotations (readOnlyHint, idempotentHint), the description discloses key behaviors: imports only, no chip count, no state/county breakdown, preliminary months revised, customs value only, and the double-counting risk from overlapping groupings. This fully informs the agent of the tool's operational characteristics.

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 front-loaded with a clear summary and well-structured into usage, parameters, and caveats. While lengthy, every sentence adds value given the tool's complexity. Minor redundancy could be trimmed, but it is appropriately detailed.

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 parameters, grouping, citation mechanism), the description is fully complete. It covers return format (JSON aggregates with citations), data source, what is not provided, and how to re-verify via get_source_evidence_v1. The existence of an output schema does not reduce need for this 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?

With input schema having 0% description coverage, the description fully documents all parameters: country, cty_code, country_level, year, data_month, data_month_from/to, group_by, order_by, top_n, include_records. It explains their usage, values, nesting (flat keys), and provides explicit examples, compensating entirely for the bare 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 that the tool queries U.S. monthly imports of integrated circuits (HS-8542) with customs value by country of origin. It distinguishes from siblings like describe variants and explicitly notes it is NOT AI-accelerator/GPU-specific, ensuring correct tool selection.

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 explicit usage examples ('how much $ of chips did the US import') and warns against summing across country rows due to overlapping groupings. While it doesn't directly contrast with other query tools, it effectively clarifies when to use this tool and its limitations.

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 indicate readOnlyHint, idempotentHint, and non-destructive. The description adds significant behavioral context: automatic scope alignment, storage exclusion, nameplate basis, and explicit statements of what the tool does not determine. No contradiction with annotations.

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

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

Every sentence adds value, covering purpose, usage, parameters, behavior, and limitations. The description is dense but well-organized and front-loaded with key information.

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

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

With an output schema present, the description does not need to detail return values. It explains the calculation, scope, filters, and output components (capacity factor, generation, capacity, coverage, citation), making it complete for a complex analytical 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 a generic 'params' object with 0% coverage, but the description compensates by detailing actual parameters: data_month (required), optional group_by, state, fuel_group filters. This adds essential 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 the tool queries 'U.S. capacity factor' and explains the computation methodology using EIA-860M and EIA-923 data. It distinguishes itself from siblings like query_power_capacity_v1 and query_power_generation_v1 by focusing on capacity factor derived from both sources.

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 specifies that a data_month is required and provides guidance on handling missing month or errors, including not retrying blindly. It mentions optional parameters but does not explicitly compare usage against sibling tools for when to use this vs. others.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint. The description adds context: it returns JSON aggregates with citations and optional generator-level records, explains the lifecycle parameter, and clarifies there is no 'status' parameter. No contradictions with annotations.

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

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

The description is somewhat long but well-organized: it front-loads the main purpose, then details usage, exclusions, and alternatives. Every sentence adds value, though minor tightening could improve 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 output schema exists, the description explains the return format (aggregates with citations and optional records). It covers exclusions and alternatives comprehensively, making it complete for a complex filtering tool with many potential use cases.

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 with a single generic 'params' object. The description compensates by listing all valid filter dimensions (state, FIPS, balancing authority, fuel, etc.) and clarifying the lifecycle selector, providing essential 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 the verb (Query), resource (power capacity), source (EIA-860M), and lifecycle states (operating, planned, retired, canceled). It distinguishes from sibling tools like query_power_generation_v1 by explicitly listing what it does not determine, such as generation MWh or capacity factor.

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

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

The description provides explicit when-to-use guidance (capacity questions by state, FIPS, etc.) and when-not-to-use (does not determine electricity supplied, demand, prices, etc.). It also names alternative tools for interconnection queue queries, such as query_power_interconnection_queue_v1, making the choice 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?

The description discloses important behaviors beyond annotations: non-additivity of demand_mw, default to latest day, inverted additivity, handling of anomalies, and data history. No contradiction with annotations (readOnlyHint=true, etc.).

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

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

The description is long but well-structured, front-loading the core purpose, then providing examples and details. Every sentence adds value, though minor trimming could improve 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 tool's complexity and the presence of an output schema, the description is complete: it explains return format (JSON aggregates with citations), historical range, default behavior, and exceptions, leaving no critical 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?

Despite a generic input schema with no specific parameters, the description thoroughly documents all expected parameters (respondent, data_date, hour_number, group_by, etc.), their usage, and examples, fully compensating for the schema's lack of detail.

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 queries verified U.S. hourly electricity demand (MW) as EIA national and regional totals, and distinguishes itself from the sibling tool power.demand which does balancing-authority-level demand.

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

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

The description explicitly says when to use this tool ('how much load for the whole country, or a region') and provides clear alternatives for other use cases (e.g., 'use power.demand for the BA series').

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

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

Annotations already indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds significant context: returns JSON aggregates with citations, optional records, behavior for empty results (empty_scope note), handling of as_of for historical vintage, and details on demand_mw vs demand_mw_raw. No contradictions detected.

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 lengthy but dense with useful information. It is well-structured with a clear main purpose upfront, followed by specifics on filters, default behavior, and exclusions. Every sentence adds value, though some repetition could be trimmed. Minor redundancy exists (e.g., mentioning data_date multiple times).

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 single free-form parameter and its complexity (querying EIA-930 demand with many options), the description thoroughly covers filtering, grouping, default behavior, output structure (citations, records, notes), and exclusions. The output schema exists but the description adds necessary context on response fields and edge cases, making it 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?

The input schema has only one free-form 'params' object with 0% coverage. The description fully compensates by documenting acceptable filter/group fields (balancing_authority_code, region, data_date, etc.) and explaining field meanings (demand_mw as adjusted series, demand_forecast_mw as day-ahead forecast). It also covers defaults and edge cases, providing complete semantic guidance.

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 queries U.S. hourly electricity demand by balancing authority from EIA-930, specifying the resource, unit, and grain. It explicitly distinguishes from siblings by listing what it does not do (e.g., capacity, generation, retail sales, regional totals), making it highly specific and 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 provides explicit guidance: 'Use this for "how much load" questions at the hourly balancing-authority grain.' It details filterable fields and explains default behavior (latest day if no date range) and pitfalls (demand not additive across BAs). It also lists excluded use cases with tool alternatives, such as using power.capacity for installed capacity.

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 data history, as_of pinning, empty results behavior, and return format beyond annotations (which already declare readOnly, idempotent, and non-destructive). No contradiction with annotations.

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

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

Front-loaded with main purpose, but description is long and dense. Every sentence adds value, but could be more concise or broken into bullet points. Still well-structured.

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?

Covers all essential aspects: data source, filters, aggregation types, date limitations, return format, and exclusions. Sufficient for a complex query tool with open schema 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?

Input schema has 0% coverage (just a nullable object with additionalProperties). Description compensates fully by explaining filterable fields (state, fuel, plant, etc.) and parameter semantics (fuel_group vs. energy_source_code, atom options).

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 verb 'Query', resource 'U.S. monthly net electricity generation (MWh) from EIA-923', and scope. Distinguishes from siblings by listing what it does not do (capacity, demand, prices, etc.).

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 tells when to use (for 'how much was generated' questions) and when not to use (other power metrics). Provides detailed guidance on fuel_group vs. energy_source_code, atom selection, and balancing authority code date restriction.

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?

Beyond annotations (readOnly, idempotent, not destructive), the description discloses critical behaviors: net_mw_to_grid is requested capacity not built, most projects withdraw, CAISO does not provide a separate built-MW column, and the tool does not infer data-center types. No contradiction with annotations.

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

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

The description is long but well-structured: first paragraph outlines returned fields, second provides examples and caveats, third addresses pitfalls and alternatives. Every sentence adds value, though some rephrasing could tighten it slightly.

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 (one flexible param, no required fields, output schema exists), the description is complete. It covers filtering, grouping, returned data structure, important caveats, and cross-ISO comparisons.

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 thoroughly explains all parameter semantics: the flat params object, available filters (application_status, state, etc.), grouping via group_by array, and include_records flag. Provides concrete examples.

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 queries the CAISO generator interconnection queue. It specifies the resource (CAISO's Public Queue Report) and distinguishes it from sibling tools by naming alternatives for other ISOs and built capacity.

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 explicit guidance on when to use this tool vs alternatives, listing specific sibling tools for MISO, PJM, NYISO, ISO-NE, ERCOT, and SPP, and recommending query_power_capacity_v1 for built capacity. It also warns against using it for data-center load inference.

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?

Description adds extensive behavioral context beyond annotations: monthly snapshots, full history queryable, as_of behavior, derived application_status, and that the tool does not infer data-center-driven projects. No contradiction with annotations (readOnlyHint, idempotentHint all consistent).

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?

Though long, the description is front-loaded with core purpose and then structured with examples and warnings. Every sentence adds unique value, no wasted text. Conciseness is appropriate given complexity.

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 sheets, derived status, history, caveats), the description covers all necessary aspects: source, filters, behaviors, examples, and cross-references to sibling tools. Output schema exists but description explains return format adequately.

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% (only generic params object), but description fully compensates by detailing all valid parameters, their meanings, valid values (e.g., fuel codes), and how to structure queries with examples. Adds substantial meaning beyond 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 it queries the ERCOT generator interconnection queue, specifies the source (GIS Report), and lists return fields. It distinguishes from siblings by naming other ISO-specific tools, achieving a specific verb+resource+scope.

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

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

Explicitly says when to use this tool vs alternatives (e.g., use query_power_capacity_v1 for built capacity, lists other ISO queue tools). Provides usage examples and warns against interpreting requested capacity as built, meeting all criteria for explicit when/when-not/alternatives.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds substantial behavioral context: that MW are requested not built, the withdrawal dominance historical pattern, and the distinction between application_status and project_status. No contradiction with annotations.

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

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

The description is long but every sentence adds value. It is front-loaded with purpose and key details, then covers usage, warnings, and sibling references. Minor redundancy could be trimmed but overall well-organized.

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 complexity (many parameters, output schema, multiple ISOs, warnings), the description is complete. It covers the tool's function, output structure, parameter semantics, data interpretation caveats, and alternatives.

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?

Despite 0% schema description coverage, the description thoroughly explains parameter usage: flat top-level keys, available filter fields (application_status, request_type, state, etc.), date range filters, grouping, and the include_records toggle. Examples are provided.

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 it queries the ISO-NE generator interconnection queue, specifies the source (IRRT public queue), and distinguishes from sibling tools by naming other ISO-specific tools. It enumerates the 31 columns returned, demonstrating a precise verb+resource+scope.

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 explicit when-to-use and when-not-to-use guidance, including alternatives for other ISOs and for built/operating capacity (query_power_capacity_v1). It also warns against summing across ISOs and misinterpreting MW as installed capacity.

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 goes well beyond annotations by detailing data source, that returned MW are requested not built, project-rows granularity, as-reported Load Projects tab, and the need to use query_power_capacity_v1 for built capacity. No contradiction with annotations.

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

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

The description is lengthy but well-organized, front-loading the core action and then providing necessary details. While verbose, every sentence adds value given the tool's complexity; could be slightly tighter but remains 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 tool's many parameters, siblings, and the presence of an output schema, the description covers all essential aspects: filtering, grouping, field explanations, warnings, cross-references, and examples, leaving no gaps for an agent.

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

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

The schema is generic (one 'params' object with additionalProperties), but the description enumerates many specific parameters (application_status, sheet_name, type_fuel, etc.), their meaning, and usage examples, fully compensating for the 0% schema coverage.

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 queries the NYISO generator + load interconnection queue, distinguishing it from siblings by naming other ISOs. The verb 'query' and resource are explicitly defined.

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 explicit when-to-use (NYISO only) and when-not-to (never sum or dedupe across ISOs), lists alternative tools for other ISOs and for built capacity, and includes caveats like withdrawn-dominated nature.

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

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

Annotations already indicate read-only, idempotent, non-destructive. The description adds key behavioral context: returns cited records with source details, warns that requested MW are not built, and clarifies relationship to other tools. No contradictions.

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?

Description is verbose but well-structured with clear warnings and examples. Front-loaded with purpose. Some redundancy (lists sibling tools already provided in context) but overall effective for a complex tool.

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 (numerous parameters, multiple sibling tools, output schema present), the description covers all necessary aspects: what it returns, how to filter, relationships to other tools, and critical caveats about requested vs built capacity.

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?

Input schema has only a single open 'params' object with 0% property coverage, but the description exhaustively lists valid keys (cycle, stage, status, etc.), provides usage examples, and explains grouping/filtering. Fully compensates for schema 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 verb 'Query' and resource 'PJM cluster/cycle service-request grid', distinguishing it from the sibling full PJM queue tool and other ISO tools. It explicitly notes that this is a separate publication and should not be conflated.

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

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

Provides explicit when-to-use context: for cluster/cycle view of PJM. Warns against summing with other PJM tool or across ISOs. Includes example filters and grouping, and redirects to query_power_capacity_v1 for built capacity.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds critical context: data is cited with source information, requested MW are not built, majority withdraw, in_service_mw is separate, and the tool returns only PJM data. No contradictions.

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 well-organized with clear sections: query target, return fields, parameters, examples, warnings, and sibling differentiation. While long, every sentence adds value. Minor verbosity in listing all sibling tools could be trimmed slightly.

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 (many parameters, many siblings, output schema present), the description is thoroughly complete. It covers data fields, filtering, interpretation warnings, alternative tools, and even notes that PJM reports no data-center type. The output schema is present but the description adds necessary 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?

Input schema is generic (params object with additionalProperties true), but the description enumerates valid parameters (state, county_fips, status, etc.) with examples, fully compensating for 0% schema coverage. It also explains how to pass them as top-level keys and provides an example query.

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 queries the PJM New Services interconnection queue, specifies the region (mid-Atlantic RTO including specific states), and lists the returned data fields. It distinguishes from sibling tools by naming specific alternatives for other ISOs and the PJM cycle tool.

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 when to use (PJM queue), when not to use (not for built capacity, directs to query_power_capacity_v1), and lists alternatives for MISO, CAISO, NYISO, ISO-NE, ERCOT, SPP, and the PJM cycle tool. Also warns against summing across ISOs.

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 significant behavioral context beyond annotations: it explains the response structure (citations, as_of), data interpretation (requested vs installed), and limitations (no history, no deduplication). No contradictions.

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 comprehensive but verbose, with some repetition of warnings. It is well-structured into logical sections, but slightly longer than necessary.

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 (one free-form parameter, no required fields, rich output schema), the description covers all necessary aspects: parameter options, grouping, ordering, output format, domain context, and sibling differentiation.

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

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

The schema provides only a generic 'params' object with 0% description coverage. The description compensates fully by listing all valid keys (native_status, generation_type, etc.), their meanings, and examples, effectively documenting the free-form 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 that the tool queries the SPP generator interconnection queue, lists the data fields returned, and explicitly distinguishes from sibling tools for other ISOs, providing a specific verb and resource.

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 explicit when-to-use and when-not-to-use guidance, lists alternative tools for other ISOs, gives example parameter usage, and warns about interpreting capacity as requested not built.

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

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

Annotations already indicate read-only, idempotent, non-destructive. The description adds critical context: that data represents requested (not built) capacity, that majority of megawatts withdraw, and that MISO reports no data-center type. No contradiction with annotations.

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

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

The description is long but well-structured and front-loaded, with clear sections: purpose, return fields, filters, examples, warnings, and sibling disambiguation. Every sentence earns its place, though it could be slightly tighter without losing 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 complexity of the tool (multiple filter dimensions, output schema existence, warnings, sibling tools), the description covers all necessary aspects: what it does, parameters, return fields, caveats, and alternatives. It is 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?

The input schema has a generic 'params' object with no description. The description compensates fully by listing valid keys (state, county_fips, application_status, etc.), giving examples, and explaining that parameters are flat top-level keys. Without this, the schema is uninformative.

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 queries the MISO generator interconnection queue, lists the fields returned (megawatts, location, statuses, dates), and distinguishes it from sibling tools for other ISOs. The verb 'query' and the specific scope (MISO) are explicit.

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

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

The description explicitly states when to use (for MISO interconnection queue, requested capacity) and when not to use (not for built/operating capacity, not to combine across ISOs). It lists alternative sibling tools for other ISOs and for built capacity, guiding proper tool 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?

Annotations already indicate readOnlyHint, idempotentHint, destructiveHint. The description adds detailed behavioral context: defaults to latest day, history floor, no sum possible, and indicative averages across points. No contradictions.

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 lengthy but well-structured with clear sections, examples, and warnings. Every sentence adds value; slight reduction possible without losing clarity.

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?

Covers all aspects: filtering, grouping, output fields, unit interpretation, DST edge cases, and data lineage. Output schema is mentioned, reducing need for return value explanation.

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?

Input schema has only a generic 'params' object with 0% coverage. The description fully explains all possible fields (settlement_point, delivery_date, etc.), their meanings, and examples, compensating for schema gaps.

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 it queries ERCOT day-ahead wholesale electricity prices, specifying units ($/MWh), data source (EMIL NP4-190-CD), and settlement point types. It distinguishes from siblings like query_power_capacity_v1 and query_power_generation_v1.

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 tells when to use this tool (for ERCOT day-ahead prices) and when not to (for capacity/generation, other ISOs, or summing prices). Provides examples and warnings against blending across ISOs.

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?

Beyond annotations (readOnlyHint, idempotentHint, destructiveHint), the description details crucial behaviors: default exclusion of total sector, handling of sentinel rows, territory exclusion, service type mix in revenue sums, and the nuanced interplay between as_of and data_year. It also warns about empty results when misusing data_year.

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?

Despite its length, every sentence is purposeful and informative. The description is front-loaded with the core purpose and then systematically covers details, behaviors, exclusions, and examples. There is no redundancy or fluff.

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

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

The description covers all essential aspects: purpose, parameters, behaviors, limitations, return format (citations, optional records), and what the tool does not do. Given the tool's complexity and the presence of an output schema, it is 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?

The input schema has one parameter 'params' with 0% description coverage, but the description thoroughly lists and explains all valid fields (data_year, state, sector, etc.) and their defaults. This adds immense value beyond the bare 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 it queries verified U.S. annual retail electricity sales data from EIA-861, specifying the grain (utility×state×sector) and measures (billed MWh, revenue, customer counts). It distinguishes from siblings like query_power_demand by explicitly listing what it does NOT do, such as hourly or peak load.

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 explicit guidance on when to use this tool (e.g., 'who sold how much power to whom') and when not to use it (e.g., for hourly/peak load, facility-level, monthly data). It names alternative tools or capabilities, like power.demand for peak load, and explains default behaviors and parameter interactions.

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