Bixi MCP Server
Bixi MCP Server
================
[](LICENSE)
[](https://github.com/renaudb/bixi-mcp/actions/workflows/ci.yml)
## Description
A local (stdio) [MCP](https://modelcontextprotocol.io) server exposing the [BIXI Montréal](https://bixi.com) bike-share API, via [bixi-sdk](https://github.com/renaudb/bixi), as tools for MCP clients.
## Tools
- `list_stations` — list all Bixi stations currently in service.
- `list_rides` — list the current member's ride history (paginated via `offset`).
## Installation
The server can be run directly with [`uvx`](https://docs.astral.sh/uv/guides/tools/) — no separate install step required.
## Configuration
The server authenticates with your Bixi account using the `BIXI_USERNAME` and `BIXI_PASSWORD` environment variables.
Example configuration for an MCP client (e.g. Claude Desktop `claude_desktop_config.json`):
```json
{
"mcpServers": {
"bixi": {
"command": "uvx",
"args": ["bixi-mcp"],
"env": {
"BIXI_USERNAME": "your-username",
"BIXI_PASSWORD": "your-password"
}
}
}
}
```
## Development
```bash
pip install -e .[dev]
pre-commit install
```
TDQS
Scored across 2 tools
The two tools target completely different domains: station availability/location versus the member's ride history. There is no possibility of confusing list_stations with list_rides. Each has a clearly distinct purpose.
Both tools follow a consistent verb_noun pattern (list_stations, list_rides), using snake_case throughout. The naming convention is uniform and predictable.
With only 2 tools, the server feels quite thin for what appears to be a bike-sharing service. While both tools are useful, the scope of a Bixi server would naturally extend to more operations, meaning the count sits at the borderline low end.
The surface is notably incomplete. It provides station listing and ride history, but lacks obvious operations such as finding available bikes/docks, checking station real-time availability, or any ride lifecycle actions. The read-only surface covers only a narrow slice of the domain.