Skip to main content
Glama

Emission Factors

by io.github.rozetyp
OverviewDiscussionsAdmin

plant_emissions

Read-only

Get emissions from EPA Clean Air Markets Division (CAMD) for a specific US power plant or a state: fossil units over 25 MW reporting to the Acid Rain Program and CSAPR. Per facility returns total CO2 (short tons), gross generation (MWh), heat input (mmBtu), NOx and SO2 (lb), primary fuel type, operating hours, and derived emissions rate (kg CO2/MWh). CAMD publishes by quarter, so the default window is the last 7 days of the latest published quarter (latest_published_date in the response); later dates are not available yet. Default output is a per-facility summary from daily data; format=hourly returns unit-hour records for small windows. Use for plant-specific carbon accounting, state-level fossil emissions and "dirtiest plants in [state]" queries.

Input Schema

NameRequiredDescriptionDefault
endNoCustom end date YYYY-MM-DD (optional, overrides days).
daysNoNumber of most recent days to include (1-90, default 7).
beginNoCustom begin date YYYY-MM-DD (optional, overrides days).
limitNoSummary only: return the top N facilities by CO2 (default 25); facilities_total gives the full count.
stateNoUS state (2-letter code or full name, e.g. TX or Texas) for a state-wide aggregate.
formatNo"summary" (default) aggregates by facility; "hourly" returns raw CAMD unit-hour records, about 0.8 KB each (a 9-unit plant-day was 172 KB), so use it with facility_id and 1-2 days.
facility_idNoEPA CAMD/ORIS facility code (e.g. 3 for Barry, AL). Find codes in the summary_by_facility of a state query, or at https://campd.epa.gov/.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / state / description
      Previous value: -"2-letter US state code for state-wide aggregate (e.g. TX, CA, PA)."New value: +"US state (2-letter code or full name, e.g. TX or Texas) for a state-wide aggregate."
  2. Changed1 schema field changed
    • changedInput schema / properties / format / description
      Previous value: -"\"summary\" (default) aggregates by facility; \"hourly\" returns raw records."New value: +"\"summary\" (default) aggregates by facility; \"hourly\" returns raw CAMD unit-hour records, about 0.8 KB each (a 9-unit plant-day was 172 KB), so use it with facility_id and 1-2 days."
  3. Changed1 schema field changed
    • addedInput schema / properties / limit
      Added value: +{
+  "description": "Summary only: return the top N facilities by CO2 (default 25); facilities_total gives the full count.",
+  "maximum": 500,
+  "minimum": 1,
+  "type": "integer"
+}
  4. First observed

TDQS

A4.6/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond readOnlyHint=true, the description discloses substantive behavior an agent cannot get from annotations: data availability is capped by the latest published quarter, later dates are unavailable, the default is the last 7 days of that quarter, and format=hourly returns large unit-hour records (with a concrete size example) that demand narrow windows. These are real operational constraints that shape how the tool should be called.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with what the tool does, followed by output contents, availability constraints, then formats and use cases. Every sentence carries information, though the single dense paragraph is longer than strictly necessary and the return-field list partially duplicates schema documentation.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description compensates by enumerating the return fields (CO2 in short tons, gross generation, heat input, NOx, SO2, primary fuel type, operating hours, derived kg CO2/MWh). Combined with the zero-required-parameter defaults and the publication-window caveat, an agent has everything needed to call it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3, but the description adds cross-parameter context the schema does not: the quarterly publication logic behind the days default, and how format=hourly should be paired with facility_id and 1-2 days. It also enumerates the returned measure set, which supports interpreting the facility-level parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Get emissions from EPA Clean Air Markets Division (CAMD)') and narrows the universe precisely: fossil units over 25 MW reporting to the Acid Rain Program and CSAPR. This distinguishes it cleanly from calculation siblings like calculate_emissions or calculate_fuel_emissions, which derive values rather than retrieve reported CAMD data.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Names concrete use cases ('plant-specific carbon accounting, state-level fossil emissions and "dirtiest plants in [state]" queries') and explains the default lookback window via the quarterly publication cadence. It does not explicitly say when to prefer a sibling (e.g., calculate_emissions) or when this tool is the wrong choice, so it stops short of a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Emission Factors toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources