Skip to main content
Glama

Query Power Capacity Factor

query_capacity_factor_v1
Read-onlyIdempotent

Query verified U.S. capacity factor — how hard a fleet actually runs — by joining EIA-860M capacity and EIA-923 generation.

Requires data_month: one ISO month start, e.g. "2026-01-01". If the user names no month, ask which one (or state the month you chose); if a month is not covered, the error lists the months that are — do not retry blindly.

capacity_factor = net generation (MWh) / (operating nameplate capacity (MW) × hours in the month), computed over plant×fuel present in BOTH sources, so scope is auto-aligned. Optional group_by of state and/or fuel_group, and state/fuel_group filters. Returns the capacity factor per group with its generation and capacity, a coverage declaration (what share of in-scope capacity/generation matched), and a citation to BOTH the capacity and the generation source row. Basis is nameplate; storage is excluded; the capacity snapshot is matched to the month. Does not determine per-generator capacity factor, a net-summer/winter basis, or months absent from either source.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
paramsNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

TDQS

A4.8/5.0
Behavior5/5

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

The description richly discloses behavior beyond the readOnly/idempotent annotations: the exact formula, auto-aligned scope from both sources, nameplate basis, storage exclusion, month-matched snapshot, coverage declaration, citation to both source rows, and explicit non-capabilities. This is far more than the annotations alone provide.

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

Conciseness5/5

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

The description is dense but well-organized: purpose, required input, formula, optional parameters, return values, and limitations. Every sentence adds useful detail, and there is no fluff or repetition of trivial information.

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

Completeness5/5

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

Given the sophisticated multi-source calculation and minimal schema, the description covers all necessary aspects: input format, computation scope, returned outputs, error behavior, and boundaries. The presence of an output schema means it does not need to enumerate every return field, but it still summarizes what to expect.

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

Parameters5/5

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

The input schema is an opaque `params` object with zero property documentation, so the description carries the entire burden. It explicitly documents `data_month` with format and example, optional `group_by` values, and `state`/`fuel_group` filters, making the parameters fully understandable.

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

Purpose5/5

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

The description starts with a clear verb-resource pair ('Query verified U.S. capacity factor') and immediately explains the computation: joining EIA-860M capacity and EIA-923 generation. It distinguishes itself from sibling tools like describe_capacity_factor_v1 by emphasizing the querying/computation nature and the specific data sources, even without naming alternatives explicitly.

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

Usage Guidelines4/5

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

The description gives concrete usage guidance: requires `data_month`, tells the agent to ask for a month if absent, warns against blind retries on uncovered months, and describes optional grouping/filtering. It does not explicitly say 'use this instead of X when...' but provides clear operational context and lists limitations that imply when not to use it.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4/5.0
Disambiguation4/5

Each capability has a clearly named describe/query pair, and domains like power, AI infrastructure, robotics, and space are distinct. The generic describe_capability_v1/query_capability_v1 could be confused with the named variants, and the many ISO-specific interconnection queues share similar names, but descriptions explicitly disambiguate them.

Naming Consistency5/5

All tools follow a consistent lowercase snake_case verb_noun pattern: describe_<capability>_v1 and query_<capability>_v1, with a few utility tools like list_capabilities_v1 and get_source_evidence_v1. There is no mixing of conventions.

Tool Count2/5

At 62 tools, the set is far too large for typical server scope. The describe/query pairs inflate the count even though each is justified, and the generic capabilities plus per-ISO variants make it feel heavy and hard to navigate.

Completeness4/5

The server covers each domain thoroughly with describe, query, and evidence verification, plus generic fallbacks for capabilities not yet in the client's tool list. Minor gaps exist (e.g., no county/state attribution for some data, no load types in ISO queues) but they are explicitly documented and workable.

Resources