metaflow-mcp-server
# Metaflow MCP Server
[](https://github.com/npow/metaflow-mcp-server/actions/workflows/ci.yml)
[](https://pypi.org/project/metaflow-mcp-server/)
[](https://pypi.org/project/metaflow-mcp-server/)
[](LICENSE)
[](https://modelcontextprotocol.io/) [](https://mintlify.com/npow/metaflow-mcp-server)
Give your coding agent superpowers over your Metaflow workflows. Instead of writing throwaway scripts to check run status or dig through logs, just ask -- your agent will figure out the rest.
Works with any Metaflow backend: local, S3, Azure, GCS, or Netflix internal.
<p align="center">
<img src="demo/demo.gif" alt="demo" width="800">
</p>
## Tools
| Tool | Description |
|------|-------------|
| `get_config` | What backend am I connected to? (also returns your default namespace) |
| `list_flows` | What flows exist in a namespace? |
| `search_runs` | Find recent runs of any flow |
| `get_run` | Step-by-step breakdown of a run |
| `get_task_logs` | Pull stdout/stderr from a task |
| `list_artifacts` | What did this step produce? |
| `get_artifact` | Grab an artifact's value |
| `get_latest_failure` | What broke and why? |
| `search_artifacts` | Which runs produced a named artifact? |
## Quickstart
```bash
pip install metaflow-mcp-server
claude mcp add --scope user metaflow -- metaflow-mcp-server
```
That's it. Restart Claude Code and start asking questions about your flows.
**To upgrade:**
```bash
pip install --upgrade metaflow-mcp-server
```
Then restart Claude Code (or reconnect via `/mcp`) to pick up the new version.
If Metaflow lives in a specific venv, point to it:
```bash
claude mcp add --scope user metaflow -- /path/to/venv/bin/metaflow-mcp-server
```
For other MCP clients, the server speaks stdio: `metaflow-mcp-server`
## How it works
Wraps the Metaflow client API. Whatever backend your Metaflow is pointed at, the server uses too -- no separate config needed. Sets `namespace(None)` at startup so production runs (Argo, Step Functions, Maestro) are visible alongside your dev runs.
Starts once per session, communicates over stdin/stdout. No daemon, no port.
## License
Apache-2.0
TDQS
Scored across 24 tools
Each tool has a clearly distinct purpose, from run management (get_run, run_flow, resume_run) to artifact handling (get_artifact, list_artifacts, search_artifacts) to comparisons (diff_runs, compare_cards). There is no ambiguity between similar-sounding tools like get_recent_runs and search_runs, as their descriptions clarify different scopes and filters.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., add_run_tags, get_config, list_flows). Even compound names like get_latest_failure or get_triggered_run_status adhere to the pattern. No mixing of conventions (camelCase or other styles) is present.
With 24 tools, the set is slightly above the typical well-scoped range (3-15) but remains justified for the Metaflow domain, which involves many distinct operations (runs, artifacts, cards, deployments, tags, etc.). The count is not excessive given the platform's complexity.
The tool surface covers most core workflows: running flows (locally and triggered), monitoring, fetching artifacts and logs, comparing runs, managing tags, and viewing cards and deployments. Minor gaps exist, such as no explicit tool to abort a locally run flow (only triggered runs) and no tool to delete runs or artifacts, but these do not severely hinder typical agent tasks.