Renewable Vision energy data

Search the project trackers

search_projects

Read-only

Match a name, developer, country, region or city across the project trackers and return the matching rows with their capacities, largest first. dataset: renewables (Saudi renewable projects — technology, capacity MW, status operational|construction|tendered|announced, developers, LCOE), captive (Saudi captive and corporate solar: corporate PPAs, plants owned by the factory or farm they supply, plants built into water projects — capacity as the source states it, offtaker, arrangement, status operational|construction|contracted|tendered|announced|observed, sources), gcc (utility-scale solar, CSP, wind and battery projects of 50 MW or more in the UAE, Oman, Qatar, Kuwait and Bahrain — country as ISO code, capacity as stated, procurer, owners and developers, published tariff, the same statuses, sources), data-centres (Saudi data-centre records — lead, city, disclosed MW with its basis, investment), ccus (global carbon capture projects — developer, country, capture Mt/yr, sector), hydrogen (the IEA low-emission hydrogen map, mirrored as capacity by year, region and stage rather than as named projects). Omit dataset to search the renewables, captive, GCC, data-centre and CCUS trackers at once. Capacity totals are summed only inside one dataset, in that dataset’s own unit; captive and GCC capacity is MW as each source states it (MWac or MWp) and heat (MWth) is never added. The renewables, captive, gcc and data-centres datasets are the layers of the Energy Atlas and are free with membership: they answer a request carrying a member’s API key, and refuse one without, as does a search with no dataset named; ccus and hydrogen answer anyone.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "query": "<query>"
    },
    "name": "search_projects"
  }
}

Input Schema

Name	Required	Description
`limit`	No	Rows per dataset; default 20
`query`	Yes	Name, developer, country, region or city
`dataset`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 10, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, and the description adds substantial context beyond them: authentication requirements per dataset (member key required, refusal without one, including a search with no dataset named), result ordering (largest first), and aggregation semantics (capacity summed only within a single dataset, MWac/MWp never reconciled, MWth never added). Those are exactly the behavioral facts an agent cannot infer from structured fields.

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?

Purpose, ordering and the omit-dataset rule are front-loaded, and the long dataset catalog is information-dense rather than padded. The cost is a single dense paragraph of parenthetical glosses that is hard to scan; splitting the dataset catalog into a list would improve it without adding words.

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?

For a three-parameter search tool with no output schema, the description covers what an agent needs to call it correctly: which trackers exist and what each holds, the multi-dataset default, unit/aggregation caveats, ordering, and the authentication gate that can cause a refusal. Return shape is characterized at a high level ('matching rows with their capacities'), which is sufficient absent an output schema.

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

Parameters5/5

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

Schema coverage is only 67% and the `dataset` enum carries no per-value descriptions in the schema, so the description compensates by glossing every dataset's contents, geography, fields and status vocabulary, plus what omitting it means. That is meaning well beyond the enum values themselves, and `query` semantics align with the schema's own description.

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?

Opens with a concrete verb and scope: match a name/developer/country/region/city across the project trackers and return matching rows with capacities, largest first. It then enumerates exactly which trackers are searched, so an agent can distinguish this from generic siblings like `search` without opening the schema.

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?

Gives a clear operational rule for the key decision: omit `dataset` to search renewables, captive, GCC, data-centre and CCUS at once, otherwise pick one tracker. It also states the access rule (member API key required for four datasets, ccus and hydrogen open to anyone), which determines whether the call can succeed. It does not, however, explicitly contrast with sibling tools such as `search` or `get_report`.

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

All Renewable Vision energy data tools Inspect

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

Need Help?