A
licenseNot graded
qualityNot graded
maintenanceProvides access to comprehensive U.S. and international energy data from the EIA API, including electricity, natural gas, petroleum, coal, renewables, CO2 emissions, and energy forecasts.
PowerGridIQ
Officialby powergridiq
PowerGridIQ MCP server
Exposes the PGIQ Rating as tools any MCP-capable agent (Claude Desktop, Claude Code, Cursor,
custom agents) can call: "where should I site or schedule a large electricity load, and how is a
given market rated." It wraps the read-only REST API at https://powergridiq.com/api/v1, covering
67 global power markets with a reasoned, cited decision, not just raw feeds.
Tools
pgiq_markets- list every rated market (id, tier, score, outlook). Start here.pgiq_rating(market)- full five-pillar rating + evidence for one market (e.g.quebec).pgiq_best(lens?, group?, min_tier?, limit?)- the ranked best-market decision.lensisdefault|cost|carbon|momentum.pgiq_developments(market?)- recent cited grid developments.pgiq_grid(market)- grid snapshot: carbon intensity, price, fuel mix, demand, firm headroom, peak stress. Merges live signals where available, else a clearly labelled modelled baseline.pgiq_cheapest_window(market?)- cheapest hours to run a flexible load (modelled daily price shape, local time). Omitmarketfor the cheapest grids ranked.
Related MCP server: MCP Energy Hub
Install & run
cd pgiq-mcp
npm install
node index.js # speaks MCP over stdioConfigure in Claude Desktop
Add to claude_desktop_config.json (Settings → Developer → Edit Config):
{
"mcpServers": {
"powergridiq": {
"command": "node",
"args": ["/absolute/path/to/pgiq-mcp/index.js"],
"env": { "PGIQ_KEY": "pk_live_optional_key_for_higher_limits" }
}
}
}Restart Claude Desktop, then ask things like "Use PowerGridIQ to find the best carbon-light market for a 100 MW AI cluster in Europe" or "What's the PGIQ rating for Ireland and why?"
Authentication & limits
No key needed for the free tier: 100 requests/day per IP.
For a higher monthly quota, set
PGIQ_KEY=pk_live_...(developer 25,000/mo, pro 500,000/mo). Request a key at hello@powergridiq.com.Override the API base with
PGIQ_APIif needed.
Notes
The rating is a directional screen, not a connection guarantee; the interconnection queue is the real gate. Every market carries a confidence level, treat lower confidence with more caution.
Live grid signals, rating-change webhooks, and metered keys are available now; short-horizon forecasts are next.
A hosted remote MCP server (no local install) is planned; for now this runs locally via stdio.
Links
API spec: https://powergridiq.com/openapi.json
Agent map: https://powergridiq.com/llms.txt
Developer page: https://powergridiq.com/build
Available Tools
6 toolspgiq_bestA
Get a ranked best-market decision for siting or scheduling a large electricity load (data center, AI cluster, industrial load). Re-weights the five pillars under a lens and returns the top markets with a one-line rationale. This is the decision endpoint.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| lens | No | Weighting lens. 'default' is carbon-light (hyperscaler/AI). 'carbon' favors clean grids, 'cost' favors cheap power, 'momentum' favors proven build-out. | |
| group | No | Optional region filter. | |
| limit | No | Max results (default 5). | |
| min_tier | No | Only return markets at this tier or better (1=best, 5=worst). |
TDQS
A3.9/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description mentions re-weighing pillars and returning rationale, but does not disclose whether the tool is read-only, requires authentication, or has any side effects. More behavioral context would be helpful.
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?
Three sentences, under 50 words, front-loaded with main purpose, efficient and no superfluous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has 4 parameters and no output schema. Description explains the purpose and lens mechanism but omits details on output format, pagination behavior (limit), tier definitions (min_tier), and error handling. Could be more thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (baseline 3). The description adds meaningful context for the 'lens' parameter by explaining the re-weighing of pillars. Other parameters (group, limit, min_tier) are not elaborated beyond schema, so minor added value.
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?
Description clearly states the tool 'Get a ranked best-market decision for siting or scheduling a large electricity load', specifies the resource (markets), and distinguishes it as the 'decision endpoint' from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is the final decision tool but does not explicitly state when to use it versus alternatives like pgiq_rating or pgiq_cheapest_window. No prerequisites 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.
pgiq_cheapest_windowA
The cheapest hours to run a flexible load. With a market, returns its typical daily price shape and cheapest window; without one, returns the cheapest grids ranked by trough price. Modelled daily shape, not a real-time forecast.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| market | No | Optional market id. Omit for the cross-market ranking. |
TDQS
A4.1/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that the result is a 'modelled daily shape, not a real-time forecast' and explains the two modes. This adds significant value beyond the input schema.
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?
Three sentences, no fluff. First sentence clearly states purpose, next two add necessary details. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Description explains modes and warns it's a model, but does not define 'cheapest window' precisely (e.g., number of hours) or describe output format. No output schema exists to compensate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (market parameter has description). Description adds behavioral context: 'With a market, returns its typical daily price shape and cheapest window; without one, returns the cheapest grids ranked by trough price.' This goes beyond the schema.
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 clearly states the tool returns 'the cheapest hours to run a flexible load', with specific behaviors for with/without a market parameter. It distinguishes itself from siblings (e.g., pgiq_best, pgiq_markets) by focusing on cheapest window for load scheduling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context (flexible load scheduling) and explains behavior based on market presence, but does not explicitly mention when to use this tool over siblings or provide alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
pgiq_developmentsA
Recent dated, cited grid developments (moratoria, tariffs, queue reforms, big builds) across markets, newest first. Optionally filter to one market.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| market | No | Optional market id to filter to. |
TDQS
A4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses ordering ('newest first') and optional filtering, adding value beyond the schema. However, it does not mention data freshness, limits, or the meaning of 'cited', leaving some behavioral traits unspecified.
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?
Two sentences with no redundancy. Every word contributes to explaining purpose and optional filter. Highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter and no output schema, the description covers purpose, ordering, and filtering. It lacks details on output structure or pagination, but is sufficient for basic use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline 3. The description's mention of 'optionally filter to one market' restates the schema description without adding new semantics. No enrichment of parameter meaning.
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 clearly states the tool provides recent dated, cited grid developments (moratoria, tariffs, queue reforms, big builds) across markets, sorted newest first. It specifies an optional filter, distinguishing its purpose from sibling tools like pgiq_best or pgiq_grid.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (to get recent developments) but does not explicitly state when not to use or suggest alternatives. No exclusions or context for alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
pgiq_gridB
Grid snapshot for one market: carbon intensity (gCO2/kWh), price, fuel mix, demand, firm headroom and peak stress. The inputs for carbon- and cost-aware scheduling.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| market | Yes | Market id, e.g. 'quebec'. |
TDQS
B3.4/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Does not disclose behavioral traits such as data freshness, read-only nature, idempotency, rate limits, or side effects. Only lists returned metrics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. First sentence enumerates what the tool provides; second states use case. Could be slightly more scannable with bullet points but overall concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given only one parameter and no output schema, the description lists key metrics but not the output structure or format. For complex data like fuel mix and peak stress, more detail would be helpful. Adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with one parameter 'market' described as 'Market id, e.g. 'quebec'.' The tool description adds no extra information about the parameter beyond the schema, so baseline score of 3 applies.
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?
Clearly states it provides a grid snapshot for one market, listing specific metrics (carbon intensity, price, fuel mix, demand, etc.). Differentiates from siblings by focusing on a single market and listing unique data points.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies use for scheduling decisions ('The inputs for carbon- and cost-aware scheduling'), but does not explicitly state when to use this tool versus alternatives like pgiq_best or pgiq_cheapest_window. No when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
pgiq_marketsA
List every rated power market with its PGIQ tier (1 Prime to 5 Largely closed), 0-100 score, and outlook. Start here to discover market ids.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
A4.5/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must handle behavioral disclosure. It clearly indicates a read-only listing operation with no side effects. For a simple listing tool, this is adequate, though it could mention that no authentication or rate limits apply.
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 two sentences, completely front-loaded with the action and result. Every word serves a purpose, with a clear directive ('Start here') that guides usage. No wasted language.
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 no parameters and no output schema, the description fully covers what the tool does and what it returns. It also provides a usage hint for discovering market IDs, which is essential for context with sibling tools. Complete for this simple listing tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, so schema description coverage is 100% trivially. However, the description adds meaning by explaining that the tool returns a list of markets with tier, score, and outlook, which is not captured in the empty schema. This adds value for an agent.
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 clearly states the verb 'List' and the resource 'every rated power market', specifying the returned attributes (PGIQ tier, 0-100 score, outlook). It also explicitly differentiates from siblings by noting this is the starting point to discover market IDs, which is a unique purpose.
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 explicitly says 'Start here to discover market ids', which implies this tool should be used first to obtain market IDs for other tools like pgiq_best or pgiq_rating. While it doesn't explicitly state when not to use it or mention alternatives, the context is clear and sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
pgiq_ratingA
Get the full PGIQ Rating and evidence for one market: five-pillar scores (access, availability, cost, momentum, carbon) with rationale, tier, outlook, confidence, thesis, peers, sources, and the latest rating action. Use for a deep read on a specific market.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| market | Yes | Market id, e.g. 'quebec', 'ercot', 'ireland'. Use pgiq_markets to list ids. |
TDQS
A4.2/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It details the output content (five-pillar scores, rationale, tier, etc.) but does not explicitly state read-only behavior, auth requirements, or error handling. The description adds value but could be more transparent about behavioral traits beyond what is implied.
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 two sentences, front-loaded with the core purpose, and contains no extraneous information. Every sentence earns its place, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 parameter, no output schema), the description covers the purpose, input, and output components. It could improve by briefly noting the return structure (e.g., a JSON object with specified fields), but it is mostly complete for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (one parameter 'market'). The description adds examples ('quebec', 'ercot', 'ireland') and references pgiq_markets for listing IDs, which provides meaningful semantic guidance beyond the schema's minimal description.
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 clearly states the verb 'Get' and the resource 'full PGIQ Rating and evidence for one market', listing specific components like five-pillar scores and rationale. It distinguishes from siblings by emphasizing a deep read on a specific market, while siblings like pgiq_markets cover listing or other views.
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 includes the explicit phrase 'Use for a deep read on a specific market', providing clear context for when to invoke this tool. It does not explicitly mention when not to use or list alternatives, but the context is sufficient for an AI agent to infer appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
TDQS
A4.2/5.0
Disambiguation5/5
Each tool has a clearly distinct purpose: market discovery (pgiq_markets), deep rating analysis (pgiq_rating), grid snapshot (pgiq_grid), cheapest hours (pgiq_cheapest_window), recent developments (pgiq_developments), and decision recommendation (pgiq_best). No overlapping functionality.
Naming Consistency5/5
All tool names follow a consistent pattern: lowercase prefix 'pgiq_' followed by a descriptive noun or noun phrase using underscores (e.g., pgiq_cheapest_window, pgiq_developments). No mixing of conventions.
Tool Count5/5
With 6 tools, the server is well-scoped for its purpose of providing electricity market intelligence for large loads. Each tool serves a distinct function without unnecessary bloat or deficiency.
Completeness5/5
The tool set covers the full workflow: discover markets (pgiq_markets), get deep ratings (pgiq_rating), view current grid conditions (pgiq_grid), find cheapest scheduling windows (pgiq_cheapest_window), stay informed on developments (pgiq_developments), and get a ranked decision (pgiq_best). No obvious gaps for the stated domain.
Maintenance
ActivitySlowing
ResponsivenessSyncing
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Live and historical electricity prices and demand for 25 grids; carbon intensity for GB.
Live U.S. electric-grid data, forecasts, alerts, and analysis across major grid regions.
Real-time electricity price signals for AI agents. Spot prices, cheapest hours, and contract recommendations. 31 countries across Europe and Oceania. No authentication required.
Real-time electricity prices for AI agents. 40+ countries, 100+ zones. No auth required.
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceProvides real-time US power grid intelligence and carbon intensity data to enable carbon-aware AI compute scheduling across major grid regions. It allows users to monitor energy generation and optimize workloads based on renewable energy availability and grid load forecasts.2MIT
- AlicenseAqualityDmaintenanceProvides access to Danish energy data from Energinet, including real-time electricity spot prices, CO2 emissions, and production mix. It enables users to monitor grid status and identify the most cost-effective hours for energy-intensive tasks.415MIT
- FlicenseNot gradedqualityDmaintenanceMCP server for real-time electricity prices, carbon intensity, and energy analytics across 41+ zones in Europe, Great Britain, the United States, and Australia. Query live prices, compare zones, check gas storage levels, get green scores, find optimal charging windows, and access advanced analytics. Free Basic tier requires no API key. Install via npx gridpulse-mcp or connect directly via Streamab
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/powergridiq/pgiq-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server