一个 MCP 服务器，用于将 RMI 的公开 Utility Transition Hub 数据 加载到 DuckDB。任何 MCP 客户端（Claude Code、Claude Desktop）都可以通过自然语言查询美国公用事业的排放、发电结构和气候对齐情况。
pip install fastmcp duckdb pandas pymupdf或者使用 uv：
uv init rmi-mcp-uth
cd rmi-mcp-uth
uv add fastmcp duckdb pandas pymupdf从 Utility Transition Hub 下载数据，并将其解压到 server.py 旁边的 data/ 目录中：
mkdir data
cd data
curl -LO https://utilitytransitionhub.rmi.org/static/data_download/data_download_all_pt_1.zip
curl -LO https://utilitytransitionhub.rmi.org/static/data_download/data_download_all_pt_2.zip
unzip data_download_all_pt_1.zip
unzip data_download_all_pt_2.zipnpx @modelcontextprotocol/inspector python server.py这会打开一个浏览器界面，你可以在此调用每个工具、浏览资源并检查协议流量。
服务器使用 stdio 传输。任何 MCP 客户端都可以连接它。下面提供了 Claude Code 和 Claude Desktop 的配置。
如果你使用 uv，请将客户端指向 uv，让它解析环境。如果没有 uv，请将其指向已安装依赖的 python，并且在两种情况下都使用绝对路径。
使用 CLI 添加服务器：
claude mcp add rmi-mcp-uth -- uv --directory /absolute/path/to/rmi-mcp-uth run server.py或者，不使用 uv：
claude mcp add rmi-mcp-uth -- python /absolute/path/to/server.py默认情况下，这是一个 local 服务器：仅对你可用，并且仅在你运行命令的目录中可用。使用 --scope user 使其在每个项目中可用，或使用 --scope project 写入一个 .mcp.json 文件，该文件会提交到 git 并与协作者共享：
claude mcp add rmi-mcp-uth --scope project -- uv --directory /absolute/path/to/rmi-mcp-uth run server.py验证连接：
claude mcp list你应该看到 rmi-mcp-uth: ... - ✔ Connected。在会话中，/mcp 会列出服务器的工具、资源和提示。提示以斜杠命令（/mcp__rmi-mcp-uth__decarbonization_assessment）的形式出现，资源可以通过 @rmi-mcp-uth:rmi://data-dictionary 附加。
要移除它：claude mcp remove rmi-mcp-uth。
将此添加到你的 Claude Desktop 配置文件中：
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
{
"mcpServers": {
"rmi-mcp-uth": {
"command": "uv",
"args": ["--directory", "/absolute/path/to/rmi-mcp-uth", "run", "server.py"]
}
}
}或者，不使用 uv：
{
"mcpServers": {
"rmi-mcp-uth": {
"command": "python",
"args": ["/absolute/path/to/server.py"]
}
}
}重新启动 Claude Desktop。消息框中会出现一个锤子图标。点击它即可查看你的工具。
Related MCP server: US ISO Grid MCP
工具 | 说明 |
| 显示所有表、列和行数 |
| 显示任意表的示例行 |
| 按州查找公用事业 |
| 某个公用事业随时间变化的 CO2 排放 |
| 按 technology_rmi 划分的发电结构 |
| 将实际 CO2 与 1.5°C 路径进行比较 |
| 运行只读 SQL（DuckDB 语法） |
URI | 描述 |
| 所有数据集、列和单位的摘要 |
| 完整的数据字典 PDF（每个字段的定义、来源和方法） |
| RMI 的方法文档（数据来源、假设和计算） |
提示 | 说明 |
| 对公用事业气候进展的完整分析 |
| 某个州内所有公用事业的概览 |
| 公用事业对化石燃料资产的财务敞口 |
"科罗拉多州哪些公用事业的 CO2 排放量最高？"
"显示 Xcel Energy 过去十年的排放趋势"
"比较 Duke Energy 和 Southern Company 的发电结构"
"哪些公用事业偏离 1.5°C 路径最远？"
"美国公用事业发电中可再生能源占多少比例？"
删除 utility_hub.duckdb 并重新启动服务器。它会自动从 CSV 文件重建。
RMI Utility Transition Hub 数据采用 CC BY 4.0 许可。
Compare a utility's emissions to RMI's 1.5°C pathway, year by year.
Adds a gap column (CO2 minus the 1.5°C benchmark: positive = above the pathway) and a status label. Historical years use reported CO2; future years fall back to the utility's stated target, then its IRP projection.
basis is "delivered" (default), "owned", or "all" — see get_emissions_trend.
The search is case-insensitive and supports partial names.
| Name | Required | Description | Default |
|---|---|---|---|
| basis | No | delivered | |
| utility_name | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It discloses the calculation logic (historical years use reported CO2, future years fall back to targets/IRP projections), the gap column formula, and case-insensitive partial-name search. This is substantial behavioral context beyond what the schema shows.
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 appropriately sized and well-organized: purpose first, then output/calculation details, then parameter conventions. Every sentence adds useful information and there is no filler or 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?
The description covers the essential behavioral and parameter details needed to invoke the tool correctly. It does not describe the output schema, but an output schema exists, so that is not a gap. It is slightly weaker on explicit sibling differentiation but still contextually complete for the tool itself.
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 0%, so the description must compensate. It explains the 'basis' parameter's allowed values and default, and it clarifies that 'utility_name' supports partial and case-insensitive matches. This adds real meaning over the raw 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 states a specific action and resource: 'Compare a utility's emissions to RMI's 1.5°C pathway, year by year.' It clearly distinguishes this from sibling tools by focusing on the RMI benchmark and the added gap/status columns, so an agent can identify its unique function.
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 context, such as referencing get_emissions_trend for basis definitions, but it does not explicitly state when to use this tool versus sibling alternatives or when not to use it. Usage guidance is implied by the purpose rather than spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get yearly CO2 emissions and 1.5°C pathway comparison for a utility.
Returns historical CO2 (MMT), emissions implied by the utility's stated targets, its IRP projection, and RMI's 1.5°C benchmark — plus generation (TWh) and emissions intensity (metric tons/MWh).
basis selects the accounting boundary and MUST be one of:
"delivered" (default) — emissions behind the power the utility sells
"owned" — emissions from generation the utility owns
"all" — both, distinguished by the owned_delivered column
The two bases are separate row sets; never sum across them.
The search is case-insensitive and supports partial names.
| Name | Required | Description | Default |
|---|---|---|---|
| basis | No | delivered | |
| utility_name | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so well: it discloses returned quantities with units, explains that the basis parameter selects separate row sets ('never sum across them'), and specifies that search is case-insensitive and supports partial names. It also clarifies the meaning of the 'owned_delivered' column for basis='all'.
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 main purpose is front-loaded and the remaining sentences each add functional value: outputs, units, basis semantics, row-set warning, and search behavior. The basis values are presented in a scannable list format that is easy for an agent to parse.
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 two-parameter tool with an output schema, this description tells the agent everything needed to call it correctly: what data comes back, units, boundary choices, a warning about summing across bases, and name matching behavior. The only notable omission is sibling comparison, which is already covered under usage guidance.
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 0%, so the text must explain the parameters, and it does. 'basis' is fully documented with its three allowed values, defaults, and accounting meaning; the description also clarifies utility_name behavior via case-insensitive partial matching. No parameter is left semantically opaque.
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 opens with a specific action and object — 'Get yearly CO2 emissions and 1.5°C pathway comparison for a utility' — and enumerates the exact outputs (CO2, targets, IRP projection, RMI benchmark, generation, intensity), which makes the tool's role clear. It does not explicitly draw boundaries against siblings like get_generation_mix or get_climate_alignment, so some differentiation is left to inference.
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 use case is implied by the detailed output list, and the basis options tell the agent how to choose accounting scope. However, no guidance is given about when to prefer this tool over the overlapping sibling tools, and there are no when-not-to-use conditions or alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get electricity generation breakdown by technology for a utility.
Shows capacity (GW), net generation (TWh), capacity factor, and CO2 emissions (MMT) by RMI technology group (Coal, Gas, Wind, Solar, Nuclear, Hydro, Storage, ...).
By default this covers only generation the utility OWNS. The underlying table also carries non-owned energy_source rows — wholesale power purchases, net exchanges, wheeled power, energy efficiency, demand response, and negative transmission losses. Those are supply, not generation, and summing them together with owned output overstates the fleet and mixes in negative rows. Set include_purchases=True to get them as separate rows, split by the energy_source and owned_energy_source columns.
The search is case-insensitive and supports partial names. Optionally filter to a single year; defaults to all years (2005-2024).
| Name | Required | Description | Default |
|---|---|---|---|
| year | No | ||
| utility_name | Yes | ||
| include_purchases | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does so excellently. It discloses the ownership default, the existence and risk of non-owned rows, the behavior of include_purchases, case-insensitive partial-name search, and the default year range. It even warns about the overstatement pitfall from mixing purchased supply with owned generation.
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 front-loaded with the core purpose and output metrics, then logically progresses through the ownership default, caveat about non-owned rows, and optional parameters. Every sentence adds necessary operational detail, and the structure makes the information easy to scan.
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 data-retrieval tool with an output schema. It covers defaults, edge cases, parameter behavior, and the important conceptual distinction between generation and purchased supply. Nothing needed for correct invocation is missing.
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 0%, but the description compensates by explaining all three parameters: utility_name supports case-insensitive partial matches, year is optional and defaults to all years 2005-2024, and include_purchases is thoroughly described with its effect on row splitting and columns. This adds substantial meaning beyond the bare schema types and defaults.
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 opens with a specific verb and resource: 'Get electricity generation breakdown by technology for a utility.' It also names the output metrics (capacity, net generation, capacity factor, CO2 emissions) and technology groups, making it clearly distinguishable from siblings like get_emissions_trend and get_climate_alignment.
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 guidance on the default owned-generation scope and explains exactly when to set include_purchases=True. It does not explicitly name alternative tools or state when not to use this tool, but the context it provides is sufficient for most selection decisions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all tables with their column names and types.
Call this first to understand what data is available before querying.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the operation and an ordering hint, but does not explicitly confirm this is a read-only metadata operation, mention permissions, or note any rate limits or side effects. The agent must infer safety.
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 with the core function front-loaded and the usage hint second. There is no filler, redundancy, or unnecessary detail.
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 discovery tool with an output schema, the description covers what the tool does and when to call it. It is slightly incomplete in not contrasting with sibling tools, but overall it is sufficient given the tool's simplicity.
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 and an empty input schema with 100% coverage. No parameter documentation is needed, so the 0-params baseline of 4 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?
The description clearly states the verb ('List') and resource ('all tables') with specific output detail ('column names and types'). This distinguishes the tool from data-returning siblings like preview_table or query_data by focusing on schema metadata, though it does not name any alternative.
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 sequencing guidance: 'Call this first to understand what data is available before querying.' This tells the agent when to use the tool in a workflow, but it does not mention when not to use it or contrast with alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List utilities, optionally filtered by two-letter state code (e.g. 'CO', 'TX').
Returns utility and parent names, EIA/FERC1 IDs, RMI utility type, and — when
a state is given — the capacity that utility owns in that state (MW), largest
first. name_contains additionally filters on utility or parent name
(case-insensitive substring).
Use this to find the right utility name before pulling emissions or generation data.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| state_abbr | No | ||
| name_contains | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It discloses what is returned, that capacity only appears when a state is given, that results are ordered by capacity largest first, and that name_contains is case-insensitive. It does not mention limit behavior or pagination, but for a read-only list tool the key behaviors are 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?
The description is tight and front-loaded: main function first, return details second, usage guidance last. Every sentence adds useful information and there is no redundant phrasing.
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 simple list utility with an output schema, the description is nearly complete: filters are explained, the conditional return field is described, and the intended workflow is stated. The only real gap is the undocumented limit parameter and the resulting size/behavior of the response.
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 0%, so the description must compensate. It explains state_abbr with examples and the conditional capacity output, and explains name_contains with case-insensitive substring semantics. However, the limit parameter is not mentioned at all, leaving one of three parameters undocumented.
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 and resource ('List utilities') and goes beyond the name by detailing the returned fields (utility/parent names, EIA/FERC1 IDs, RMI type, capacity). It also distinguishes itself from emission/generation tools by positioning this as the lookup step before pulling that data.
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 a clear use case: 'Use this to find the right utility name before pulling emissions or generation data.' It also explains the optional filtering behavior. However, it does not explicitly name sibling alternatives or state when not to use this tool, so it stops short of full when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show the first few rows of a table to understand its structure.
Use this after list_tables to see what the actual data looks like.
| Name | Required | Description | Default |
|---|---|---|---|
| rows | No | ||
| table_name | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the behavioral burden. It conveys a read-only preview behavior and a row limit via 'first few rows', but does not disclose whether column types/headers are included or any output caps beyond the default, leaving gaps.
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 tight sentences with the primary behavior first followed by a concrete usage hint. No filler or repetition.
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 simple preview tool with an output schema, the description covers purpose and a usage scenario, but remains thin on parameter semantics and alternative tools. It is adequate but not rich enough to fully guide an agent without additional inference.
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 0% and the description does not name or explain the rows parameter or explicitly map table_name to a tool argument. It only tangentially implies table via 'a table', which is insufficient compensation.
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 action (show first few rows of a table) and its goal (understand structure). This clearly distinguishes it from siblings like list_tables, which lists table names, and query_data, which performs arbitrary queries.
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 explicitly instructs to use the tool after list_tables, giving a clear sequence. However, it does not mention when to prefer query_data over this tool for more complex data exploration, so it lacks explicit when-not/alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a read-only SQL query against the database. DuckDB SQL syntax.
Call list_tables() first to see available tables and columns. One SELECT statement per call (a leading WITH ... CTE is fine).
There is no single join key across all tables: utility_id_eia — utility_information, utility_state_map, operations_emissions_by_tech / _by_fuel, reliability utility_id_ferc1 — utility_information, customers_sales, revenue_by_tech, assets_earnings_investments, debt_equity_returns, net_plant_balance respondent_id — expenditure_bills_burden, housing_units_income only emissions_targets has NO id column; join it on utility_name_irp / parent_name. utility_name and parent_name appear in most tables directly.
Two traps worth knowing:
emissions_targets holds separate 'owned' and 'delivered' row sets —
filter owned_delivered or you double-count.
operations_emissions_by_tech mixes owned generation with purchased
power, exchanges, EE/DR, and negative transmission losses —
filter owned_energy_source for generation only.
Example: SELECT utility_name_irp, year, emissions_co2_historical, emissions_co2_1point5c FROM emissions_targets WHERE year >= 2015 AND owned_delivered = 'delivered' ORDER BY emissions_co2_historical DESC LIMIT 20
| Name | Required | Description | Default |
|---|---|---|---|
| sql | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It clearly states the operation is read-only, limits each call to one SELECT statement, reveals join-key incompatibilities, and warns about the owned/delivered row-set and generation/purchased-power mixing traps. These are meaningful behavioral disclosures beyond a generic 'run a query.'
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?
Although long, the description is tightly organized: purpose, prerequisite, constraints, join-key reference, known traps, and an example. No sentence is wasted; the density is justified by the complexity of the database schema.
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 complex multi-table schema and existing output schema, the description is remarkably complete. It identifies all relevant tables, join keys, the table that lacks an ID, and both data-quality traps. It also delegates table/column discovery to list_tables() rather than trying to inline the full schema.
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 the only parameter is an undocumented 'sql' string. The description fully compensates by defining acceptable syntax, query structure, join constraints, required filters, and providing a concrete example. An agent can confidently construct a correct SQL value from this guidance.
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 opens with a specific verb and resource: 'Run a read-only SQL query against the database.' It also clarifies the SQL dialect (DuckDB), immediately distinguishing this general-purpose query tool from the specialized sibling get_* and table-inspection 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?
The description gives strong usage guidance: call list_tables() first, one SELECT per call, CTEs allowed, join-key mapping per table, and filter traps to avoid double-counting. It does not explicitly compare this tool to specialized siblings like get_emissions_trend, so the 'when vs alternatives' guidance is slightly implicit rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0get_climate_alignmentget_emissions_trendget_generation_mixlist_tableslist_utilitiespreview_tablequery_dataScored across 7 tools
list_tables, preview_table, list_utilities, and get_generation_mix are clearly distinct, but get_emissions_trend and get_climate_alignment both promise yearly CO2 emissions versus a 1.5°C pathway. The detailed descriptions help, but an agent could easily pick the wrong one.
Most tools follow a get_/list_ + noun pattern, which is predictable. preview_table and query_data deviate slightly, but they still read naturally and fit the overall exploration-oriented convention.
Seven tools is well-scoped for a domain-specific utility data hub. Each tool has a clear role, and the count is neither bloated nor too thin.
The surface covers data discovery, table preview, utility lookup, standard analytical queries, and raw SQL for arbitrary exploration. There are no obvious dead ends for a read-only analysis server.
US power plant, generation, price, curtailment and water data, with sources on every result.
Query your org's data in natural language — read-only MCP access to SQL, NoSQL, files & warehouses.
Live US power market prices, load, generation, weather and permits for AI agents.
Protocol-native energy infrastructure orchestration for AI data centers. Provides 46 MCP tools across 8 grid protocols (IEC-61850, DNP3, Modbus, OCPP, OpenADR, IEEE 2030.5, IEC 60870-5-104, ICCP) with 5 core API primitives: connect, dispatch, settle, comply, and intel. Enables AI agents to programmatically interact with substations, grid interfaces, and energy assets for real-time workload-grid coordination.
