This MCP server gives LLMs live access to Australian electricity market data (AEMO NEMWEB), covering spot prices, demand, generation, interconnector flows, rooftop PV, and forecasts.
Query current or historical data with get_data for 7 curated NEM datasets, filtering by region, fuel, interconnector, unit, and time windows.
Get latest values instantly with latest — e.g. current NSW spot price, QLD generation mix, or Heywood interconnector flow.
Discover datasets via search_datasets (fuzzy text search) and describe_dataset (schema, filters, cadence, source URL).
List curated datasets with list_curated.
Answer practical questions like: negative pricing in SA, weekly average VIC prices, rooftop PV forecasts, and total NEM demand.
Receive rich metadata with every response — timestamps, units, source URL, AEMO attribution, staleness flags, and server version.
Multiple response formats — records, series, or CSV.
mcp-name: io.ausdata/aemo-mcp
Ask Claude about Australia's electricity market and get real, current numbers — 5-minute spot prices, regional demand, generation by fuel, interconnector flows, rooftop solar — not "I don't have access to that data." This MCP server gives Claude (and other MCP clients like Cursor) live access to the Australian Energy Market Operator (AEMO) NEMWEB feeds, with curated mappings for the most-asked indicators.
Hosted access? For cross-source queries, webhooks, an always-on REST API, and a uniform response envelope across all 9 sources, see ausdata.io — free tier available (500 calls/mo, no card).
Companion to abs-mcp (ABS macro stats), rba-mcp (RBA interest + FX rates), ato-mcp (ATO tax + ACNC charity), apra-mcp (banking + superannuation), aihw-mcp (health & welfare), asic-mcp (companies + financial advisers), and au-weather-mcp (Australian weather) — together they cover the most-asked Australian official data.
Once installed, your LLM can answer questions like:
Question | What the tool does |
What's the current NSW spot price? |
|
Did SA hit negative pricing in the last 24 hours? |
|
Generation by fuel type right now in QLD |
|
Weekly average dispatch price for VIC, last 4 weeks |
|
Rooftop PV forecast for tomorrow |
|
What's the current flow across Heywood (VIC ↔ SA)? |
|
Total NEM demand right now |
|
Every answer comes with the interval timestamp (AEMO market time, UTC+10), units (MW, $/MWh), and a link back to the NEMWEB source. The MCP wraps NEMWEB's CSV/ZIP feeds and exposes them through 5 plain-English tools.
Related MCP server: AusEcon MCP for ABS | RBA | APRA data
# After publish:
uvx --upgrade aemo-mcp
# Local dev:
uv pip install -e .Add to ~/Library/Application Support/Claude/claude_desktop_config.json:
{
"mcpServers": {
"aemo": {
"command": "uvx",
"args": ["--upgrade", "aemo-mcp"]
}
}
}Why
--upgrade?uvx aemo-mcp(without the flag) uses whatever wheel is cached and never adopts new PyPI releases on its own.--upgrademakes uvx check PyPI on each launch and pull a newer release if one exists. Recommended for everyone except offline-first / pinned-version workflows. To verify which version is currently serving you, look at theserver_versionfield on anyDataResponse.
If you also have rba-mcp / abs-mcp installed, all servers run side-by-side.
Claude disambiguates with the server prefix (aemo:get_data, rba:get_data,
abs:get_data).
For local dev (pre-PyPI):
{
"mcpServers": {
"aemo": {
"command": "uv",
"args": ["run", "--directory", "/absolute/path/to/aemo-mcp", "aemo-mcp"]
}
}
}Add to ~/.cursor/mcp.json (or workspace .cursor/mcp.json):
{
"mcpServers": {
"aemo": {
"command": "uvx",
"args": ["--upgrade", "aemo-mcp"]
}
}
}Tool | What it does |
| Fuzzy-search the 7 curated NEM datasets by name, topic, or region. |
| Schema, filters, source URL, cadence, and example queries for one dataset. |
| Query data. Records / series / csv format. |
| Most recent 5-min or 30-min interval for time-series feeds. |
| The 7 curated dataset IDs. |
The 7 datasets cover ~95% of typical NEM analytic queries:
| Cadence | Source | Use case |
| 5 min | DispatchIS / DISPATCHPRICE | Current spot price per region; negative-pricing detection |
| 5 min | DispatchIS / DISPATCHREGIONSUM | Demand + scheduled + semi-scheduled gen + net interchange |
| 5 min | DispatchIS / DISPATCHINTERCONNECTORRES | MW flow + losses across NEM interconnectors |
| 5 min | Dispatch_SCADA | DUID-level MW (every unit), aggregable by fuel |
| 30 min | ROOFTOP_PV/ACTUAL + FORECAST | Regional rooftop solar (actual + forecast) |
| 30 min | PredispatchIS | 30-min forecast, ~40h horizon |
| Daily | Daily_Reports | Yesterday's full data in one drop |
Use list_curated() to enumerate, describe_dataset(dataset_id) to learn
the filters available on each.
NSW1 (New South Wales), QLD1 (Queensland), SA1 (South Australia), TAS1 (Tasmania), VIC1 (Victoria). Western Australia (WEM) and the Northern Territory are not on the NEM and are out of scope.
Every DataResponse carries:
source = "Australian Energy Market Operator"
attribution — AEMO Copyright Permissions verbatim attribution string
source_url — the NEMWEB folder the data came from
retrieved_at — UTC timestamp of the fetch
interval_start / interval_end — period covered
stale — True if the latest interval is older than 2× the feed cadence
server_version — the wheel that served the call
This package is MIT-licensed (see LICENSE).
The AEMO data it fetches is published under AEMO's Copyright Permissions policy: AEMO grants general permission to use AEMO Material for any purpose (commercial included) on the sole condition of accurate attribution of the relevant material and AEMO as its author. See https://aemo.com.au/privacy-and-legal-notices/copyright-permissions.
End-users redistributing data fetched via this server must credit AEMO.
The canonical attribution string is on every DataResponse.attribution.
"What's the current NSW spot price?"
latest(dataset_id="dispatch_price", filters={"region": "NSW1"})→ {"records": [{"period": "2026-05-14T10:05:00+10:00", "value": 87.5, "dimensions": {"region": "NSW1", "metric": "rrp"}, "unit": "$/MWh"}], ...}
"NSW spot price for the last 24 hours"
get_data(dataset_id="dispatch_price", filters={"region": "NSW1"},
start_period="2026-05-13", end_period="2026-05-14")"Did SA hit negative pricing in the last 24 hours?"
get_data(dataset_id="dispatch_price", filters={"region": "SA1"},
start_period="<24h ago>")Then the LLM filters value < 0 client-side.
"Generation by fuel type right now in QLD"
latest(dataset_id="generation_scada", filters={"region": "QLD1"})→ DUID-level rows with fuel attribution; the LLM aggregates by fuel.
Live-fetch only. No NEMWEB archives in the wheel. Every request goes through the cache.
Cache TTLs tuned per cadence. 60s for 5-min feeds, 5min for 30-min feeds, 1h forecasts, 24h daily archive. Timestamped historical files are immutable in NEMWEB and cache effectively forever.
In-flight request deduplication. Concurrent callers for the same URL share one HTTP request. Critical at 5-min cadence with many users.
Latest-file detection is purely lexicographic on the NEMWEB directory
listing — AEMO embeds the interval timestamp in every filename
(PUBLIC_DISPATCHIS_YYYYMMDDHHmm_<seq>.zip), so max() is enough.
Multi-section CSV parser handles AEMO's I,/D, row format where a
single ZIP holds several tables (DISPATCHPRICE, DISPATCHREGIONSUM,
DISPATCHINTERCONNECTORRES, etc.).
git clone https://github.com/Bigred97/aemo-mcp
cd aemo-mcp
uv sync --extra dev
uv pip install -e .
uv run pytest -qRun live tests (hit NEMWEB):
uv run pytest -q -m liveZero-flake validation:
for i in $(seq 1 10); do uv run pytest -q || break; doneWant all 9 sources behind one REST API? The hosted gateway at ausdata.io adds cross-source joins, full history, webhooks, and HMAC-signed responses on top of these MCPs — free tier (500 calls/mo, no card).
abs-mcp — Australian Bureau of Statistics (CPI, unemployment, ERP, building approvals)
rba-mcp — Reserve Bank of Australia (cash rate, lending stats, exchange rates)
ato-mcp — Australian Taxation Office (tax stats, ACNC charities)
apra-mcp — Australian Prudential Regulation Authority (banking, insurance, super)
aihw-mcp — Australian Institute of Health and Welfare
asic-mcp — Australian Securities and Investments Commission (company registers)
aemo-mcp — this one. Australian Energy Market Operator (NEM dispatch, spot prices, generation).
au-weather-mcp — Open-Meteo (Bureau of Meteorology aggregator)
wgea-mcp — Workplace Gender Equality Agency
aus-identity — Postcode / state / ABN normalisation helper used by all sisters
Built by Harry Vass. Issues + PRs welcome at github.com/Bigred97/aemo-mcp.
Describe one NEM dataset — schema, filters, cadence, source URL.
Examples: detail = await describe_dataset("dispatch_price") # → filters: [{key: "region", values: ["NSW1", "QLD1", ...]}] # → metrics: {rrp: "$/MWh"} # → cadence: "5 min"
Returns: DatasetDetail with id, name, description, filters, units, source URL, and example invocation strings.
| Name | Required | Description | Default |
|---|---|---|---|
| dataset_id | Yes | Dataset ID like 'dispatch_price', 'generation_scada'. Use the search endpoint or search tool to discover, or the list-curated endpoint/tool to enumerate. Case-insensitive. |
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| name | Yes | |
| description | Yes | |
| is_curated | Yes | |
| cadence | No | |
| filters | No | |
| units | No | |
| source_url | Yes | |
| examples | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must be self-contained. It lists the return fields (id, name, description, filters, units, source URL, example invocation strings) and includes an example with return structure. No behavioral contradictions.
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 concise: one sentence for purpose, followed by an example and return format. No redundant information; each sentence adds value.
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 tool's simplicity (one parameter, output schema present), the description covers all essential information: what it does, how to use it, and what it returns. No gaps.
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 input schema already provides comprehensive details (100% coverage) for the single parameter, including examples and case-insensitivity note. The description does not add extra parameter semantics beyond mentioning the dataset types, which is not necessary.
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 starts with 'Describe one NEM dataset — schema, filters, cadence, source URL' which clearly states the action and resource. It differentiates from sibling tools like search_datasets and list_curated by focusing on a single dataset's metadata.
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 advises using search or list-curated endpoints to discover dataset IDs before calling this tool. This gives clear guidance on the proper workflow, though it does not explicitly state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Query an AEMO NEM dataset and return observations.
Examples: # Latest NSW dispatch price (preferred over latest() if you want # a window) resp = await get_data("dispatch_price", filters={"region": "NSW1"})
# Whole-day NSW dispatch price for a specific day
resp = await get_data(
"dispatch_price",
filters={"region": "NSW1"},
start_period="2026-05-13",
end_period="2026-05-13"
)
# Generation by fuel for QLD, current
resp = await get_data("generation_scada", filters={"region": "QLD1"})
# All 6 interconnectors right now
resp = await get_data("interconnector_flows")Returns: DataResponse with records, units, period bounds, NEMWEB source URL, and AEMO attribution.
| Name | Required | Description | Default |
|---|---|---|---|
| dataset_id | Yes | Dataset ID like 'dispatch_price'. Use the search endpoint or search tool to discover. | |
| filters | No | Dict of filter key → value(s). Common filters: 'region' (NSW1/QLD1/SA1/TAS1/VIC1), 'interconnector' (V-SA/Basslink/...), 'duid' (unit ID), 'fuel' (black_coal/gas/wind/solar/battery/...). Each dataset's valid filter keys + allowed values are listed in the dataset's detail metadata. | |
| start_period | No | Inclusive start of the period window in AEMO market time (UTC+10). Accepts 'YYYY', 'YYYY-MM', 'YYYY-MM-DD', or 'YYYY-MM-DD HH:MM'. Defaults to None which fetches just the most recent NEMWEB file for the dataset. | |
| end_period | No | Inclusive end. Same format as start_period. | |
| format | No | Response shape. 'records' (default): flat list of observations. 'series': observations grouped by dimensions. 'csv': returns the result as a CSV string in the `csv` field. | records |
| Name | Required | Description |
|---|---|---|
| dataset_id | Yes | |
| dataset_name | Yes | |
| query | No | |
| interval_start | No | |
| interval_end | No | |
| period | No | Canonical {start, end} period bounds for cross-sister consumers. Populated alongside aemo-specific interval_start/interval_end. |
| unit | No | |
| row_count | No | Number of observation rows in records. |
| records | No | |
| csv | No | |
| source | No | |
| attribution | No | |
| source_url | Yes | |
| retrieved_at | Yes | |
| stale | No | |
| stale_reason | No | |
| truncated_at | No | |
| server_version | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It describes the return type (DataResponse with fields) and mentions that it queries data without side effects. However, it lacks explicit statements about read-only nature, authentication, rate limits, or error behavior.
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 well-structured with a clear opening sentence and bullet-pointed examples. While longer due to examples, each sentence adds value and the structure aids readability.
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 tool's complexity (5 parameters, output schema exists), the description covers the return type, common filter patterns, and period formatting. It could mention pagination or error handling but is otherwise adequate for agent use.
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 100%, so baseline is 3. The description adds significant value through extensive examples showing how parameters combine in real queries (e.g., filters with start/end periods). This clarifies usage beyond schema descriptions.
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 action ('Query') and resource ('AEMO NEM dataset'), with multiple examples showing typical use. While it doesn't explicitly distinguish siblings, the examples implicitly separate it from search, describe, and list 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 provides examples that illustrate common use cases but does not explicitly state when to use this tool versus alternatives like search_datasets or describe_dataset. Usage is implied rather than directly guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the most recent interval(s) for a NEM dataset.
For 5-min feeds (dispatch_price, dispatch_region, interconnector_flows, generation_scada): returns the most recent 5-minute interval, typically 1-2 minutes after the interval close.
For 30-min feeds (rooftop_pv, predispatch_30min): the most recent half-hour.
For daily feeds (daily_summary): yesterday's data.
Examples: # Current NSW spot price resp = await latest("dispatch_price", filters={"region": "NSW1"})
# Current generation mix in QLD
resp = await latest("generation_scada", filters={"region": "QLD1"})
# Current flow across Heywood
resp = await latest("interconnector_flows", filters={"interconnector": "V-SA"})Returns:
DataResponse with one observation per filtered (dimension, metric)
tuple at the most recent interval. stale=True flag indicates the
most recent interval is older than 2× the feed cadence (NEMWEB
delay).
| Name | Required | Description | Default |
|---|---|---|---|
| dataset_id | Yes | Dataset ID like 'dispatch_price'. Use the search endpoint or search tool to discover. | |
| filters | No | Optional filter dict. Same shape as get_data — narrow to a region, interconnector, fuel, etc. |
| Name | Required | Description |
|---|---|---|
| dataset_id | Yes | |
| dataset_name | Yes | |
| query | No | |
| interval_start | No | |
| interval_end | No | |
| period | No | Canonical {start, end} period bounds for cross-sister consumers. Populated alongside aemo-specific interval_start/interval_end. |
| unit | No | |
| row_count | No | Number of observation rows in records. |
| records | No | |
| csv | No | |
| source | No | |
| attribution | No | |
| source_url | Yes | |
| retrieved_at | Yes | |
| stale | No | |
| stale_reason | No | |
| truncated_at | No | |
| server_version | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description provides good behavioral details: interval cadence per feed type, delay characteristics, and the stale flag. Lacks explicit mention that it is a read-only operation, but the context is clear.
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 well-organized with sections for different feed types, a concise list of examples, and no unnecessary words. Every sentence contributes to understanding.
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 that an output schema exists, the description provides sufficient context about the return type (DataResponse with stale flag) and covers all relevant feed types. No gaps identified.
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 has 100% coverage with descriptions and examples, but the description adds value by explaining the meaning in context, such as how filters narrow results and which dataset IDs apply.
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 precisely states the tool's purpose: 'Return the most recent interval(s) for a NEM dataset.' It differentiates from siblings like get_data (historical) and search_datasets by focusing on the latest single observation.
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 clearly tells when to use the tool (to get the most recent interval) and provides examples. However, it does not explicitly mention when not to use it or contrast with siblings like get_data for historical queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the 7 curated AEMO NEM dataset IDs.
These cover ~95% of typical NEM analytic queries: spot prices, regional demand and generation, interconnector flows, unit-level SCADA, rooftop PV (actual + forecast), 30-min predispatch forecasts, and daily-settled summaries.
Example: ids = list_curated() # → ['daily_summary', 'dispatch_price', 'dispatch_region', # 'generation_scada', 'interconnector_flows', # 'predispatch_30min', 'rooftop_pv']
Returns: Sorted list of dataset IDs. Always 7 entries today.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| 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. It reveals that the tool returns a sorted list of 7 entries and provides examples. It does not discuss error handling or immutability, but for a simple read-only list, this is adequate.
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 concise, front-loading the main purpose, and provides a clear example and summary. Every sentence adds value without 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?
Given the simplicity of the tool, the description is complete. It explains what the tool does, what it returns, and its typical use. The output schema is present, but the description already covers the return structure.
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 input schema has no parameters, so the description adds value by explaining the output and purpose. Baseline for 0 parameters is 4, and the description appropriately compensates for the lack of parameter details.
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 explicitly states that this tool lists the 7 curated AEMO NEM dataset IDs, which covers ~95% of typical queries. It distinguishes itself from sibling tools like 'get_data' and 'search_datasets' by being a no-parameter listing operation.
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 explains that the tool returns the most common datasets, implying it should be used first for typical analytical queries. However, it does not explicitly state when not to use it or compare with alternatives like 'search_datasets'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fuzzy-search the 7 curated AEMO NEM datasets.
Use this when you don't know the exact dataset_id. The 7 curated datasets cover ~95% of typical NEM analytic queries — spot prices, demand, generation, rooftop PV, interconnector flows, forecasts.
Examples: # Find the dataset that publishes the spot price results = await search_datasets("spot price") # → [{id: 'dispatch_price', name: 'NEM Dispatch Price ...', ...}]
# Discover what's available on rooftop solar
results = await search_datasets("rooftop pv", limit=5)Returns: List of DatasetSummary (id, name, description, cadence), ranked by relevance. All v0 datasets are curated.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Free-text search query. Matches against dataset IDs, names, descriptions, filter keys, region values, and search keywords. Case-insensitive. | |
| limit | No | Maximum number of results to return, ranked by relevance. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains that the tool returns a list of DatasetSummary objects ranked by relevance and that datasets are curated. It also provides example output structure. However, it does not address behavior like rate limiting or error handling, but for a search tool, the provided detail is sufficient.
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 concise yet comprehensive: it starts with a clear purpose, provides usage guidance, includes illustrative examples, and states the return format. Every sentence adds value, and the structure is logical and 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?
Given the tool's complexity (2 parameters, output schema exists), the description covers all essential aspects: purpose, when to use, return format, and examples. The output schema handles detailed return field definitions, so the description is complete. No omissions for typical usage.
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 input schema already covers both parameters with descriptions and examples (100% coverage). The description adds value by explaining that the search is fuzzy, results are ranked by relevance, and the curated nature of the datasets. This context enriches the parameter meaning beyond the 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 clearly states that the tool performs fuzzy-search on the 7 curated AEMO NEM datasets, and specifies it is for use when exact dataset_id is unknown. This distinguishes it from siblings like describe_dataset (which requires a known ID) and list_curated (which lists all curated datasets). The purpose is specific and actionable.
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 explicitly advises using this tool when the exact dataset_id is unknown, and mentions that curated datasets cover ~95% of typical NEM queries. This provides clear context for when to use this tool versus alternatives. Examples further illustrate usage scenarios.
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. Dates show when Glama detected each change.
v0.4.14describe_datasetget_datalatestlist_curatedsearch_datasetsv0.4.13describe_datasetget_datalatestlist_curatedsearch_datasetsv0.1.1describe_datasetget_datalatestlist_curatedsearch_datasetsEach tool has a distinct purpose: describe_dataset provides schema details, get_data retrieves arbitrary time ranges, latest returns the most recent interval, list_curated enumerates datasets, and search_datasets performs fuzzy search. Even though get_data and latest both retrieve data, their use cases are clearly separated by examples and descriptions.
Tool names are in snake_case and follow a verb_noun pattern for four tools (describe_dataset, get_data, list_curated, search_datasets). The exception is 'latest', which is an adjective rather than a verb, but it is still concise and commonly understood in data contexts.
With 5 tools, the server covers the essential operations for interacting with AEMO NEM datasets: schema discovery, data retrieval, latest value shortcut, dataset listing, and fuzzy search. This scope is neither too sparse nor too heavy for the domain.
The toolset provides a complete workflow for read-only access to AEMO NEM data: discover available datasets (list_curated, search_datasets), inspect schema (describe_dataset), and retrieve data (get_data, latest). There are no obvious missing operations like update or delete, which are not expected in this read-only context.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Query Australia's electricity market (NEM/AEMO): prices, generation, FCAS, interconnectors, bids.
Gas and fuel prices by station and area, as structured data via a hosted MCP server.
Browse and query the EIA API v2 — electricity, petroleum, natural gas, coal, forecasts via MCP.
Energi Data Service (Energinet) MCP — Denmark's official open energy data.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Bigred97/aemo-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
