bizidashboard-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| BIZI_API_BASE_URL | No | Base URL of the BiziDashboard instance to query. Override to point at another city's deployment or a local dev server. | https://datosbizi.com |
| BIZI_PUBLIC_API_KEY | No | X-Public-Api-Key sent on every request. Only required for elevated calls (CSV exports on get_alerts_history/get_rebalancing_report, or wide days/limit windows on those two tools). Everything else works anonymously. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_stationsA | List every Bizi Zaragoza station with its latest known availability snapshot (bikes available, free anchors, capacity, location). Reflects the most recent GBFS collection, not necessarily real time to the second. |
| get_rankingsA | Rank stations by turnover (bike rotation activity) or availability. Useful for finding the busiest or most reliably stocked stations over the observed history. |
| get_alertsA | List currently active alerts (stations running low on bikes or free anchors right now). |
| get_alerts_historyA | Query historical alerts (resolved and active) with filters by station, alert type, severity, and time range. This is the tool for "how often has station X run out of bikes" style questions. Requesting format=csv or a limit above 500 rows requires BIZI_PUBLIC_API_KEY to be configured. |
| get_patternsA | Get weekday vs. weekend hourly occupancy patterns for a single station, showing typical bike availability by hour. |
| get_heatmapB | Get occupancy heatmap cells (day x hour) for a single station. |
| get_mobilityA | Get mobility signals: hourly demand curve, station-to-station flow signals, and public transit impact analysis. Good for understanding usage rhythms rather than instantaneous state. |
| get_historyA | Get full historical daily demand/balance data since BiziDashboard started recording this city, plus coverage metadata. This is the long-range view the official GBFS feed cannot provide since it only exposes current state. |
| get_rebalancing_reportA | Get the station rebalancing diagnostic report: per-station classification (overstock, deficit, peak saturation, peak emptying, balanced, data_review), 1h/3h empty/full risk predictions, and origin-destination bike transfer recommendations. Optionally filter by district/barrio. Requesting format=csv or a days window above 30 requires BIZI_PUBLIC_API_KEY to be configured. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 9 tools
Most tools have clearly distinct purposes, but get_patterns and get_heatmap both describe occupancy patterns for a single station, differing only in data format (weekday/weekend hourly vs day x hour heatmap). get_rankings and get_mobility are also somewhat related but descriptions clarify their distinct focuses.
All tools follow a consistent get_<noun> pattern, using snake_case throughout. The naming is predictable and makes it easy for an agent to infer the resource being accessed.
Nine tools is a well-scoped set for a bike-sharing analytics dashboard, covering current status, alerts, historical trends, mobility patterns, and rebalancing diagnostics without feeling bloated or sparse.
The tool set provides comprehensive coverage of the station analytics domain: current availability, rankings, active and historical alerts, hourly patterns, heatmaps, long-range history, mobility signals, and rebalancing recommendations. No obvious dead ends or missing core operations.