---
title: "MCP Servers Behaving Badly"
newsletter: "MLOps Community"
date: 2026-06-25
source: https://aaif.live/newsletters/mlopscommunity/2026-06-25-mcp-servers-behaving-badly
---

# MCP Servers Behaving Badly

*Plus... sandboxed agents, feature drift, secure RAG, coding subagents, and Databricks’ Omnigent.*

*MLOps Community — Agentic AI Foundation, 2026-06-25*

Positive news from OpenAI on open-source security [https://openai.com/index/patch-the-planet/], though the name sounded familiar...

## RAGrets

Your RAG eval can be green while the wrong user sees the right chunk.

When retrieval gets sensitive, what matters more - relevance or authorization?

[RELEVANCE](https://gatewaze.mlops.community/offer/surveys/?sid=yesno&question=Logs+are+underrated+because+dashboards+made+us+lazy.+If+agents+can+reconstruct+metrics+and+traces+from+logs%2C+what+would+you+rather+debug+with%3A+Dashboards+or+Chat%3F&y=DASHBOARDS&n=CHAT&oneclick=true&accept=true)

[AUTHORIZATION](https://gatewaze.mlops.community/offer/surveys/?sid=yesno&question=Logs+are+underrated+because+dashboards+made+us+lazy.+If+agents+can+reconstruct+metrics+and+traces+from+logs%2C+what+would+you+rather+debug+with%3A+Dashboards+or+Chat%3F&y=DASHBOARDS&n=CHAT&oneclick=true&accept=true)

## On the Trail

Evals are trailing, with 80% putting more trust in audit logs when agents fail.

## Curated finds to help you stay ahead

## OPEN SOURCE SOFTWARE

Agent work is starting to look a lot like browser-tab chaos for terminals. Claude Code in one terminal, Codex in another, maybe Pi or a custom agent for a specific job, a sandbox or two, a pile of credentials, and an approval step that lives in someone's head. Work gets copy-pasted between agents, Docs, and Slack. Each harness only understands its own sessions, so nothing carries over when you switch tools.

Earlier this month, Databricks open sourced Omnigent [https://www.databricks.com/blog/introducing-omnigent-meta-harness-combine-control-and-share-your-agents] under Apache-2.0. It calls itself a meta-harness: a common interface that wraps Claude Code, Codex, Pi, and agents you write yourself, then adds the things a single harness rarely gives you across tools, like collaboration, policies, cost caps, and cloud execution.


WHAT IT IS

The core idea is that, however each harness talks to its model internally, the interface to the user is the same: messages and files in, text streams and tool calls out. 

Omnigent builds one API over that and splits the system in two. A runner wraps an agent in a sandboxed session and executes the loop and tools, either on your machine or in a cloud sandbox. A server handles persistence, policies, sharing, and access from terminal, browser, phone, or the macOS app. 

The split keeps code execution and model credentials on the host side rather than in the server, which matters if you care where your secrets live. (cough cough enterprise-ready)

Omnigent wraps agent harnesses in a runner, with a server handling policies, history, MCPs, skills, and shared interfaces. Image: Databricks 


WHY IT MATTERS

Let’s look at what this lets you build once the agents are interchangeable:

 * Collaboration on the session, not the chat window. Share a live session by URL, watch it run, comment on files, co-drive it, or fork it. The session is the shared object, so a teammate or reviewer joins the work rather than a transcript of it.

 * Contextual policies. Rules that track session state instead of static allow/deny. The example from the docs is gating git push only after an agent has installed a new npm package. Policies stack across server, agent, and session, with the stricter rules checked first.

 * Cost caps. Per-session spend tracking with hard caps and soft warnings, so a sub-agent tree cannot quietly burn through tokens. You can tell it to pause and ask after every $100. (Or if you are like me, have it play a cha-ching sound and Fat Joe/Lil Wayne make it rain [https://www.youtube.com/watch?v=6OP8SNdyWJA&list=RD6OP8SNdyWJA&start_radio=1] at full volume)

 * Cloud execution. This is becoming table stakes now. Nobody is excited about keeping their laptop open on the metro. 

 * Multi-harness authoring. Probably the most interesting for me. Define an agent in one YAML file [https://github.com/omnigent-ai/omnigent/blob/main/docs/AGENT_YAML_SPEC.md] covering prompt, executor, tools, policies, and sub-agents, then switch harnesses with a one-line change, or mix harnesses inside the same agent.


META HARNESS & LOOP ENGINEERING

Addy Osmani's recent writing on loop engineering [https://addyosmani.com/blog/loop-engineering/] argues that the work has shifted from prompting one agent to designing repeatable systems of worktrees, sub-agents, connectors, and persistent state. 

Omnigent reads as a control layer for that shift. The bundled Polly example is a lead agent that plans, hands coding to sub-agents in parallel git worktrees, and routes each diff to a reviewer from a different vendor than the one that wrote it. Debby runs the same question through a Claude head and a GPT head side by side and lets them debate. 

So the fit is workflows like planner plus coder plus reviewer, cross-vendor adjudication, and a team working a single repo state together. The current docs lean harder on orchestration, collaboration, and policies than on scheduling and automation, so today Omnigent is less a finished loop product and more a substrate you build loop-style workflows on.


WHAT LOOKS PROMISING

 * A real abstraction if you already run more than one harness or model family, rather than a wrapper around one.

 * A more explicit governance story than a lot of open-source agent tooling: contextual policies, spend caps, and approval gates built in.

 * Collaboration primitives that are part of the session model, not bolted on afterward.

 * A YAML agent spec that makes multi-agent, multi-harness setups legible for a platform team.


WHAT NEEDS CAUTION

This is alpha. The repo [https://github.com/omnigent-ai/omnigent] is clearly early, carries an explicit alpha badge, and there is not much independent operator feedback yet, so almost all the public evidence is launch material. Treat any judgment on ergonomics or reliability as provisional until people have run it on real repos.

The setup surface is also wider than the one-line install [https://omnigent.ai/quickstart/install] suggests. You need Python 3.12+, uv, git, and Node.js 22+ for the Claude/Codex/Pi harnesses, plus tmux for the native wrappers. Remote deploys [https://github.com/omnigent-ai/omnigent/blob/main/deploy/README.md] add database choices, memory floors, slower first boot against remote Postgres, and provider caveats like Modal's 24-hour sandbox lifetime and Daytona's free-tier egress limits.

The biggest operational risk is that the collaboration features cut both ways. Co-drive means another user's messages can execute on your machine, and the docs warn that header-based auth is dangerous unless a trusted reverse proxy rewrites identity headers correctly. Get that wrong and one caller could impersonate another and reach sessions, files, and history. Cross-vendor loops can also raise token spend fast, and if your team is standardizing on one harness anyway, Omnigent may be more control plane than you need.


IN PRACTICE

I got early impressions from my friend Mateo (who is a much better engineer than myself). 

Setup was genuinely easy, which is worth noting against the dependency list above. His take was that Omnigent simplifies the loopcraft idea a lot, and that for someone already running their own custom multi-agent setups the tradeoff is versatility against ease. 

Bespoke stacks still offer more flexibility, and can go further than Omnigent's static YAML-led setup. Gas Town [https://github.com/gastownhall/gastown] and the newer Gas City SDK [https://github.com/gastownhall/gascity], for instance, can run a coordinator agent that watches a task tracker and hands work out to other agents on its own. But, the Gas projects are also far harder to stand up, and Omnigent closes most of that gap with much less effort.

The main limitation was around MCP. Today, an MCP server is wired in either as a local command or a remote URL with a bearer token, which means keeping tokens on your machine or in the Databricks config. He would prefer MCP OAuth with dynamic client registration so credentials are not sitting locally. I’m sure this will change soon. (Friend of the pod Corey Zumar is doing a ton of work on Omniagent, and that guy ships)

Between CLIs, MCP, and Agent Skills, switching between harnesses is already possible without much ceremony, and a team running one or two agents may find their own light glue does the job. 

I know in our Friday coding agent sessions folks have asked how others are using coding agents in teams now. The case for Omnigent gets stronger as the coordination problem grows: several harnesses, multiple people, work moving across machines, and policies or spend limits that need to hold across all of it.

## JOB OF THE WEEK

## The Dark Side of MCP Servers

A broken MCP server can make a capable agent look useless, and a malicious one can change the tools it exposes after you already trusted it. This podcast looks at what has to improve before MCP feels safe in production.

 * Toolbench and MCP Debugger expose protocol failures, misstated capabilities, broken auth, and bad tool schemas.

 * Skills, CLIs, and MCP solve different problems once agents move beyond local coding workflows.

 * OAuth-based MCP keeps user identity outside the prompt, reducing spoofing and token misuse.

Reliable agents need boring protocol behavior before they get dangerous work.

[https://podcasts.apple.com/gb/podcast/the-dark-side-of-mcp-servers/id1505372978?i=1000773916733](https://podcasts.apple.com/gb/podcast/the-dark-side-of-mcp-servers/id1505372978?i=1000773916733)

[https://home.mlops.community/home/videos/the-dark-side-of-mcp-servers](https://home.mlops.community/home/videos/the-dark-side-of-mcp-servers)

[https://open.spotify.com/episode/3ApCMsI0ewBsj0jFv8dzmE?si=c9d1a22118154612](https://open.spotify.com/episode/3ApCMsI0ewBsj0jFv8dzmE?si=c9d1a22118154612)

## Sandboxing, Agent Harnesses, and Agent Teamwork

An SRE agent that gets 70% right can still send an engineer down the wrong path during an incident. This podcast looks at why production agents need more than better models.

 * Harness design has to evolve as models improve, relaxing rigid tools while adding stronger sandboxing.

 * Verification matters more than the agent loop, especially across messy production environments.

 * Slack history, code, logs, and human feedback can teach agents local rules and decision bounds.

Better agents need clear boundaries, fast feedback, and humans reviewing the decisions that matter.

[https://podcasts.apple.com/gb/podcast/sandboxing-agent-harnesses-and-agent-teamwork/id1505372978?i=1000773385608](https://podcasts.apple.com/gb/podcast/sandboxing-agent-harnesses-and-agent-teamwork/id1505372978?i=1000773385608)

[https://home.mlops.community/home/videos/sandboxing-agent-harnesses-and-agent-teamwork](https://home.mlops.community/home/videos/sandboxing-agent-harnesses-and-agent-teamwork)

[https://open.spotify.com/episode/7dBe0sVJLv2u2fvb794pqM?si=ce8ea0cc4c9b4f80](https://open.spotify.com/episode/7dBe0sVJLv2u2fvb794pqM?si=ce8ea0cc4c9b4f80)

## Roundtable: Building Real-Time ML Systems with Zipline + Chronon

A feature can look right offline and still be wrong when it hits serving. This round table looks at why teams are moving feature pipelines toward Chronon and Zipline as models, ranking systems, and real-time use cases grow.

 * Batch and streaming definitions can share one authoring path, reducing training-serving drift.

 * Point-in-time joins, backfills, and online lookup become platform concerns instead of product-team chores.

 * Adoption still carries cost, especially around debugging, versioning, and fitting existing data assumptions.

For growing ML systems, feature correctness is where speed either holds or breaks.

[https://podcasts.apple.com/gb/podcast/zipline-roundtable-episode-building-real-time-ml-systems/id1505372978?i=1000773131746](https://podcasts.apple.com/gb/podcast/zipline-roundtable-episode-building-real-time-ml-systems/id1505372978?i=1000773131746)

[https://home.mlops.community/home/videos/zipline-roundtable-episode-building-real-time-ml-systems-with-zipline-chronon](https://home.mlops.community/home/videos/zipline-roundtable-episode-building-real-time-ml-systems-with-zipline-chronon)

[https://open.spotify.com/episode/3qR3wI99eKn1r2JxfN86jn?si=b69865ec8fa64988](https://open.spotify.com/episode/3qR3wI99eKn1r2JxfN86jn?si=b69865ec8fa64988)

## Securing the Agent: Vendor-Neutral, Multitenant Enterprise Retrieval and Tool Use

A RAG system can retrieve the perfect chunk and still show it to the wrong person. This discussion looks at the security gap behind multi-tenant agent systems, where relevance scores alone are not enough.

 * Authorization has to happen at chunk level, before retrieved context reaches the model.

 * Predicate pushdown helps preserve recall by filtering tenant access inside the vector database.

 * Server-side orchestration gives teams a stronger place to enforce policy on tool calls and retrieval.

The danger starts when retrieval works, but access control arrives too late.

[Watch the reading group](https://home.mlops.community/home/videos/securing-the-agent-vendor-neutral-multitenant-enterprise-retrieval-and-tool-use)

## Supagents: One Source to Rule Your Coding Subagents

One Friday tweak to an agent persona can quietly turn into five different behaviors across five coding tools. This blog shows how supagents keeps Claude Code, Gemini CLI, Copilot, Cursor, OpenCode, and Kilo Code aligned from one markdown source.

 * Shared instructions live in .agents/supagents/, then compile into each tool’s expected agent format.

 * Per-tool frontmatter stays verbatim, so fast-changing agent config does not need a fragile translation layer.

 * Pre-commit and CI checks stop generated agent files drifting from the source.

A small compiler can save a lot of debugging when every agent starts from the same instructions.

[Read the blog](https://mlops.community/blog/supagents-one-source-to-rule-your-coding-subagents)

## VIRTUAL EVENTS

* The Current State of Agentic Retrieval [https://home.mlops.community/home/events/the-current-state-of-agentic-retrieval-g3ssvap40q?agenda_day=6a1ee42216f5cb7213db38dc&agenda_track=6a1ee42316f5cb7213db3911&agenda_stage=6a1ee42216f5cb7213db38e0&agenda_filter_view=stage&agenda_view=list] - June 25

 * Coding Agents Lunch & Learn Session [https://home.mlops.community/home/events/coding-agents-lunch-and-learn-session-16-real-world-coding-agent-workflows-drpuzfuq6q?agenda_day=6a30467ed33e5acb9d2e6f06&agenda_track=6a30467fd33e5acb9d2e6f1d&agenda_stage=6a30467ed33e5acb9d2e6f0c&agenda_filter_view=stage&agenda_view=list] - June 26

## Feature Drift Store

[https://docs.google.com/forms/d/e/1FAIpQLScLyUmV7B_fvmiQni6cF0iIFMEvjrL5fivzUjdFci14G_nQCA/viewform](https://docs.google.com/forms/d/e/1FAIpQLScLyUmV7B_fvmiQni6cF0iIFMEvjrL5fivzUjdFci14G_nQCA/viewform)

---
Source: https://aaif.live/newsletters/mlopscommunity/2026-06-25-mcp-servers-behaving-badly
