A few weeks ago, we published Our Approach to AI. In it, we said we'd rather you remember what we built than what we said. That we'd ship AI that moves the needle, not AI that wins a press cycle.
Today we're putting that into practice. We're publicly releasing the Kevel MCP Server: a way for AI assistants to read, write, and operate across the Kevel platform directly.
You can provide your teams with the integrations to:
- Increase AdOps operational efficiency: Provide Kevel tooling directly where your AdOps team is already engaging with agents, enable them with campaign setup, reporting and analysis capabilities.
- Outsource complex tasks to agents: Run analysis across your entire inventory in seconds. What used to take your senior team hours now happens in a single conversation.
- Spot yield opportunities: Surface patterns across your inventory that dashboards alone would never show. Identify underperforming placements, untapped segments, and budget gaps.
- Guide your advertisers to stronger strategies: Turn those insights into action. Show advertisers where to shift budget, which audiences to prioritise, and why.
MCP enables people who aren't writing code to get the same benefits of Kevel’s API.
What is MCP?
MCP, or Model Context Protocol, is an open standard created by Anthropic that lets AI tools connect to live software platforms. Think of it as a universal adapter between AI assistants like Claude and the systems your team already uses every day.
Without MCP, an AI assistant is working in the dark. It can answer general questions and help draft copy, but it has no direct connection to the platforms your team actually works in. It does not know what campaigns you are running, how they are performing, or what inventory you have available. Every useful answer requires your team to manually pull the data first.
With MCP, that changes. The assistant can pull your actual campaign data, run a forecast, check delivery against pacing goals, or update a flight's targeting, all through the same conversational interface, without anyone switching screens or writing a query.
Why Kevel, and why now
Kevel is API-first. Agents are a natural extension of that.
Our customers have been building automation on top of our APIs for years, whether that is custom scripts, internal tooling, or scheduled jobs running in the background. Engineering teams were already pulling Kevel data into AI development tools as part of their day-to-day work. MCP formalises that capability and makes it accessible to teams who are not writing code.
We have also been deliberate about when to release this. The Kevel MCP Server went through an early access phase while we validated two things: that it genuinely improves efficiency for the teams using it, and that it does so reliably. That included working through some hard questions about what happens when agents operate on live campaign infrastructure — questions we think every retail media operator should be asking before they deploy any MCP integration.
What you can do with it
The Kevel MCP Server covers campaign management, reporting, forecasting, the Decision API, inventory, targeting, catalog, and async jobs. In total, it exposes over 100 tools across 10 API surfaces to support a wide variety of use cases and capabilities, with both read and write support.
The read side is where most teams will start. Say you are an account lead preparing for a quarterly business review. Instead of pulling reports across multiple screens and assembling a summary manually, you ask an AI assistant for a performance breakdown across every advertiser in your portfolio. It comes back in seconds, structured and ready to use. Or you want to know which flights have segment targeting rules that might be limiting delivery. Rather than clicking through each one, you ask the question and get the answer drawn from live data.
The write side is where the efficiency gains compound. An agent that can not only surface a pacing issue but act on it, adjusting a flight's budget or updating targeting parameters directly, removes a class of manual work that currently sits with your AdOps team. That same capability requires the most careful thought before deployment, which is why we have built explicit safeguards and logging into every write operation.
These workflows do not have to stay within Kevel either. Because MCP is an open standard, an AI assistant connected to Kevel can also connect to Slack, your CRM, email, or other platforms through their own MCP servers. That quarterly review prep could pull in recent client correspondence, flag open action items, and draft an agenda. One conversation, multiple systems.
Getting started
The Kevel MCP Server authenticates using your existing Kevel API credentials. Consistent with our approach across all of Kevel's AI, we don't cross-train models using your data. Your data is only used to uniquely benefit you.
Network admins control which networks can authenticate, and write support can be disabled upon request. Networks can also operate in a read-only mode for added safety.
The Kevel MCP Server is available now for all Kevel customers. No additional enablement is required. If you're evaluating Kevel and want to see the MCP Server in action, get onboarded, contact us.
Questions to ask any vendor announcing an MCP server:
- How long did it take to develop the MCP server, and how did you roll this out to customers?
- What percentage of your API surface does the MCP server actually cover? Is it read-only, or does it support writes too?
- Can we run in read-only mode while we evaluate? What does the path to enabling writes look like?
- What are the most common use cases your customers are using this for today?
- How does this integrate with other tools our team already uses, like Slack or our CRM?
- What does onboarding look like? How long until our team is actually using it?
- What logging and audit trail exists for actions taken by agents? Can we trace what an agent changed and when?
- Is the retailer's data used to train or improve any shared models, or does it stay isolated to their own environment?
Questions to ask your own team before deploying any MCP integration
These are not vendor questions. They are operational decisions your organisation needs to make before agents start touching live campaign infrastructure.
- Who in our organisation has authority to approve write access for agents? Is this a technical decision, a commercial decision, or both?
- Which workflows are we comfortable automating fully, and which ones require a human in the loop before an action is confirmed? Have we mapped that boundary explicitly?
- What is our rollback plan if an agent makes an unintended change to a live campaign? How quickly can we identify it, reverse it, and communicate it to the affected advertiser?
- How will we explain agent-assisted changes to advertisers? If a campaign is adjusted automatically based on an agent recommendation, what transparency do we owe them and how do we provide it?
- Do we have clear data governance policies for what information agents are permitted to access? Have those policies been reviewed by legal or compliance?
- Have we tested agent workflows in a staging environment before deploying on live inventory? What does our acceptance criteria look like before we go live?
- Who owns the ongoing monitoring of agent activity in our organisation? Is there a named person or team responsible for reviewing agent logs regularly?
Ash Boxshall
