You're building a predictive maintenance model for a solar installation company in Casablanca -- predicting panel and inverter failures 7-14 days ahead from hourly monitoring data -- and connecting Claude Code to your MLflow experiment tracking via MCP for the first time.
The discipline skills: building a predictive maintenance model from sensor time series data, implementing per-prediction cost tracking that captures the full cost chain (not just the obvious API call), designing budget alerts that trigger before costs become a problem, and configuring MCP to give Claude direct read access to MLflow experiments.
The AI-direction lesson: MCP changes the directing relationship. Before the connection, you describe experiment results to Claude. After, Claude reads them directly -- querying runs, comparing metrics, retrieving artifacts. This is a qualitative capability shift. But it introduces a new category of verification: did Claude query the right experiment? Did it retrieve the right metrics? Did it draw honest conclusions, or did the MCP query return results from an interrupted training run that Claude reported with full confidence? When AI reads data directly instead of working from your description, you need to verify the data path, not just the output.
Your Role
The scaffolding is the same as last time. Brief only. You own the decomposition, the ticket breakdown, the approach. No guides, no templates. You also configure and verify the MCP connection that gives Claude direct access to your experiment data.
What's New
Last time you deployed a model to the cloud with Docker Compose, cost controls, and scaling configuration.
This time you connect Claude to your experiment data. MCP gives Claude direct access to MLflow -- it can query runs, compare metrics across experiments, and retrieve model artifacts without you mediating. The directing relationship changes when AI reads the data instead of working from your description.
Cost monitoring activates at a new level. Not just "how much does the cloud deployment cost" but "how much does each individual prediction cost, and is that cost justified by the maintenance savings?" Amina's clients will want the math.
The hard part is verifying what comes back through the MCP connection. When Claude queries your experiments directly, you need to check that it queried the right experiment, retrieved the right metrics, and drew honest conclusions. That is a new category of verification.
Tools
- MLflow MCP server -- connects Claude Code to MLflow experiment tracking (new)
- Claude Code with MCP configuration -- agent-tool connectivity (new aspect)
- Python -- scripting, data processing (familiar)
- scikit-learn -- modeling, evaluation (familiar)
- MLflow -- experiment tracking (familiar, now MCP-connected)
- pandas -- data processing (familiar)
- Docker -- containerization (familiar)
- FastAPI -- serving endpoint (familiar)
- Git / GitHub -- version control (familiar)
- Claude Code -- AI direction, plan mode (familiar)
Materials
You receive:
- Two years of hourly monitoring data from 120 solar installations (panel output, inverter status, temperatures, weather, dust)
- Maintenance logs with failure types, severity, resolution costs, and technician hours
- An evaluation suite template with stubs for precision, recall, lead-time accuracy, and MLflow logging
- An MCP server configuration file for connecting Claude Code to MLflow
- A project governance file (CLAUDE.md)