energy-permitting-tracker

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

With no annotations, the description carries the full behavioral burden. It does describe what the returned detail contains and that it is for one project, but it does not disclose error behavior, authentication needs, rate limits, or field availability caveats. This is adequate but not rich.

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

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

Two short sentences: the first front-loads the tool's purpose and return scope, and the second gives the exact prerequisite. There is no filler or duplication.

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

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

For a single-parameter, no-output-schema tool, the description is complete enough: it explains what the return value includes, how to obtain the required slug, and the scope of a single project. Nothing critical is missing for an agent to call this tool correctly.

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

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

Schema coverage is 100% and the single parameter's schema description already says it is a project slug '"as returned by search_projects."' The tool description repeats the same guidance without adding new parameter-specific semantics, so the baseline of 3 applies.

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

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

Description states a specific operation: fetch full detail for exactly one WaitingForPower project by slug, and enumerates the included content (cited sources, milestone timeline, capacity, estimated investment waiting). This clearly distinguishes it from the list/search siblings such as search_projects and get_stats.

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 tells the agent to obtain the slug from search_projects first, establishing a clear prerequisite and workflow. It implies this tool is for a single project's full detail, though it does not enumerate when-not-to-use alternatives beyond that sequencing.

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

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

With no annotations, the description carries full responsibility for behavioral disclosure. It does disclose what the tool returns and that it supports optional scoping, which is meaningful. But it does not mention output format, default filter behavior (e.g., status defaulting to 'in_permitting'), or whether results are returned as a single object, so coverage is adequate but not rich.

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 one compact, front-loaded sentence that names the result metrics before the scoping option. Every clause earns its place and there is no repetition of schema details 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?

For a read-only aggregate tool with seven fully documented optional parameters, the description supplies the output metrics and scoping relationship to search_projects. Without an output schema, it could note the return shape or default scoping more explicitly, but an agent can still invoke the tool correctly based on the information given.

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

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

Schema description coverage is 100%, so the input schema already fully documents all seven parameters. The description adds only the high-level note that filters match search_projects, which is useful context but not additional parameter-level semantics. Baseline 3 is appropriate.

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

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

The description states a specific verb ('get'), a specific resource (aggregate numbers for the WaitingForPower dataset), and lists the exact metrics returned: project count, capacity waiting, clean-energy capacity waiting, and estimated investment waiting. It also distinguishes itself from search_projects by framing this tool as the aggregate counterpart to that filterable search 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?

The phrase 'optionally scoped by the same filters as search_projects' clearly signals that this tool is for aggregate statistics rather than project-level lookup and ties it to the sibling search tool. However, it does not explicitly state when to prefer this tool over search_projects or provide exclusions, so it falls just short of fully explicit 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?

With no annotations provided, the description carries the full disclosure burden, and it does well: it reveals the tool returns a fixed, non-dynamic set, lists all seven members, and notes each comes with a neutral description. It does not state the output format explicitly, but the behavioral nature of this read-only taxonomy lookup is clearly conveyed.

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?

Everything fits in one sentence with the key fact (fixed set) front-loaded before the enumeration. The long parenthetical list is valuable because it names every category the agent will receive; no sentence is wasted.

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

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

For a zero-parameter, no-output-schema, no-annotation tool, the description is nearly complete: it names every returned value and indicates each has a neutral description. The only residual gap is the exact return structure (e.g., array of objects with id/name/description fields), but the tool's simplicity keeps this minor.

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

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

The schema has zero parameters, so there is nothing to document; baseline 4 applies. The description sensibly focuses on the return content rather than inputs, and the empty schema confirms no arguments are required.

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

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

The description states a specific verb (list) and resource (the fixed set of delay cause categories) and enumerates exactly what the set contains. It clearly distinguishes itself from sibling list tools like list_policies and list_states by naming the full taxonomy of structural bottleneck categories.

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?

Usage is implied: this is the canonical taxonomy every tracked project's delay maps to, so an agent can infer it should be called to obtain the delay-category vocabulary. However, there is no explicit when-to-use guidance or contrast with sibling reference tools such as list_policies and list_states.

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

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

No annotations are provided, so the description carries the behavioral disclosure burden. It discloses the nature of the output (six proposals, each with specified components) and the important framing that this is an argued position rather than neutral content. This gives the agent useful context about what kind of information to expect.

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

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

The description is two sentences long with no filler. The first sentence states what the tool returns and the structure of each item; the second sentence immediately clarifies the key distinction from list_causes. Every word earns its place.

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

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

For a zero-parameter, no-output-schema tool, the description is fully sufficient. It states the number of proposals, their framing, the per-item fields, and how this tool differs from the most relevant sibling. An agent can confidently invoke this tool without further clarification.

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

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

The tool accepts zero parameters and the schema coverage is 100%, so there are no parameter semantics to explain. The description appropriately focuses on the fixed output and contextual meaning instead of irrelevant 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 clearly identifies a specific verb/action (list), a concrete resource (WaitingForPower's six bipartisan permitting-reform policy proposals), and the content structure (summary, strengths, weaknesses, related bills). It also explicitly distinguishes this tool from the sibling list_causes, making its purpose immediately clear.

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

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

The description gives clear context on what this tool offers and explicitly contrasts it with list_causes, telling the agent that list_policies returns the site's argued position while list_causes returns neutral categories. It does not discuss usage relative to other siblings, but the distinction is sufficient for the main alternative.

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

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

With no annotations provided, the description carries the full burden. It discloses what the tool returns (codes and names) and that these values feed other tools' state filters, but it stays silent on ordering, whether USPS territories are included, and what 'tracked projects' means for membership in the list — minor gaps for a trivial read-only lookup.

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 that front-loads the output content and closes with the operational purpose. Every word earns its place, and the title adds the scope qualifier ('with tracked projects') without redundancy.

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

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

For a zero-parameter tool with no output schema or annotations, the definition is nearly complete: an agent knows what comes back (state codes and full names), for which states (tracked projects), and why to call it. The only gap is the unspecified return shape (object vs. plain list), which is a minor issue for a tool this simple.

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

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

The tool has zero parameters, so the schema (an empty object) conveys nothing; the baseline is 4. The description adds the cross-tool hint that these values are consumed as the `state` filter in other tools, giving the no-argument invocation a clear purpose.

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 title 'List states with tracked projects' supplies a specific verb and resource, and the description names the exact output content: 'USPS state codes and full names'. This clearly differentiates list_states from sibling reference listers list_causes and list_policies, which cover different entities.

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 its use context explicitly: the output is 'usable as the `state` filter in other tools,' which tells an agent when to call it (when it needs valid state filter values). It doesn't name alternatives or exclusions, but for a zero-parameter static reference tool, the condition for use is essentially self-evident.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It does disclose that results are a paginated summary and that full detail lives elsewhere, but it doesn't mention pagination response shape, ordering, limits, or any access/error behavior. It is adequate but not richly transparent.

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

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

Two sentences, front-loaded with purpose and dataset scope, and ends with a useful routing hint. Every phrase earns its place; 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?

The description covers dataset scope, filtering context, and the relationship to get_project. However, there is no output schema and the description only says 'paginated summary' without describing what fields each result contains or how pagination is represented, leaving an important gap for a 9-parameter search tool.

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

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

Schema description coverage is 100%, so the baseline is 3. The description doesn't add parameter-specific detail, but none is needed because every parameter already has a meaningful schema description.

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

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

The description identifies a specific resource (WaitingForPower U.S. energy projects waiting on permitting) and a clear verb (search). It also contrasts with get_project by mentioning that full detail requires that sibling tool, so an agent can distinguish the two.

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

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

It clearly states this tool is for searching and returning paginated summaries, and explicitly routes to get_project for full detail. It doesn't enumerate exclusions for the other list_* siblings, but the core search-vs-detail decision is unambiguous.

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