How do I use Renfe MCP Server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Renfe MCP Server What trains go from Madrid to Barcelona tomorrow?" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

Renfe MCP Server

by belgrano9

Overview Schema Related Servers Score Discussions

Python

Remote

Renfe MCP Server 🚄

A Model Context Protocol (MCP) server for querying Renfe (Spanish national railway) train schedules using official GTFS data. Integrates seamlessly with Claude Desktop and other MCP-compatible clients.

Python 3.12+ FastMCP License: MIT

✨ Features

🔍 Search trains between any two Spanish cities on a specific date with pagination
💰 Check prices - real-time price scraping from Renfe website with pagination support
🚉 Find stations in any city (Madrid has 7 stations!)
📅 Flexible date parsing - accepts ISO, European, and written date formats
🔄 Auto-updates - automatically downloads latest GTFS schedules from Renfe
⚡ Fast & accurate - uses official Renfe GTFS data with complete timetables
🎯 Smart filtering - handles service calendars, holidays, and exceptions
🛠️ Claude Desktop ready - works out of the box with MCP clients

Related MCP server: railinfo-mcp

🚀 Quick Start

Prerequisites

Python 3.12 or higher
uv (recommended) or pip

Installation

Clone the repository

git clone https://github.com/yourusername/renfe_mcp.git
cd renfe_mcp

Install dependencies
```
uv sync
```
Run the server (GTFS data downloads automatically)
```
uv run python -m renfe_mcp.server
```

📖 Usage

Standalone Testing

Test the search functionality directly:

from renfe_mcp.schedule_searcher import ScheduleSearcher
from renfe_mcp.price_checker import check_prices

# Search trains
searcher = ScheduleSearcher("renfe_schedule")
trains = searcher.search("Madrid", "Barcelona", "2025-11-20")

# Check prices
prices = check_prices("Madrid", "Barcelona", "2025-11-20")

Claude Desktop Integration

Add to your Claude Desktop config file:

Windows (%APPDATA%\Claude\claude_desktop_config.json):

{
  "mcpServers": {
    "renfe": {
      "command": "uv",
      "args": [
        "--directory",
        "C:\\Users\\YourName\\path\\to\\renfe_mcp",
        "run",
        "python",
        "-m",
        "renfe_mcp.server"
      ]
    }
  }
}

macOS (~/Library/Application Support/Claude/claude_desktop_config.json):

{
  "mcpServers": {
    "renfe": {
      "command": "uv",
      "args": [
        "--directory",
        "/path/to/renfe_mcp",
        "run",
        "python",
        "-m",
        "renfe_mcp.server"
      ]
    }
  }
}

Linux (~/.config/Claude/claude_desktop_config.json):

{
  "mcpServers": {
    "renfe": {
      "command": "uv",
      "args": [
        "--directory",
        "/path/to/renfe_mcp",
        "run",
        "python",
        "-m",
        "renfe_mcp.server"
      ]
    }
  }
}

Restart Claude Desktop, and you can ask:

"Show me trains from Madrid to Barcelona tomorrow"
"What's the earliest train from Barcelona to Valencia on December 1st?"
"What train stations are in Madrid?"
"How many trains run between Madrid and Sevilla in the afternoon?"
"Check prices for trains from Madrid to Barcelona on December 1st"
"What are the ticket prices for the first 5 trains?"

🛠️ MCP Tools

1. `search_trains`

Find trains between two cities on a specific date with pagination support.

Parameters:

origin (string): Origin city name (e.g., "Madrid", "Barcelona")
destination (string): Destination city name (e.g., "Valencia", "Sevilla")
date (string, optional): Travel date in flexible formats:
- ISO: "2025-11-28"
- European: "28/11/2025"
- Written: "November 28, 2025"
- Default: today's date
page (integer, optional): Page number to display (default: 1)
per_page (integer, optional): Results per page (default: 10, max: 50)

Example Output:

Found 36 train(s) total
Showing page 1 of 4 (10 trains)

  1. AVE
     Madrid Pta.Atocha - Almudena Grandes → Barcelona-Sants
     Departs: 6:16:00 | Arrives: 9:05:00
     Duration: 2h 49min

  2. AVE
     Madrid Pta.Atocha - Almudena Grandes → Barcelona-Sants
     Departs: 6:27:00 | Arrives: 9:25:00
     Duration: 2h 58min
  ...

─────────────────────────────────
To see more trains, use page=2
Total pages: 4

2. `find_station`

Search for train stations in a city.

Parameters:

city_name (string): City name to search (e.g., "Madrid")

Example Output:

Found 7 stations:

All stations found:
  1. Madrid-Chamartín-Clara Campoamor (ID: 17000)
  2. Madrid - Atocha Cercanías (ID: 18000)
  3. Madrid Pta.Atocha - Almudena Grandes (ID: 60000)
  ...

3. `get_train_prices`

Check actual ticket prices by scraping the Renfe website with pagination support.

Parameters:

origin (string): Origin city name (e.g., "Madrid", "Barcelona")
destination (string): Destination city name (e.g., "Valencia", "Sevilla")
date (string, optional): Travel date (same formats as search_trains)
page (integer, optional): Page number to display (default: 1)
per_page (integer, optional): Results per page (default: 5, max: 20)

Example Output:

PRICE CHECK RESULTS
From: Madrid -> Barcelona
Date: 2025-11-17
Showing 5 train(s)

  1. AVE
     Departs: 06:16 | Arrives: 09:05
     Duration: 2h 49min
     Price: 94.90 EUR | [Available]

  2. AVE
     Departs: 06:27 | Arrives: 09:25
     Duration: 2h 58min
     Price: 118.60 EUR | [Available]
  ...

To see more prices, try page=2

Note: This tool scrapes the Renfe website and may take a few seconds to complete. Pagination now matches search_trains so you can get prices for trains on any page (e.g., page 2 shows prices for trains 6-10).

📊 Data Updates

The server includes automatic GTFS data updates from Renfe's open data portal.

Automatic Updates

On server startup, it checks for new data and downloads if needed:

uv run python -m renfe_mcp.server
# [CHECK] Checking data versions:
#         Server: 2025-11-15T00:40:21
#         Local:  2025-11-10T00:30:15
# [UPDATE] Server has newer data
# [DOWNLOAD] Downloading GTFS data...
# [OK] GTFS data updated successfully!

Manual Updates

Check and update if needed:

uv run python -m renfe_mcp.update_data

Force update (download regardless of version):

uv run python -m renfe_mcp.update_data --force

The update system:

✅ Compares server version with local version
✅ Only downloads when new data is available
✅ Stores version info in renfe_schedule/.last_updated
✅ Automatically extracts GTFS CSV files

🏗️ Architecture

renfe_mcp/
├── pyproject.toml           # Dependencies & build config
├── README.md                # This file
├── src/renfe_mcp/           # Main package
│   ├── __init__.py          # Package exports
│   ├── server.py            # FastMCP server implementation
│   ├── config.py            # Pydantic configuration
│   ├── exceptions.py        # Exception hierarchy
│   ├── logging.py           # Structured logging
│   ├── security.py          # Auth & rate limiting
│   ├── price_checker.py     # Price checking module
│   ├── schedule_searcher.py # GTFS schedule search
│   ├── station_service.py   # Unified station lookups
│   ├── update_data.py       # GTFS data updater
│   └── scraper/             # Price scraper package
│       ├── __init__.py      # Package exports
│       ├── scraper.py       # RenfeScraper with DWR protocol
│       ├── dwr.py           # DWR utilities
│       ├── models.py        # Pydantic models
│       ├── exceptions.py    # Scraper exceptions
│       └── stations.json    # Station code database
├── tests/                   # Test suite
│   ├── test_final_integration.py
│   ├── test_security.py
│   └── ...
└── renfe_schedule/          # GTFS data (auto-downloaded)
    ├── stops.txt            # Station information
    ├── routes.txt           # Train routes
    ├── trips.txt            # Trip schedules
    ├── stop_times.txt       # Arrival/departure times
    ├── calendar.txt         # Service schedules
    ├── calendar_dates.txt   # Holiday exceptions
    └── .last_updated        # Version tracking

How It Works

City to Station Mapping: Fuzzy matches city names to station IDs
Date Filtering:
- Checks calendar.txt for service schedules (day of week)
- Applies exceptions from calendar_dates.txt (holidays, special dates)
Route Finding:
- Joins trips, stop_times, and stops tables
- Validates stop sequences and pickup/dropoff permissions
- Ensures origin comes before destination
Results: Returns all trains sorted chronologically with proper numeric time sorting

Key Implementation Details

✅ Handles multiple stations per city (e.g., Madrid has 7)
✅ Respects service exceptions (holidays, maintenance)
✅ Validates passenger boarding/alighting permissions (pickup_type, drop_off_type)
✅ Fixed sorting bug: Proper numeric time sorting (not lexicographic!)
✅ CSV column whitespace handling (strips on load)
✅ Complete result sets (no truncation)

🗺️ Supported Routes

The server supports any route in the Renfe network:

High-Speed (AVE): Madrid-Barcelona, Madrid-Sevilla, Madrid-Valencia
Long-Distance (ALVIA, Intercity): Major city connections
International (AVE INT): Cross-border services
Regional: Local routes across Spain
Commuter (Cercanías): Urban networks

Popular Cities:

Madrid (7 stations), Barcelona, Valencia
Sevilla, Málaga, Bilbao, Zaragoza
Alicante, Córdoba, Granada, Murcia
100+ cities across Spain!

Use find_station to discover available stations in any city.

🔧 Development

Project Setup

# Clone and install
git clone https://github.com/yourusername/renfe_mcp.git
cd renfe_mcp
uv sync

# Run the server
uv run python -m renfe_mcp.server

# Run tests
uv run python tests/test_final_integration.py

Dependencies

fastmcp (>=0.7.0) - MCP server framework
pandas (>=2.3.3) - GTFS data processing
pydantic (>=2.11.7) - Data validation and models
pydantic-settings (>=2.0.0) - Environment-based configuration
httpx (>=0.27.0) - Modern HTTP client for price scraping
python-dateutil (>=2.8.2) - Flexible date parsing
json5 (>=0.12.0) - JavaScript object parsing for DWR responses
python-dotenv (>=1.0.0) - Environment variables

Configuration

Configure via environment variables (prefix RENFE_) or .env file:

# Authentication
RENFE_ENABLE_AUTH=true
RENFE_API_KEY=your-secret-key

# Rate Limiting
RENFE_RATE_LIMIT_ENABLED=true
RENFE_MAX_REQUESTS_PER_MINUTE=30
RENFE_MAX_REQUESTS_PER_HOUR=200

# Development
RENFE_DEV_MODE=false
RENFE_LOG_LEVEL=INFO

📝 Data Source

GTFS data from Renfe's Open Data Portal:

API Endpoint: https://data.renfe.com/api/3/action/resource_show
Resource ID: 25d6b043-9e47-4f99-bd91-edd51d782450
Update Frequency: Updated regularly by Renfe (checked on server startup)
Format: GTFS (General Transit Feed Specification)
Size: ~800 KB compressed, ~40 MB extracted

🐛 Known Issues

Windows console may show encoding errors with Unicode characters (functionality not affected)
Very large result sets (100+ trains) can be verbose but complete

🤝 Contributing

Contributions welcome! Please:

Fork the repository
Create a feature branch (git checkout -b feature/amazing-feature)
Commit your changes (git commit -m 'Add amazing feature')
Push to the branch (git push origin feature/amazing-feature)
Open a Pull Request

Ideas for Contributions

~~Add price information~~ (✅ Implemented via web scraping)
Support for train status/delays
Multi-leg journey planning
Visualization of routes on maps
Additional query filters (train type, duration, etc.)
Return trip price checking

📄 License

This project is licensed under the MIT License - see the LICENSE file for details.

🙏 Acknowledgments

Renfe Operadora for providing open GTFS data
FastMCP by @jlowin for the excellent MCP framework
Anthropic for Claude and the Model Context Protocol
The GTFS community for standardizing transit data

📮 Support

Issues: GitHub Issues
Discussions: GitHub Discussions
MCP Docs: Model Context Protocol

SNCF MCP Server - Similar server for French railways
FastMCP - The framework powering this server
MCP Servers - Official MCP server implementations

🙏 Sources & Inspiration

renfe-bot by @emartinez-dev - Telegram bot for Renfe train ticket monitoring. The DWR (Direct Web Remoting) protocol reverse-engineering and price scraping techniques were inspired by renfe-bot's implementation. This MCP server features a custom-built scraper using modern Python (httpx, pydantic) while preserving the core DWR protocol logic.

Built with ❤️ using FastMCP and Claude

Travel smart, travel by train! 🚄

Available Tools

3 tools

find_stationA

Search for train stations in a city and return matching options.

Useful for checking what stations are available in a city before searching for journeys.

Args: city_name: City name to search for (e.g., "Madrid", "Barcelona", "Valencia") api_key: API key for authentication (optional if configured via environment)

Returns: A formatted string showing all matching stations with their IDs and full names.

ParametersJSON Schema

Name	Required	Description	Default
`city_name`	Yes
`api_key`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.4/5.0

Behavior3/5

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

No annotations are provided, so the description bears full burden. It mentions returns as a formatted string with IDs and names, and that api_key is optional. However, it does not disclose potential side effects, rate limits, or error behavior, which is a gap for a network call 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 concise, front-loading the purpose in the first sentence, followed by a clear use case and structured Args/Returns sections. No redundant information.

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?

Given the tool has only 2 parameters and an output schema exists, the description provides all necessary context: what it does, when to use it, parameter explanations, and return format. It is complete for this simple tool.

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 description coverage is 0%, but the description compensates fully by explaining city_name with examples (e.g., Madrid, Barcelona) and clarifying api_key's optional nature and purpose. This adds significant meaning beyond the bare schema.

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 explicitly states 'Search for train stations in a city and return matching options.' It uses a specific verb (Search) and resource (stations), and clearly distinguishes from sibling tools like get_train_prices and search_trains.

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 gives clear context: 'Useful for checking what stations are available in a city before searching for journeys.' This explains when to use the tool, but does not explicitly state when not to use or mention alternatives beyond the implied sequence.

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

get_train_pricesA

Check actual ticket prices for trains between two cities using web scraping with pagination.

NOTE: This tool scrapes the Renfe website and may take a few seconds to complete. It complements the search_trains tool by providing real-time price information. This endpoint has stricter rate limits due to web scraping.

Args: origin: Starting city name (e.g., "Madrid", "Barcelona", "Valencia") destination: Destination city name (e.g., "Madrid", "Barcelona", "Sevilla") date: Travel date. Accepts flexible formats: - ISO: "2025-11-28" (RECOMMENDED) - European: "28/11/2025" - Written: "November 28, 2025" or "28 November 2025" If not provided, checks prices for today's date. page: Page number to display (default: 1) per_page: Number of results per page (default: 5, max: 20) api_key: API key for authentication (optional if configured via environment)

Returns: Formatted string with train prices, availability, and booking information.

ParametersJSON Schema

Name	Required	Description	Default
`origin`	Yes
`destination`	Yes
`date`	No
`page`	No
`per_page`	No
`api_key`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.7/5.0

Behavior5/5

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

With no annotations, the description fully discloses scraping behavior, potential delays, rate limits, pagination, and the return format, giving the agent clear behavioral expectations.

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?

The description is well-structured with Args and Returns sections but is slightly verbose. However, it efficiently front-loads the purpose and provides necessary parameter details without redundancy.

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?

Given no annotations and a missing output schema, the description comprehensively covers purpose, usage, behavior, and all parameters, leaving no critical gaps for an agent to invoke the tool correctly.

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?

Since schema description coverage is 0%, the description adds essential meaning to all 6 parameters, including examples for origin/destination, detailed date formats, page/per_page defaults, and api_key usage.

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 checks actual ticket prices via web scraping with pagination, and distinguishes it from the sibling tool search_trains by noting it provides real-time price information.

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 mentions it complements search_trains and notes stricter rate limits, providing usage context. However, it does not explicitly state when not to use this tool or give alternatives beyond the sibling.

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

search_trainsA

Search for train journeys between two cities on a specific date.

Args: origin: Starting city name (e.g., "Madrid", "Barcelona", "Valencia") destination: Destination city name (e.g., "Madrid", "Barcelona", "Sevilla") date: Travel date. Accepts flexible formats: - ISO: "2025-11-28" (RECOMMENDED) - European: "28/11/2025" - Written: "November 28, 2025" or "28 November 2025" If not provided, searches for today's date. page: Page number to display (default: 1) per_page: Number of results per page (default: 10, max: 50) api_key: API key for authentication (optional if configured via environment)

Returns: Formatted string with available train options including times and durations.

ParametersJSON Schema

Name	Required	Description	Default
`origin`	Yes
`destination`	Yes
`date`	No
`page`	No
`per_page`	No
`api_key`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.3/5.0

Behavior3/5

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 input parameters and output (formatted string with times/durations), but lacks details on side effects, authentication (api_key optional but not explained), rate limits, or error handling.

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 well-structured with 'Args' and 'Returns' sections, each parameter is clearly described, and the entire text is concise without unnecessary details.

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 6 parameters (2 required) and no annotations, the description covers all parameters and explains the return value (formatted string). However, it could include more detail on pagination behavior or error responses, and the output schema exists but is not summarized in the description.

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 0%, yet the description adds substantial meaning: lists example city names for origin/destination, explains flexible date formats, specifies default and max values for page/per_page, and clarifies api_key as optional.

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 it searches for train journeys between two cities on a specific date, using the verb 'Search' and resource 'train journeys'. It distinguishes from siblings 'find_station' and 'get_train_prices' by focusing on journey search.

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 explains when to use the tool (search for train journeys) and provides date format guidance. However, it does not explicitly state when not to use it or mention alternatives like 'get_train_prices' for pricing.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

3 tool updatesv0.4.0May 28, 2026
- First observedfind_station
- First observedget_train_prices
- First observedsearch_trains

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.4/5.0

Disambiguation5/5

Each tool serves a distinct purpose: station lookup, journey search, and price retrieval. No overlap in functionality.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern in snake_case: find_station, get_train_prices, search_trains.

Tool Count4/5

Three tools cover the core workflow of finding stations, searching journeys, and checking prices. While minimal, it's appropriate for the scope.

Completeness4/5

Covers the essential travel information needs: station lookup, journey search, and pricing. Missing booking or detailed trip info, but acceptable for an info-focused server.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

MetehanGZL-pokemcpOAuth
ai.smithery
Provide detailed Pokémon data and information through a standardized MCP interface. Enable LLMs an…
Search Open Data
2
Live Times Transit
io.github.travelwhiz-ltd
Read-only public transit departures, stop search, and city coverage for bus and train users.
Travel & Transportation Location Services
1
Pointify Travel A
com.pointifytravels
Search award flights and cash fares, optimize points, and predict fares inside ChatGPT and Claude.
Travel & Transportation Finance
52
Europe Rail Watch MCPOAuth
net.nexlab
Monitor European train stations
1

Related MCP Servers

NS Travel MCP Server
Travel & Transportation Location Services
lauragift21
F
license
Not graded
quality
D
maintenance
Provides real-time Dutch Railways (NS) data for journey planning, live departures, disruptions, and station search.
Updated a year ago (2025-06-09 21:52 UTC)
3
-
railinfo-mcp
Travel & Transportation Search
AquibFaiyaz
F
license
Not graded
quality
D
maintenance
Enables real-time Indian Railways information retrieval, including live train running status, station schedules, and upcoming arrivals/departures.
Updated 3 months ago (2026-06-07 13:54 UTC)
-
SNCF MCP Server
Travel & Transportation Search
belgrano9
F
license
A
quality
D
maintenance
Enables querying SNCF train schedules and stations in France using the official Navitia API, with support for flexible date parsing and real-time journey planning.
Updated 10 months ago (2025-11-16 16:30 UTC)
3
1
-
data-sncf
Travel & Transportation Open Data
pipeworx-io
A
license
Not graded
quality
C
maintenance
Enables querying SNCF Open Data (train schedules, stations, punctuality, etc.) through natural language or direct tool calls, with dataset search, metadata retrieval, and ODSQL querying.
Updated 11 days ago (2026-08-26 16:57 UTC)
15
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/belgrano9/renfe_mcp_server'

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

Renfe MCP Server 🚄

✨ Features

🚀 Quick Start

Prerequisites

Installation

📖 Usage

Standalone Testing

Claude Desktop Integration

🛠️ MCP Tools

1. search_trains

2. find_station

3. get_train_prices

📊 Data Updates

Automatic Updates

Manual Updates

🏗️ Architecture

How It Works

Key Implementation Details

🗺️ Supported Routes

🔧 Development

Project Setup

Dependencies

Configuration

📝 Data Source

🐛 Known Issues

🤝 Contributing

Ideas for Contributions

📄 License

🙏 Acknowledgments

📮 Support

🔗 Related Projects

🙏 Sources & Inspiration

Available Tools

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

1. `search_trains`

2. `find_station`

3. `get_train_prices`