PowerGridIQ

Official

by powergridiq

Overview Schema Related Servers Score Discussions

JavaScript

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.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.
Average 4/5 across 6 of 6 tools scored. Lowest: 3.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 4 commits in the last 12 weeks
- Last stable release on July 4, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
View related servers

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

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.
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.
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.
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.
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.
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![pgiq-mcp MCP server](https://glama.ai/mcp/servers/powergridiq/pgiq-mcp/badges/card.svg)](https://glama.ai/mcp/servers/powergridiq/pgiq-mcp)

Score Badge

Copy to your README.md:

[![pgiq-mcp MCP server](https://glama.ai/mcp/servers/powergridiq/pgiq-mcp/badges/score.svg)](https://glama.ai/mcp/servers/powergridiq/pgiq-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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