Skip to main content
Glama
ESJavadex

REE MCP Server

by ESJavadex

get_spain_hourly_prices

Retrieve hourly electricity prices for Spain's SPOT market on a specific date to analyze daily electricity costs and identify peak pricing periods.

Instructions

Get Spanish hourly electricity prices (SPOT market) for a specific day.

Returns the 24 hourly prices for the Spanish Peninsular market (OMIE/MIBEL). This is the simplified version focused only on Spain, perfect for checking daily electricity costs.

Args: date: Date in YYYY-MM-DD format

Returns: JSON string with hourly prices, min/max/average, and the cheapest/most expensive hours.

Examples: Get today's hourly prices: >>> await get_spain_hourly_prices("2025-10-19")

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dateYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Implementation Reference

  • The main handler function for the 'get_spain_hourly_prices' tool. Decorated with @mcp.tool() for automatic registration. Fetches SPOT market price data from REE API, filters for Spanish Peninsular market, processes hourly prices, calculates statistics, and returns formatted JSON response.
    @mcp.tool()
    async def get_spain_hourly_prices(date: str) -> str:
        """Get Spanish hourly electricity prices (SPOT market) for a specific day.
    
        Returns the 24 hourly prices for the Spanish Peninsular market (OMIE/MIBEL).
        This is the simplified version focused only on Spain, perfect for checking
        daily electricity costs.
    
        Args:
            date: Date in YYYY-MM-DD format
    
        Returns:
            JSON string with hourly prices, min/max/average, and the cheapest/most
            expensive hours.
    
        Examples:
            Get today's hourly prices:
            >>> await get_spain_hourly_prices("2025-10-19")
        """
        try:
            start_datetime = f"{date}T00:00"
            end_datetime = f"{date}T23:59"
    
            async with ToolExecutor() as executor:
                use_case = executor.create_get_indicator_data_use_case()
    
                # Get SPOT price data
                request = GetIndicatorDataRequest(
                    indicator_id=IndicatorIDs.SPOT_MARKET_PRICE.id,
                    start_date=start_datetime,
                    end_date=end_datetime,
                    time_granularity="hour",
                )
                response = await use_case.execute(request)
                price_data = response.model_dump()
    
            values = price_data.get("values", [])
    
            # Filter to only Spanish Peninsular market
            spain_values = [v for v in values if v["geo_scope"] == "Península"]
    
            if not spain_values:
                return ResponseFormatter.success(
                    {
                        "date": date,
                        "error": "No price data available for Spanish Peninsular market",
                    }
                )
    
            # Build hourly price list
            hourly_prices = []
            for value_point in spain_values:
                hourly_prices.append(
                    {
                        "datetime": value_point["datetime"],
                        "hour": value_point["datetime"][11:13],  # Extract HH from datetime
                        "price_eur_per_mwh": round(value_point["value"], 2),
                    }
                )
    
            # Sort by datetime to ensure correct order
            hourly_prices.sort(key=lambda x: x["datetime"])
    
            # Calculate statistics
            prices = [p["price_eur_per_mwh"] for p in hourly_prices]
            min_price = min(prices)
            max_price = max(prices)
            avg_price = sum(prices) / len(prices)
    
            # Find cheapest and most expensive hours
            cheapest_hours = [p for p in hourly_prices if p["price_eur_per_mwh"] == min_price]
            most_expensive_hours = [p for p in hourly_prices if p["price_eur_per_mwh"] == max_price]
    
            result = {
                "date": date,
                "market": "Península (OMIE/MIBEL)",
                "hourly_prices": hourly_prices,
                "statistics": {
                    "min_price_eur_per_mwh": round(min_price, 2),
                    "max_price_eur_per_mwh": round(max_price, 2),
                    "avg_price_eur_per_mwh": round(avg_price, 2),
                    "total_hours": len(hourly_prices),
                },
                "cheapest_hours": [
                    {"hour": h["hour"], "price": h["price_eur_per_mwh"]} for h in cheapest_hours
                ],
                "most_expensive_hours": [
                    {"hour": h["hour"], "price": h["price_eur_per_mwh"]}
                    for h in most_expensive_hours
                ],
                "unit": "€/MWh",
            }
    
            return ResponseFormatter.success(result)
    
        except Exception as e:
            return ResponseFormatter.unexpected_error(e, context="Error getting Spanish hourly prices")
  • The @mcp.tool() decorator registers the get_spain_hourly_prices function as an MCP tool in the FastMCP server.
    @mcp.tool()
Behavior3/5

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

With no annotations provided, the description carries the full burden. It discloses that it returns data for the 'Spanish Peninsular market (OMIE/MIBEL)' and includes min/max/average and cheapest/most expensive hours, adding useful context. However, it lacks details on error handling, rate limits, or data freshness, which are important for a data-fetching tool.

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

Conciseness5/5

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

The description is appropriately sized and front-loaded, starting with the core purpose, followed by returns, args, and examples. Every sentence adds value without redundancy, and the structure is clear and efficient for quick understanding.

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

Completeness4/5

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

Given the tool has an output schema, the description doesn't need to explain return values in detail, and it adequately covers the purpose and parameter. However, as a data-fetching tool with no annotations, it could benefit from more behavioral context like error cases or data sources, but it's mostly complete for its complexity.

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?

The schema description coverage is 0%, so the description must compensate. It adds meaning by specifying the parameter 'date' must be in 'YYYY-MM-DD format' and provides an example, which clarifies usage beyond the bare schema. Since there's only one parameter, this is sufficient, but it doesn't explain validation rules or constraints.

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?

The description clearly states the tool's purpose with specific verb ('Get') and resource ('Spanish hourly electricity prices (SPOT market)'), and distinguishes it from siblings by specifying it's the 'simplified version focused only on Spain' for 'checking daily electricity costs.' This differentiates it from other price-related tools like get_price_analysis or get_pvpc_rate.

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?

The description provides clear context for when to use this tool ('perfect for checking daily electricity costs') and implies it's for Spain-specific data, but does not explicitly state when not to use it or name alternatives among siblings. It suggests usage for a 'specific day' without mentioning limitations like date range or availability.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/ESJavadex/ree-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server