{"slug": "castpilot-mcp-put-your-agent-to-work-on-production-problems", "title": "CastPilot MCP: put your agent to work on production problems", "summary": "Cast AI released CastPilot MCP into general availability, exposing Cast AI cluster and database capabilities as tools that MCP-compatible AI clients can call with defined inputs and outputs. One engineer used CastPilot MCP for about a week and a half, including during on-call work, to review production cluster policies and to build a manual dry-run workflow for Evictor changes by combining MCP data with their own simulation logic and direct cluster access. The release also lets coding agents pull Database Optimizer Performance Advisor recommendations, fetching impact and validation summaries first and then the full SQL and explanation for selected recommendations.", "body_md": "If you’re still collecting cluster data and pasting it into an AI conversation, you’re doing work your agent could be doing. CastPilot MCP lets your agent retrieve that context directly from Cast AI and use it alongside your code and configuration. A question about a production policy can become an investigation. A database recommendation can become a proposed code change, without someone carrying every piece of information between the two.\n\n## From recommendation to confident change\n\nAn engineer we spoke with had a concrete reason to try this while on call. They had already used CastPilot Assistant to help create cluster policies. Now they wanted to examine those policies more closely and work through adjustments in their preferred AI client.\n\nTheir questions went beyond whether a configuration looked sensible. Which workloads could a change affect? Could several nodes restart together? Some services needed a maintenance window before they could be interrupted.\n\nThe assistant needed the existing policies and information about the environment they governed. Connecting Cast AI directly to their AI client opened up an experiment: bring those policies into the conversation and ask the assistant to help improve them.\n\nThey tried it. With CastPilot MCP supplying the data, they reviewed their policies and worked through adjustments for their production clusters. By the time we spoke, they had been using MCP for about a week and a half, including heavily during their on-call work.\n\nThey also took it further. They combined MCP data with their own simulation logic and direct cluster access to build a manual dry-run workflow for Evictor changes. Before applying a configuration, they wanted to explore its effect on the workloads they cared about.\n\nThe simulation was their own work. MCP supplied the data for it. Predicting what a change would do still required their logic and knowledge of the applications.\n\nCastPilot MCP is now generally available. It exposes Cast AI capabilities as tools an MCP-compatible client can call, with defined inputs and outputs. The client can request information as an investigation develops, so the engineer can follow a question without assembling every report in advance.\n\nFor this engineer, that meant examining policies against their own environment.\n\n## The recommendation waiting in the backlog\n\nA developer facing a database recommendation has a similar need, with a code change waiting at the end.\n\nTake an e-commerce application with database recommendations waiting to be implemented. Each one needs someone to find the affected code and work out how the suggested change fits the application.\n\nThe developer picking it up may have been building a feature a moment earlier. Now they need to trace a query through the repository, understand the advice, and check that a rewrite preserves the application’s behavior. An index recommendation creates a different task: preparing a database change.\n\nThis is how useful recommendations end up waiting in a backlog. Following through takes time and familiarity with parts of the system that may sit outside the developer’s everyday work.\n\nCast AI’s Database Optimizer includes [Performance Advisor](https://docs.cast.ai/docs/dbo-performance-advisor), which analyzes database workloads and suggests changes such as query rewrites and indexes. Through CastPilot MCP, a coding agent can retrieve that advice while working with the application’s repository.\n\nThe first implementation challenge is finding the right database. An application may connect directly to it or through a DBO proxy. The MCP tools expose both endpoint types, allowing the agent to match the application’s connection host to a database instance, then identify the logical database within it.\n\nRecommendation retrieval happens in two steps. The agent first fetches summaries containing impact and validation status. It can then retrieve the full SQL and explanation for selected recommendations. This keeps the initial response smaller, at the cost of additional tool calls when more detail is needed.\n\nFor the e-commerce example shown below, the request was deliberately limited: use the Performance Advisor recommendations to edit the checked-out repository, then stop before running validation.\n\nThe agent prepared changes addressing three high-impact recommendations: two query rewrites and an index script. One rewrite moved pagination ahead of the join between orders and users, with the aim of limiting the join to the requested page of orders.\n\n*A Performance Advisor recommendation becomes a proposed edit to the orders query in the demonstration application.*\n\nThe other changes addressed product search: a query rewrite and a SQL initialization script defining trigram indexes. The completion summary identified the affected files and explained what the agent had changed.\n\n*The agent reports two query rewrites and an index script prepared in the repository. As requested, it stops without running validation.*\n\nThe developer now has the recommendations alongside the code intended to address them. The search through the repository and the first edits are already done. They can concentrate on whether the changes fit the application and which checks are needed next.\n\nThat stopping point is a useful implementation choice. A repeatable workflow needs to specify how the agent should test the application, whether it can start local dependencies, and where its task ends. Broader checks take time and may require additional infrastructure. An index script also needs a path into the deployment process for an existing database.\n\nThe developer can also work through unfamiliar database advice along the way. Why is the original query expensive? What does the rewrite change? The explanation helps them complete a task already in front of them.\n\n## Starting from a question\n\nSometimes there is no recommendation yet. There is just a question: why did our costs go up?\n\nThe same connection lets an agent compare cost periods, follow the largest changes into namespaces or allocation groups, and examine a workload that stands out. Each answer informs the next question.\n\nChoosing the right inputs matters here. The comparison needs a clear cluster and equivalent time windows. If the available data leaves part of the increase unexplained, the answer should say so. The engineer then knows where to investigate further.\n\nTeams can build recurring work around this access, too. Their own automation could prepare a weekly rightsizing review or gather evidence about cost changes before a planning meeting. That gives optimization work a regular place in the week, even when nobody remembers to collect the reports.\n\n## How we built CastPilot MCP\n\nMaking that connection trustworthy took a few deliberate decisions, and some of them are visible in how the product behaves. If you are building something similar, the shape of it may be useful.\n\n### One document, built from our own API and its permissions\n\nThe server does not hand-write its tools, and it does not hand-write its access rules either. Both are derived from things we already maintain: the public OpenAPI specification, more than five hundred operations, and the RBAC permission model that decides what a user can do in the Cast AI console. Every operation in that specification maps to the permission groups that grant it, because that is how API access has always worked here. That mapping is not something we bolted on for this project: the same authorization component that checks every ordinary API call resolves each route to the groups that grant it, and our build consumes that same data rather than a copy of it. The result, a generated file mapping tools to permission scopes, is checked in and regenerated on every API change; stale output fails CI. Join the two, and each candidate tool arrives knowing exactly which permissions should unlock it.\n\nGeneration was not the obvious choice from day one; we debated it. The conventional way to give an agent access to an API is to write the tools by hand: one careful wrapper per endpoint, tuned to what an agent should see. It is also how you end up maintaining a second, slowly rotting copy of your API. Every new endpoint, renamed field, or changed behavior needs someone to remember the tool side, and a few releases later the hand-written surface quietly describes the API you used to have. Nobody gets paged when that happens. Generating from the specification flips the dependency direction: the tools are the API’s shadow, rebuilt on every change, and when a read endpoint worth exposing lands, the surface grows with it instead of waiting for someone to write the tool first.\n\nThe join is the engine; the filter is policy. And the filter is not just launch caution. An agent pays for its whole tool list on every turn: each description sits in the context, and the more tools that resemble each other, the worse the model picks between them. Breadth was always going to be a budget, not a goal. For launch we applied the strictest cut: an operation is in the surface only when every permission granting it is a read permission, with a short hand-maintained deny list for the operations that mutate despite living in a read group, and an individual review for each POST endpoint, since several of our most useful reads take a query body and the HTTP method proves nothing. Roughly a fifth of the specification survived. Some things a customer could technically see in the console did not make even that cut: reads of organization management, users, roles, billing, stay out, because a person opening a settings page and an agent enumerating IAM are different kinds of risk. But nothing in the machinery itself is read-only. A different filter over the same join is how a future surface with actions in it gets built, and its authorization rules come from the same source.\n\nOne build over the chosen cut emits three things: the final OpenAPI document, the authorization rules mapping each permission scope to the tools it unlocks, and a CI check that fails the build if the served surface ever drifts from the generated catalogue. The document then gets its agent-facing voice from the curation overlay, which is the next section.\n\n### The overlay, where the spec becomes agent-facing\n\nThe base specification stays the human-facing contract, untouched. Everything an agent needs beyond it lives in a separate document: a curation overlay written in the [OpenAPI Overlay standard](https://spec.openapis.org/overlay/latest.html) rather than a format of our own, so ordinary overlay tooling works on it. Each action targets one operation and updates what the agent will read. This is a real one, lightly trimmed:\n\n```\n- target: $.paths['/v1/cost-reports/clusters/{clusterId}/workload-efficiency'].get\n  update:\n    x-mcp-tool-name: cluster-workload-efficiency\n    x-mcp-args:\n      clusterId:\n        desc: Cluster NAME (e.g. production-eu) or ID. Pass the name directly.\n        resolve:\n          from: /v1/kubernetes/external-clusters\n          match: .items[] | select(.name == $v or .id == $v) | .id\n    x-mcp-response-shape: >-\n      {count: (.count // 0),\n       topWaste: [.items[] | sort_by(.totalCostImpact) | reverse | .[:15][] |\n                  {workload: .workloadName, namespace,\n                   cpuReq: .requests.cpu, cpuUsed: .usage.cpu,\n                   wastedCost: .totalCostImpact}]}\n    description: >-\n      Per-workload requested-vs-used CPU and memory efficiency, ranked by\n      wasted cost. Not the cluster's status snapshot (that is cluster-summary),\n      not raw spend (cluster-cost-report).\n```\n\nFour agent-facing things are happening in that one action. The tool gets a name a model can reason about instead of an API operation ID. The argument says, in the model’s language, that passing a name is fine and the server will sort out the ID. The description does the job of a good colleague: what this tool answers, and just as importantly what it does not answer, naming the tools to reach for instead. And the response shape decides what the answer looks like, which the last section comes back to. Roughly a hundred small lessons like that are the difference between an API an agent navigates well and one it stumbles through.\n\nThe overlay is also where the safety story closes. An overlay action may only touch an operation that already passed the read-only filter; the build rejects one that targets anything else. Curation can subtract from the surface, never add to it. A curation mistake can hide a tool, but it cannot publish a write.\n\nAt build time, the builder folds these actions into the filtered document from the previous step, and the result, one final OpenAPI document, is what the gateway turns into the tool list. The model never sees our base spec and never sees the overlay. It sees what they produce together.\n\n### Standing on agentgateway\n\nServing those tools is a separate job from defining them, and for that job we chose not to write a server of our own. CastPilot MCP runs on [agentgateway](https://agentgateway.dev/), an open-source AI-native proxy that was donated to the Linux Foundation last year and now sits in its [Agentic AI Foundation](https://aaif.io/), the same neutral home as MCP itself. Given an OpenAPI document, it generates one MCP tool per endpoint, validates the sign-in token, filters the tool list by the permissions each caller was actually granted, and forwards the customer’s own token upstream. Those are the exact behaviors we would otherwise have had to build and own.\n\nWe had an unfair advantage in knowing it works: agentgateway already serves production traffic for CAST AI’s own AI agents, so the question was never whether to trust the dependency, only which deployment of it serves our configuration. The alternative shortlist made the decision easy. A hand-written MCP server means writing the authentication layer, per-tool authorization, and every tool definition by hand: weeks of work we would then own, followed by a permanent security surface to own too. Hosted generator services would have meant sending customer infrastructure data through a third-party data plane. Both were easy to decline.\n\nA call through the finished setup takes a short path. Sign-in is the customer’s ordinary Cast AI login in a browser, the tool list that comes back is trimmed to the permissions that login consented to, and the request reaching our API still carries the customer’s own identity, so their existing access rules decide the answer:\n\n### One address, two kinds of tools\n\nA client sees one tool list. It is produced in two places. Most tools are the generated kind: the gateway reads each OpenAPI document at startup and creates one tool per endpoint, by itself. The rest come from a small handwritten backend running next to it, which exists for the tools that are more than an endpoint: the resolver that asks the user to pick between same-named clusters, the guided investigations, and the documentation search below. The gateway configuration is the whole trick, and it is short:\n\n```\nroutes:\n- backends:\n  - mcp:\n      targets:\n      - name: cast-ai-api\n        openapi:                  # tools generated from the spec\n          schema:\n            file: /specs/public.json\n          host: api.cast.ai\n      - name: curated\n        mcp:                      # a second MCP server, multiplexed in\n          host: mcp-public\n          port: 8790\n          path: /mcp\n```\n\nOne entry point, one sign-in, one permission filter in front of both, and the specs are staged from the same release image that deployed the gateway, so the tools served always match the release installed. The boundary between the two sides is enforced rather than convention: when the overlay hands a tool to the handwritten backend, the build drops that operation from the generated document but keeps its name in the permission catalogue. A name exists in exactly one target, the move takes effect in a single release, and the same permission keeps unlocking the tool after it moves.\n\nThe handwritten side earns its keep with tools no specification can generate. Our favorite is the documentation search: the question arrives as an ordinary tool call, and the answer comes from the agent that was already answering Cast AI documentation questions elsewhere in our product. That agent speaks A2A, the Agent2Agent protocol, so a single user question crosses MCP at the front door and A2A in the back room, and still comes back as one tool result. The agent predates the final A2A specification, so a thin compatibility shim translates between the draft it speaks and the current one until its SDK catches up. Reusing an agent that already worked beat rewriting it as a tool.\n\n### Tuned for the agent on the other end\n\nAn API is built for a caller that already knows exactly what it wants. An agent arrives with half a sentence and works outward from there, so three of its usual failure modes got deliberate answers.\n\n**Copying identifiers.** Cast AI identifiers are UUIDs, and models are famously bad at repeating long opaque strings exactly. So where the underlying endpoint wants an ID, the shipped tool accepts a name: “production-eu” resolves to its UUID before the API is touched, which is what the resolve block in the overlay example declares, while an actual UUID skips the lookup entirely. If two clusters share a name, the call does not silently pick one. Clients that support [elicitation](https://modelcontextprotocol.io/specification/2026-07-28/client/elicitation), the protocol’s ask-the-user mechanism, get a real picker inside the conversation, labeled candidates with provider, region and status, and the human chooses; the retried call carries the pick, so the model never spends a turn guessing. In clients without elicitation, the same candidates come back as a text list and the model chooses from it. And if the name matches nothing here but exists in another of your organizations, the picker offers it and the pick is itself the consent: that one call completes in the organization the human selected. The lookups are cached per caller: long sessions stay fast, and one user’s resolved answers never leak into another user’s session.\n\n*CastPilot MCP fully supports MCP elicitation, allowing the agent to ask questions and gather user feedback during the process whenever something is ambiguous.*\n\n**Guessing at formats.** A type declaration is not an instruction. “Must be RFC 3339” is frequently ignored where “for example, 2026-08-06T00:00:00Z” is not, so parameters carry worked examples, and parameters that want an ID say so and point at the list tool that has them.\n\n**Drowning in fields.** API responses are written for completeness, and a model pays attention for every token. The x-mcp-response-shape field in the overlay example is our answer. That endpoint returns a row per workload with everything the console might render; the tool replies with a ranked top fifteen and just the numbers a review actually quotes. On our cluster listing we measured a raw response close to 17 kilobytes, of which about a tenth matched what an investigation actually uses. Five fields per row instead of the full record: same question, much cheaper answer, and adding a shaped tool is an edit to a configuration file, not new code.\n\nThe server also ships a handful of guided investigations: a cost-spike walkthrough, a rightsizing review, a look at commitment coverage. These are [MCP prompts](https://modelcontextprotocol.io/specification/2026-07-28/server/prompts), a small and underrated part of the protocol: besides tools and resources, a server can publish canned conversation starters, which most clients surface like slash commands. Pick the cost-spike one and the session does not open on a blank box; it opens with our written recipe for that investigation, including which tools to reach for and in what order. A first session has somewhere concrete to start, and the tenth session follows the same evidence path as the first.\n\nWe chose prompts over skill bundles for a practical reason. A skill bundle is a directory of markdown instructions that has to be installed and kept current in every user’s environment, and we did not want to maintain our guidance as loose copies scattered across machines we cannot see. A prompt travels with the server, so the guidance rides our release cycle instead of yours. That calculus is shifting: skills have gone server-side in a [finalized protocol extension](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2640), and as clients and our gateway pick it up, we intend to move the richer playbooks there. Until then, prompts carry the load well.\n\nAnd we measure narrowly on purpose: which tools get called, whether they succeed, which clients connect. Never what the tools return.\n\nNone of this is finished, and some of it is more art than we would like. A tool description is a prompt, and models are touchy readers: a reworded sentence can shift which tool gets picked, so there is no spec you can write down once and walk away from; the surface improves through sessions watched and wording fiddled with, and that work does not end at launch. Some limits we chose on purpose. When a name matches a cluster in another of your organizations, the server never switches silently: the picker asks, and the person’s click is what carries the call into that organization. An agent can only ever spend the access its human just granted. Care runs into the small stuff too; the declaration order, tools before resources before prompts, keeps the repeated head of every conversation friendly to client-side prompt caches.\n\nThat is the technical part of the story, and it compresses into a short list for anyone standing up an MCP surface over an existing API: generate the tools from the specification rather than writing them, derive who may see what from the permission model you already have, treat every tool description as a prompt written for a picky reader, and shape every response as if attention were billed by the token. It effectively is.\n\n## Bring it something you’ve been meaning to fix\n\nThe on-call engineer had a practical next step in mind: help preparing policy changes across their fleet, with proposed Terraform changes going through their existing approval process. They had found a use for MCP that they wanted to extend.\n\nCastPilot MCP provides read-only access to Cast AI information. Your agent’s other tools determine how it works with code and configurations. Together, they let you carry an investigation into the place where you can act on it.\n\n[Connect CastPilot MCP to your preferred AI client](https://docs.cast.ai/docs/castpilot-mcp) and bring it something you have been meaning to work through. The policy that needs another look or the database recommendation waiting in your backlog is a good place to start.\n\n## About the authors\n\n### Tomas Kondrotas\n\nEngineering Manager, CastPilot\n\nTomas is an Engineering Manager at Cast AI, where he leads the CastPilot team, bridging the gap between AI agents and Cast AI’s workflows. He started as a Senior Software Engineer in cloud cost optimization and went on to lead the Pricing team, owning everything from accurate cross-cloud price computation to commitment-aware autoscaling across Reserved Instances, Savings Plans, CUDs, Flex CUDs, and enterprise discounts. When not writing code, Tomas likes rock climbing, spending time in nature, and traveling.\n\n### Mack Górski\n\nSenior Product Manager, CastPilot\n\nMack is a Senior Product Manager at Cast AI, where he works on CastPilot after previously focusing on Reporting. Outside work, he spends time with his family and dogs, plays drums, and composes music. He also enjoys cooking, coding, crafts, and exploring AI and data.", "url": "https://wpnews.pro/news/castpilot-mcp-put-your-agent-to-work-on-production-problems", "canonical_source": "https://cast.ai/blog/castpilot-mcp/", "published_at": "2026-11-10 14:28:17+00:00", "updated_at": "2026-11-10 14:52:02.403859+00:00", "lang": "en", "topics": ["ai-agents", "agent-protocols", "ai-tools", "ai-infrastructure", "developer-tools"], "entities": ["Cast AI", "CastPilot MCP", "CastPilot Assistant", "Database Optimizer", "Performance Advisor", "Evictor"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/castpilot-mcp-put-your-agent-to-work-on-production-problems", "markdown": "https://wpnews.pro/news/castpilot-mcp-put-your-agent-to-work-on-production-problems.md", "text": "https://wpnews.pro/news/castpilot-mcp-put-your-agent-to-work-on-production-problems.txt", "jsonld": "https://wpnews.pro/news/castpilot-mcp-put-your-agent-to-work-on-production-problems.jsonld"}}