RMI가 공개한 Utility Transition Hub 데이터를 DuckDB에 로드하는 MCP 서버입니다. 모든 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 pymupdfUtility 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이 명령을 실행하면 브라우저 UI가 열리며, 각 도구를 호출하고 리소스를 탐색하고 프로토콜 트래픽을 검사할 수 있습니다.
이 서버는 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를 사용하면 git에 커밋되어 협업자와 공유되는 .mcp.json 파일이 작성됩니다:
claude mcp add rmi-mcp-uth --scope project -- uv --directory /absolute/path/to/rmi-mcp-uth run server.py연결을 확인하세요:
claude mcp listrmi-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
도구 | 기능 |
| 모든 테이블, 열, 행 수 표시 |
| 모든 테이블의 샘플 행 표시 |
| 주(state)별 유틸리티 검색 |
| 유틸리티의 시간 경과에 따른 CO2 배출량 |
| technology_rmi별 발전 구성 |
| 실제 CO2와 1.5°C 경로 비교 |
| 읽기 전용 SQL 실행 (DuckDB 구문) |
URI | 설명 |
| 모든 데이터셋, 열, 단위 요약 |
| 전체 데이터 사전 PDF (필드별 정의, 출처, 방법론) |
| RMI의 방법론 문서 (데이터 출처, 가정, 계산) |
프롬프트 | 설명 |
| 유틸리티의 기후 진행 상황에 대한 전체 분석 |
| 한 주(state) 내 모든 유틸리티 개요 |
| 유틸리티의 화석 연료 자산에 대한 재정적 노출 |
"어느 콜로라도 유틸리티가 CO2 배출량이 가장 높나요?"
"Xcel Energy의 지난 10년간 배출량 추이를 보여줘"
"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.
