DEV Community

Renato Marinho
Renato Marinho

Posted on

Experiment tracking is a dashboard problem. Until it isn't.

I spent most of last week doing what every ML engineer does when they should be actually engineering: clicking through nested folders in a web dashboard, trying to find why one specific run from Tuesday had a slightly better precision than the others.

It’s a tedious loop. Open the browser, navigate the workspace hierarchy, hunt for the project, click into the experiment, and then scroll endlessly through logs or parameters to find that one hyperparameter tweak you made at 2 AM. It’s not just boring; it breaks your flow. When you're deep in a coding session in Cursor or Claude, every context switch to a browser tab is a tax on your productivity.

The problem isn't that the data isn't there—Comet ML tracks it brilliantly. The problem is how we access it. We treat experiment tracking as something we 'go to' instead of something that 'comes to us.'

I’ve been working on a way to bridge this gap using the Model Context Protocol (MCP). By connecting an AI agent directly to your Comet ML instance, you stop being a navigator and start being an auditor. You don't browse; you ask.

The Topology of Experiments

Most people think about MCP servers as simple API wrappers. But when you’re dealing with something like Comet ML, the real value is in navigating the hierarchy without knowing where you are.

The Comet ML MCP server I've deployed on Vinkius doesn't just dump data; it allows an agent to understand your organizational structure through tools like list_workspaces and list_projects. You can literally ask, "What projects am I running in the research-team workspace?" and the agent performs the structural extraction for you.

Once the agent understands the landscape, the heavy lifting begins. Instead of manually hunting for an experiment ID, you use list_experiments to discover exactly which runs exist within a specific project scope. If you're looking for that one run with a particular tag or timestamp, the agent finds it by parsing the routing arrays Comet provides.

Auditing via Natural Language

The real magic happens when you move from navigation to inspection. This is where the 'engineer-to-agent' workflow becomes powerful.

If I'm debugging a model convergence issue, I don't want to hunt for metrics. I want to ask: "Get current metrics for experiment 'exp_abc123'." The get_experiment_metrics tool allows the agent to pull precise numeric endpoints—loss, accuracy, learning rate curves—directly into your chat context. If you see a spike in loss at epoch 45, you don't go back to the dashboard; you ask the agent what happened to the parameters at that exact moment.

This is where get_experiment_params comes in. You can audit the internal properties of an experiment—the learning rates, batch sizes, or optimizer configurations—using natural language. I’ve used this to verify if a recent change in my local training script actually matches what was logged in a previous successful run on Comet. The agent pulls the hyperparameter's API taxonomy and lays it out clearly.

Why This Matters for MLOps

For MLOps teams, this isn't just about convenience; it’s about observability at scale. When you have hundreds of runs across multiple workspaces, human-led auditing becomes impossible. An agent can programmatically scan through experiment metadata to identify outliers or drift in performance metrics that a human would simply overlook while clicking through tabs.

You can provide the agent with an experiment key and say: "Audit all experiments in this project and tell me which ones used a batch size of 32 but failed to reach 90% accuracy." That is a task that takes twenty minutes of manual work, or five seconds of natural language command.

The Setup (No Fluff)

I hate complex configurations. If I have to configure an OAuth callback just to see my ML metrics, the tool has already failed me.

The setup for this server is three steps:

  1. Subscribe to the server on Vinkius.
  2. Enter your Comet ML API Key (the one from your Account Settings).
  3. Paste the connection token into Claude or Cursor.

That’s it. No managing local Python environments, no handling complex dependency hell for MCP execution. It just works because we run everything in isolated V8 sandboxes with built-in governance—handling things like DLP and audit chains under the hood so you can focus on the science, not the plumbing.

You can find the full server and its documentation here: https://vinkius.com/mcp/comet-ml

Stop clicking through tabs. Start auditing your models.


MCPs are the music of AI Agents. We built the catalog. Discover Vinkius MCP Catalog.

Top comments (0)