osint
Server Details
Agent-ready US power data: capacity, generation, capacity factor (EIA), cited to source.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.5/5 across 8 of 8 tools scored.
Each tool targets a distinct operation: describe tools help discover available parameters, query tools retrieve specific data types (capacity factor, capacity, generation), and get_source_evidence verifies citations. No overlap exists.
Consistent verb_noun pattern with _v1 suffix (describe_, query_, list_, get_). Minor variation: 'get_source_evidence' uses 'get' while other queries use 'query', but structure is uniform.
8 tools is ideal for this domain: discovery, querying three data types, and source verification. No clutter, no gaps.
Covers discovery, query, and verification for the three data categories. Missing batch querying (e.g., multiple months) but core workflows are complete.
Available Tools
8 toolsdescribe_capacity_factor_v1Describe Power Capacity FactorARead-onlyInspect
Describe capacity factor: net generation / (operating nameplate × hours), joined across EIA-860M and EIA-923.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description adds value by detailing the calculation and data joins beyond stating it's read-only. 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?
Single, dense sentence with no wasted words. Conveys formula, data sources, and purpose efficiently.
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 fully explains what the tool returns and its meaning, 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?
No parameters exist and schema coverage is 100%, so the description need not explain parameters. It provides useful context about the tool's 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 description clearly states the tool describes capacity factor with the exact formula and data sources, distinguishing it from likely query variants like query_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?
No guidance on when to use this tool versus its siblings, such as when to describe versus query or list. The description lacks explicit usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
describe_power_capacity_v1Describe Power CapacityARead-onlyInspect
Describe valid filters, groupings, metrics, detail fields, and citation fields for power.capacity.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, so the description adds value by specifying exactly what the output contains (valid filters, groupings, etc.). This context goes beyond the annotations without contradicting them.
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 enumerates all relevant categories of fields. 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 the tool has no parameters and an output schema exists, the description fully captures the tool's purpose. It explains what the tool describes without needing further detail.
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 trivially 100%. Per guidelines, baseline is 4. The description does not add parameter-level meaning but clarifies the tool's overall output, which is acceptable for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('describe') and resource ('power.capacity') and lists the categories of information it provides (filters, groupings, metrics, detail fields, citation fields). This clearly distinguishes it from sibling tools that describe other resources (e.g., capacity_factor, 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?
While the description does not explicitly state when to use this tool versus alternatives, the context implies it should be used before query_power_capacity_v1 to understand valid parameters. The clarity of the purpose makes the usage straightforward, but explicit guidance is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
describe_power_generation_v1Describe Power GenerationARead-onlyInspect
Describe valid filters, groupings, atoms, metrics, detail fields, and citation fields for power.generation.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds value beyond the readOnlyHint annotation by specifying the exact categories of output (filters, groupings, etc.). 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?
Single sentence, front-loaded with the verb 'Describe', no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and an output schema, the description fully covers what the tool does and what it returns.
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 baseline 4. The description adds no parameter info, but none are 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 clearly states that the tool describes valid filters, groupings, atoms, metrics, detail fields, and citation fields for power.generation. It distinguishes from sibling describe tools (e.g., describe_capacity_factor_v1) which describe other 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 implies usage context: before using query_power_generation_v1, one might need this describe tool to know valid parameters. However, it does not explicitly state when not to use or list alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_source_evidence_v1Get Source EvidenceARead-onlyInspect
Fetch and hash-verify the raw source row behind a returned citation.
Pass a citation object inside params. Two ready-to-pass shapes come straight from
the query tools: each aggregate row's citations[ref].verify object, or a detail
record's citation (from include_records). Either proves the number with no
re-query. The tool verifies the raw workbook SHA-256 before returning source-header
row values. Use this when an agent must prove an answer from the underlying source row.
| Name | Required | Description | Default |
|---|---|---|---|
| params | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond readOnlyHint annotation, description details SHA-256 verification and return of source-header row values, providing behavioral context 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?
Three sentences, each adding value: purpose, input shapes, usage scenario. No extraneous 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?
Description covers primary usage and verification, but does not detail the exact structure of source-header output; however output schema likely covers that, so it's adequate.
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% and parameter schema is minimal (anyOf object/null), but description compensates by explaining that 'params' expects a citation object and lists two specific shapes from query 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 uses specific verb 'Fetch and hash-verify' and resource 'raw source row', clearly distinguishing from sibling tools that describe or query capacities and 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?
Explicitly states 'Use this when an agent must prove an answer' and mentions two alternative input shapes from query tools, guiding when to use and implying when not needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_capabilities_v1List CapabilitiesARead-onlyInspect
List available exascale.build data capabilities for agent discovery before querying.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description adds context that it lists capabilities for discovery, reinforcing safe read-only behavior. 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?
Single sentence, front-loaded with action and purpose. No unnecessary words; every part adds 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?
The description is complete for a zero-parameter, read-only tool with a clear purpose. Output schema exists but is not needed to understand the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has no parameters, so the description does not need to provide parameter details. Baseline of 4 is appropriate given 100% schema coverage and no extra description 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 clearly states it lists available data capabilities for agent discovery before querying. It uses a specific verb ('list') and resource ('capabilities'), and distinguishes itself from sibling tools which are individual query/describe tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It specifies 'for agent discovery before querying,' indicating primary use case. It does not explicitly state when not to use or name alternatives, but the sibling list makes it clear that this is the entry point tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
query_capacity_factor_v1Query Power Capacity FactorARead-onlyInspect
Query verified U.S. capacity factor — how hard a fleet actually runs — by joining EIA-860M capacity and EIA-923 generation.
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. Pass a single data_month (required); 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.
| Name | Required | Description | Default |
|---|---|---|---|
| params | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description details the exact formula, scope alignment, exclusions (storage), and basis (nameplate). 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 well-structured with a clear opening, then details, then exclusions. At ~150 words, it is informative but slightly long; could be tightened without losing content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool joining two sources, the description covers all necessary aspects: formula, scope, optional parameters, output fields (capacity factor, coverage, citation), and exclusions. It provides a complete picture.
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% coverage with a generic params object, but the description adds meaning by naming and describing the parameters: data_month, optional group_by, and state/fuel_group filters. This compensates 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 verb ('Query'), resource ('U.S. capacity factor'), and explains the computation. It distinguishes itself from sibling tools like query_power_capacity and query_power_generation by specifying the join and metric.
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 input requirements (data_month required, optional group_by and filters) and lists what the tool does not do (per-generator CF, net-summer/winter basis). It lacks explicit when-not-to-use guidance but overall provides clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
query_power_capacity_v1Query Power CapacityARead-onlyInspect
Query verified U.S. generator-level operating, planned, retired, or canceled power capacity from EIA-860M.
Use this for capacity questions by state/jurisdiction, county FIPS,
source-reported balancing authority code, fuel, prime mover, technology, status,
or year. Pass filters inside the params object. Returns JSON aggregates with
citations and optional generator-level records when include_records is true.
Does not determine electricity supplied, generation MWh, real-time dispatch,
capacity factor, battery storage throughput/duration, demand/load, prices,
queues, data-center load, or transmission deliverability.
| Name | Required | Description | Default |
|---|---|---|---|
| params | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond the readOnlyHint annotation by stating it returns 'JSON aggregates with citations and optional generator-level records when include_records is true.' It also transparently lists limitations (e.g., not for electricity supplied, real-time dispatch). 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 paragraph of 6 sentences, front-loading the core action. Every sentence adds value, though it could be slightly more structured (e.g., bullet points for exclusions). It is not verbose and earns its length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (open-ended params, many filters) and the presence of an output schema, the description adequately covers return behavior (aggregates + optional records) and lists excluded capabilities. It does not detail error handling or parameter structure, but the filter list provides sufficient guidance for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description compensates by explaining that filters are passed inside the `params` object and enumerating possible filter criteria (state, county FIPS, balancing authority code, fuel, etc.). It also mentions the 'include_records' flag, adding meaning that the schema alone does not provide.
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. generator-level power capacity from EIA-860M, specifying the verb 'query' and the exact resource. It distinguishes itself from sibling tools by listing what it does NOT determine (e.g., generation MWh, capacity factor), making its scope 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 explicitly tells when to use the tool: 'for capacity questions by state/jurisdiction, county FIPS, ...' and lists what it does not cover, implicitly guiding away from inappropriate uses. While it does not name specific sibling alternatives, the exclusion list effectively differentiates it from tools like query_power_generation_v1.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
query_power_generation_v1Query Power GenerationARead-onlyInspect
Query verified U.S. monthly net electricity generation (MWh) from EIA-923.
Use this for "how much was generated" questions by state, source-reported balancing
authority code, fuel, prime mover, sector, plant, or generator, for a given month.
For a fuel total or a fuel mix (e.g. "coal generation", "top fuels"), filter or group
by fuel_group — it sums the several energy_source_code values a fuel spans (coal
alone is 6 codes), so a total is correct-by-construction; use the raw energy_source_code
only when you want one exact as-reported code, since it splits coal/biomass across
sub-codes. Select one atom: by_fuel (default — the complete plant total) or
by_generator (generator-level, joinable to EIA-860M); never sum across atoms. Pass
filters inside the params object. Returns JSON aggregates with citations down to the
exact source month-cell. Does not determine installed capacity (MW — use power.capacity),
demand/load, wholesale prices, fuel cost, heat rate, capacity factor, or
real-time/hourly dispatch.
| Name | Required | Description | Default |
|---|---|---|---|
| params | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the agent knows it's read-only. The description adds that it returns 'JSON aggregates with citations down to the exact source month-cell' and explicitly states what it does not determine (capacity, demand, etc.). This provides valuable 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 paragraph but quite long (over 100 words). Every sentence adds value, but it could be slightly more concise. The structure is logical, starting with the main purpose, then usage details, then exclusions.
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 a query tool with multiple filter dimensions, the description covers the essential behavior, including the crucial nuance between fuel_group and energy_source_code, atom selection, and what is excluded. With an output schema present, it doesn't need to detail return format, but it does mention it briefly.
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 loosely-typed 'params' object with 0% description coverage. However, the description compensates by explaining that filters are passed inside params and lists possible dimensions (state, fuel, etc.) and the 'atom' parameter (by_fuel vs by_generator). This adds meaning significantly 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 it queries 'U.S. monthly net electricity generation (MWh) from EIA-923'. It specifies the verb (query), resource (power generation), and scope (U.S., monthly, verified source). It distinguishes from sibling tools like query_power_capacity_v1 and describe_capacity_factor_v1 by explicitly listing what it does not do.
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 (for 'how much was generated' questions) and when not to (for capacity, demand, prices, etc.). It gives detailed advice on using fuel_group vs energy_source_code and atom selection, and names alternative tools for other purposes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!