Un servidor MCP que carga los datos públicos del Utility Transition Hub de RMI en DuckDB. Cualquier cliente MCP (Claude Code, Claude Desktop) puede consultar las emisiones de las empresas de servicios públicos de EE. UU., la combinación de generación y la alineación climática mediante lenguaje natural.
pip install fastmcp duckdb pandas pymupdfO con uv:
uv init rmi-mcp-uth
cd rmi-mcp-uth
uv add fastmcp duckdb pandas pymupdfDescarga los datos del Utility Transition Hub y extráelos en un directorio data/ junto a server.py:
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.pyEsto abre una interfaz de navegador donde puedes llamar a cada herramienta, explorar los recursos e inspeccionar el tráfico del protocolo.
El servidor utiliza transporte stdio. Cualquier cliente MCP puede conectarse a él. A continuación se muestran las configuraciones para Claude Code y Claude Desktop.
Si usas uv, apunta el cliente a uv y deja que resuelva el entorno. Sin uv, apúntalo a un python que tenga las dependencias instaladas y usa una ruta absoluta en ambos casos.
Añade el servidor con la CLI:
claude mcp add rmi-mcp-uth -- uv --directory /absolute/path/to/rmi-mcp-uth run server.pyO, sin uv:
claude mcp add rmi-mcp-uth -- python /absolute/path/to/server.pyPor defecto es un servidor local: disponible solo para ti, en el directorio desde el que ejecutaste el comando. Usa --scope user para que esté disponible en todos los proyectos, o --scope project para escribir un archivo .mcp.json que se incluya en git y se comparta con los colaboradores:
claude mcp add rmi-mcp-uth --scope project -- uv --directory /absolute/path/to/rmi-mcp-uth run server.pyVerifica la conexión:
claude mcp listDeberías ver rmi-mcp-uth: ... - ✔ Connected. Dentro de una sesión, /mcp lista las herramientas, los recursos y los prompts del servidor. Los prompts aparecen como comandos de barra (/mcp__rmi-mcp-uth__decarbonization_assessment), y los recursos se pueden adjuntar con @rmi-mcp-uth:rmi://data-dictionary.
Para eliminarlo: claude mcp remove rmi-mcp-uth.
Añade esto al archivo de configuración de 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"]
}
}
}O, sin uv:
{
"mcpServers": {
"rmi-mcp-uth": {
"command": "python",
"args": ["/absolute/path/to/server.py"]
}
}
}Reinicia Claude Desktop. Aparecerá un icono de martillo en el cuadro de mensaje. Haz clic en él para ver tus herramientas.
Related MCP server: US ISO Grid MCP
Herramienta | Qué hace |
| Muestra todas las tablas, columnas y recuentos de filas |
| Muestra filas de ejemplo de cualquier tabla |
| Encuentra empresas de servicios públicos por estado |
| Emisiones de CO2 a lo largo del tiempo para una empresa de servicios públicos |
| Desglose de la generación por technology_rmi |
| Compara el CO2 real con la trayectoria de 1.5°C |
| Ejecuta SQL de solo lectura (sintaxis de DuckDB) |
URI | Descripción |
| Resumen de todos los conjuntos de datos, columnas y unidades |
| PDF del diccionario de datos completo (definiciones, fuentes y metodología por campo) |
| Documento de metodología de RMI (fuentes de datos, supuestos y cálculos) |
Prompt | Descripción |
| Análisis completo del progreso climático de una empresa de servicios públicos |
| Panorama general de todas las empresas de servicios públicos de un estado |
| Exposición financiera de la empresa de servicios públicos a activos de combustibles fósiles |
"¿Qué empresas de servicios públicos de Colorado tienen las mayores emisiones de CO2?"
"Muéstrame la tendencia de emisiones de Xcel Energy durante la última década"
"Compara la combinación de generación de Duke Energy y Southern Company"
"¿Qué empresas de servicios públicos están más lejos de la trayectoria de 1.5°C?"
"¿Qué proporción de la generación de las empresas de servicios públicos de EE. UU. proviene de energías renovables?"
Elimina utility_hub.duckdb y reinicia el servidor. Se reconstruye automáticamente a partir de los archivos CSV.
Los datos de RMI Utility Transition Hub están bajo la licencia 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.
