Content
# EchoBase MCP
This project provides a locally resident `streamable HTTP` MCP service for accessing multiple named database connections in read-only mode.
Currently supported:
- MySQL
- PostgreSQL
## Build
```bash
go build -o bin/echobase-mcp ./cmd/echobase-mcp
go build -o bin/echobase-ctl ./cmd/echobase-ctl
```
## Start And Stop
```bash
./bin/echobase-ctl start test
./bin/echobase-ctl start prod
./bin/echobase-ctl start all
./bin/echobase-ctl status
./bin/echobase-ctl doctor
./bin/echobase-ctl restart test
./bin/echobase-ctl stop prod
./bin/echobase-ctl stop all
```
Default conventions:
- `test` uses [`configs/config.local.yaml`](configs/config.local.yaml)
- `prod` uses [`configs/config.prod.yaml`](configs/config.prod.yaml)
- `test` listens on `127.0.0.1:39001`
- `prod` listens on `127.0.0.1:39002`
- Logs are written to `.echobase/logs/*.log`
- PID is written to `.echobase/run/*.pid`
If you need to start the service process manually, you can run:
```bash
./bin/echobase-mcp --config $PWD/configs/config.local.yaml --listen 127.0.0.1:39001
./bin/echobase-mcp --config $PWD/configs/config.prod.yaml --listen 127.0.0.1:39002
```
Health check addresses:
- test: `http://127.0.0.1:39001/healthz`
- prod: `http://127.0.0.1:39002/healthz`
MCP addresses:
- test: `http://127.0.0.1:39001/mcp`
- prod: `http://127.0.0.1:39002/mcp`
## Config
There are currently three configuration files in the repository:
- [`configs/config.local.yaml`](configs/config.local.yaml): test environment
- [`configs/config.prod.yaml`](configs/config.prod.yaml): production environment
- [`configs/config.example.yaml`](configs/config.example.yaml): desensitized example template
If the test and production environments have the same data source name, you can keep the same `connections[].name`; the client distinguishes the environment through the outer service name, and the service list prompts which set of environments is currently connected through `server.title`.
`echobase-ctl` will not modify your client configuration file, only responsible for service startup, shutdown, status check, and fragment generation.
If you write the complete DSN directly into the configuration file, you can skip this step.
Environment variable example (only needed when using `${...}` placeholders in the configuration file):
```bash
export ORDERS_MYSQL_DSN='user:pass@tcp(localhost:3306)/orders'
export ANALYTICS_PG_DSN='postgres://user:pass@localhost:5432/analytics?sslmode=disable'
```
## Client Setup
Codex can directly generate the official `config.toml` fragment with the control command:
```bash
./bin/echobase-ctl snippet codex
```
Output example:
```toml
[mcp_servers.echobase_test]
url = "http://127.0.0.1:39001/mcp"
[mcp_servers.echobase_prod]
url = "http://127.0.0.1:39002/mcp"
```
You can also add it directly using Codex CLI:
```bash
codex mcp add echobase_test --url http://127.0.0.1:39001/mcp
codex mcp add echobase_prod --url http://127.0.0.1:39002/mcp
```
Claude Code can generate `.mcp.json` style fragments:
```bash
./bin/echobase-ctl snippet claude
```
Output example:
```json
{
"mcpServers": {
"echobase_test": {
"type": "http",
"url": "http://127.0.0.1:39001/mcp"
},
"echobase_prod": {
"type": "http",
"url": "http://127.0.0.1:39002/mcp"
}
}
}
```
It is recommended to use:
- `echobase_test` corresponds to [`configs/config.local.yaml`](configs/config.local.yaml)
- `echobase_prod` corresponds to [`configs/config.prod.yaml`](configs/config.prod.yaml)
This way, even if there are connections with the same name such as `evaluation`, `message_center`, and `myqa` in both sides, they will not be confused.
## Logs
View logs for a certain environment:
```bash
./bin/echobase-ctl logs test
./bin/echobase-ctl logs prod
```
## Tools
The service provides the following read-only tools:
- `list_connections`
- `list_namespaces`
- `list_tables`
- `describe_table`
- `run_read_query`