One-line summary: This MCP server loads RMI's public Utility Transition Hub data into a local DuckDB database so any MCP client can explore U.S. utility emissions, generation, and climate alignment using natural language.
Discover the data — list_tables shows every table with column names, types, and row counts; preview_table shows sample rows so you can see the actual shape of a dataset.
Find utilities — list_utilities searches by two-letter state code or a case-insensitive name substring, returning utility/parent names, EIA and FERC1 IDs, RMI utility type, and in-state owned capacity (MW).
Track emissions — get_emissions_trend returns yearly CO2 (MMT), stated-target and IRP-projection emissions, the 1.5°C benchmark, plus generation (TWh) and emissions intensity, on a delivered, owned, or all accounting basis.
Break down generation — get_generation_mix shows capacity (GW), net generation (TWh), capacity factor, and CO2 by technology (Coal, Gas, Wind, Solar, Nuclear, Hydro, Storage, …); optionally include purchased power, exchanges, EE/DR, and transmission losses as separate rows.
Assess climate alignment — get_climate_alignment compares actual CO2 to RMI's 1.5°C pathway year by year, adding a gap column and status label; rank_climate_alignment ranks utilities or parents by distance from the pathway and flags which entities were excluded.
Run custom SQL — query_data executes read-only DuckDB SQL (one SELECT or WITH…SELECT per call) across emissions, generation, reliability, customers/sales, revenue, assets, debt/equity, and net plant tables, with documented join keys and double-counting traps.
Read the documentation — resources rmi://data-dictionary, rmi://data-dictionary-full (the full PDF), and rmi://methodology give field definitions, sources, assumptions, and calculations.
Use guided prompts — decarbonization_assessment, state_landscape, and investment_risk_profile structure common analyses.
Get consistent output — every tool returns the same envelope (rows, units, meta with grain/non_additive, notes, error) so you can tell whether rows double-count or columns must not be summed.
Answer typical questions — e.g. which utilities are furthest off the 1.5°C pathway, which Wisconsin utilities emit most, or how two utilities' generation mixes compare.
Caveat — it is an unaudited demo; results can be wrong and should be checked against the Utility Transition Hub and RMI methodology before use.
Loads RMI's public Utility Transition Hub data (utility emissions, generation mix, capacity, reliability, financials) into a DuckDB database, exposing tools to list/preview tables and run read-only DuckDB SQL queries against the data.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@RMI Utility Transition Hub — MCP Server Which Colorado utilities have the highest CO2 emissions?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
This MCP server loads RMI's public Utility Transition Hub data into DuckDB. Any MCP client can then query U.S. utility emissions, generation mix, and climate alignment with natural language.
This is a demo. Use it at your own risk.
This software is not audited, validated, or ready for production. The tools can return errors. The tools can also aggregate the data incorrectly, and a language model can interpret the results incorrectly.
Check every result against the Utility Transition Hub and the RMI methodology before you cite it, publish it, or make a decision with it. RMI does not endorse this tool. This tool has no affiliation with RMI.
pip install fastmcp duckdb pandas pymupdfOr use uv:
uv init rmi-mcp-uth
cd rmi-mcp-uth
uv add fastmcp duckdb pandas pymupdfDownload the data from the Utility Transition Hub. Extract the data into a data/ directory:
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 -q -o -j data_download_all_pt_1.zip
unzip -q -o -j data_download_all_pt_2.zip
rm data_download_all_pt_1.zip data_download_all_pt_2.zipnpx @modelcontextprotocol/inspector python server.pyThis command opens a browser interface. In the interface, you can call each tool, examine the resources, and monitor the protocol traffic.
The server uses the stdio transport, and any MCP client can connect to it. See your provider's documentation or ask your agent (e.g., Claude Code) to set it up.
Related MCP server: US ISO Grid MCP
Tool | What it does |
| Show all tables, columns, and row counts |
| Show sample rows from a table |
| Find utilities by state or name. The best matches come first. |
| Show CO2 emissions over time for a utility. |
| Show the generation breakdown by |
| Compare the actual CO2 to the 1.5°C pathway. |
| Rank utilities or parents by distance from the 1.5°C pathway. Excludes the utilities whose benchmark makes the comparison meaningless, and says which. |
| Run read-only SQL in DuckDB syntax |
Every tool returns the same envelope:
{
"rows": [{"utility_name": "Wisconsin Power & Light Co.", "year": 2024,
"owned_delivered": "delivered", "emissions_co2": 4.87}],
"units": {"emissions_co2": "MMT CO2"},
"meta": {"grain": ["utility_name", "year", "owned_delivered"],
"matched_utilities": ["Wisconsin Power & Light Co."]},
"notes": [{"kind": "projection", "message": "Rows at or after projected_from are ..."}],
"error": null
}Key | What it holds |
| The data. Every row has the same keys. Warnings and errors never appear here. |
| The unit of each column that has one. Columns absent from it are unitless. |
|
|
| Warnings that apply to the whole response. Each has a |
|
|
grain guards against counting the same row twice. Whether a column can be
added up at all is a separate question, answered by meta.non_additive — the
list of returned columns that must never be summed across rows. It is present
only when such a column is in the result.
Most entries are rates, and have to be recomputed from the two totals
underneath them rather than added: co2_intensity_kg_mwh, capacity_factor,
pct_over, saidi, bill, burden. But do not infer non-additivity from the
unit — capacity_owned_in_state is plain MW and still must not be summed,
because RMI's figure runs several times above the utility's ownership share and
adding it across a state's utilities exceeds that state's real capacity. Read
non_additive, not the unit string.
URI | Description |
| A summary of the datasets, columns, and units |
| The full data dictionary PDF. It gives the definitions, sources, and methodology for each field. |
| The RMI methodology document. It gives the data sources, assumptions, and calculations. |
Prompt | Description |
| Analyze the climate progress of a utility |
| Show an overview of the utilities in a state |
| Show the financial exposure of a utility to fossil fuel assets |
"Which US utilities are furthest off the 1.5°C pathway?"
"Which Wisconsin utilities have the highest CO2 emissions?"
"Compare Alliant Energy and Xcel Energy's generation mix"
"Show me Wisconsin Power & Light's emissions trend since 2015"
"Is Alliant Energy on track for 1.5°C, or is WEC Energy Group closer?"
"What share of Wisconsin generation comes from renewables?"
Delete utility_hub.duckdb and restart the server. The server builds the database again from the CSV files.
RMI licenses the Utility Transition Hub data under 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.
Natural-language queries over a verified emissions knowledge graph, plus standards validation
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.
