odouche-mcp
# odouche
[](https://github.com/avanserv/odouche/actions/workflows/ci.yml?query=branch%3Amain)
[](LICENSE)
An unofficial toolkit for working with [Odoo.sh](https://www.odoo.sh) from your development
environment: list branches, watch builds, stream logs, from a script, a terminal or an agent.
> **Unofficial.** This project is not affiliated with, endorsed by, or supported by Odoo S.A.
> Odoo.sh has no public API: odouche talks to what the Odoo.sh web interface uses, which can change
> without notice.
>
> **Pre-alpha.** The library and the `osh` command log in, list projects, branches and builds,
> watch a build, read and follow its logs and start a rebuild, and `osh ssh` opens a shell on a
> build with your own `ssh`: the
> [CLI guide](https://avanserv.github.io/odouche/cli/) has the commands. The MCP server reports
> its session, lists projects, branches and builds, reads one build and its logs and, when you
> allow it, starts a rebuild.
## Packages
| Package | What it is |
| --- | --- |
| [`odouche`](packages/odouche) | A Python library: the client for Odoo.sh, usable in your own tools. |
| [`odouche-cli`](packages/odouche-cli) | The `osh` command, in the spirit of `gcloud`, `aws` and `scw`. |
| [`odouche-mcp`](packages/odouche-mcp) | A Model Context Protocol server, for development agents. |
The command-line tool and the MCP server are built on the library, and only on its public
interface.
## Credentials
odouche never sees, stores or logs your password or your GitHub token. The
[security model](docs/security.md) says what it does keep, where, and for how long.
## Development
Requires [uv](https://docs.astral.sh/uv/) and `make`.
```bash
make install # install the workspace and the git hooks
make check # format, lint, types, dependencies, dead code, tests with coverage, docs
make help # everything else
```
[CONTRIBUTING.md](CONTRIBUTING.md) has the conventions, and [SECURITY.md](SECURITY.md) how to
report a vulnerability.
## License
[MIT](LICENSE)
TDQS
Scored across 7 tools
Each tool targets a distinct action: listing (list_projects/list_branches/list_builds), single-item read (get_build, get_session), log read (read_log), and polling (wait_for_build). The build-oriented tools (list_builds, get_build, wait_for_build, read_log) all touch builds but have clearly separated purposes, with minor potential overlap between get_build and the build data returned by wait_for_build.
All names follow a consistent snake_case verb_noun pattern (list_projects, list_branches, list_builds, get_session, get_build, read_log, wait_for_build). The get_*/read_* split is a minor stylistic nuance but not a convention break.
7 tools is well-scoped for a read-only Odoo.sh monitoring server, with each tool earning its place across the project → branch → build → log hierarchy plus session status and build polling.
The read-only surface covers the core lifecycle (discover projects, branches, builds, detailed build, logs, and build completion polling), which is coherent for a read-only server. Minor gaps exist: no dedicated single-project or single-branch detail tool, and no mutation operations, though the latter may be out of scope by design.