So I asked my agent instead…

Evo already knows which AI Assets your teams pulled into your repos, which MCP servers and skills are sitting on your developer machines, which of them carry risk, and which policies they break. Getting to any of it created friction: you leave the tool you are working in, filter a UI, export a CSV, and rebuild the chart you built last quarter, every time it’s needed.

Today we're announcing the Evo MCP server, which puts every one of those answers one question away, inside the agent harness you already work in. So, I asked my agent instead.

Play Video: So I asked my agent instead… - video 1

What does the Evo MCP server connect to?

The Evo MCP server lets you discover AI assets in your repositories and on your developer machines, the associated risk data, and your policies and open violations. To get set up, follow the instructions in our documentation.

Connect from Cursor:

1{
2  "mcpServers": {
3    "Evo MCP": {
4      "url": "https://evo.snyk.io/mcp"
5    }
6  }
7}

Connect from Claude Code:

1claude mcp add --scope user --transport http evo https://evo.snyk.io/mcp/

That is the install. It is a remote server, so nothing lands on your machine, and it has no access to your filesystem.

The MCP Server supports the following:

• Inventory. The AI assets discovered across your environment, with their assessed risk.

• Policies and issues. The rules that govern AI usage, and the issues raised when assets violate them.

• Information. How your AI security posture changes over time.

Building an AI asset report with the Evo MCP server

To use Evo MCP, I started with the scope first. I asked, “How many AI assets do we have, broken down by type and by source?” What I received in return were the estate: models, agents, MCP servers, skills, repositories, and developer machines.

The source is especially interesting. Evo distinguishes what is referenced in a repository from what is configured on a developer machine, and it tells you which machine. So the question is not only which MCP servers and skills exist in your organization, but whose laptop each one is sitting on. That per-machine view is hard to get from a dashboard export, and it is what turns a risky server from a list entry into a named machine someone owns.

Then I narrowed it down: “I want models grouped by vendor and country of origin, broken down by license type and whether they are self-hostable, and open violations grouped by policy and severity.”

Finally came the part I would normally lose an afternoon to: “Build me a dashboard from this, with a chart for each section.” It was assembled from the four results already in the session, without querying anything again. This means I can regenerate it whenever I ask.

Writing an Evo policy against your actual inventory

You can use the MCP server to create a policy against your inventory, starting with a question I could check: How many skills in our estate score 500 or above for insecure credential handling?

Then I asked to see those skills ordered by score. From here, as Evo, to create a policy to identify skills in my estate that score 500 or above for insecure credential handling with appropriate remediation notes. Back came the same violations I queried earlier. Prediction and result matched, which is the whole point of asking the estate before you write the rule.

Turning Evo violations into tickets, one per team

I pulled the open violations for a policy, each one carrying its affected asset, that asset’s location, and the policy's remediation notes. Then I asked to group them by repository, because one ticket per violation is how security work gets ignored, and one ticket per responsible team is how it gets done. Once they were grouped, I asked for the tickets to be created, with the asset list and remediation notes already included in each description.

That last step ran through a ticketing MCP server already configured in my client, alongside the Evo MCP Server. Snyk does not provide or support those servers, and what the flow can do depends on the permissions you have granted to your ticketing MCP Server, like Jira or ServiceNow. The issues Evo caught now became actions in your systems, without needing to build an integration for them.

How the Evo MCP server is secured

Everything above depends on an agent being allowed to query and change your security data, which is exactly the kind of access Evo exists to scrutinize. The failure mode I expected from a language model in front of an inventory was a confident wrong number. Three constraints are what stop it.

1. It runs as you

Over OAuth, with your identity and your permissions. What you can do through the server is exactly what you can do in the Evo UI. Of the eight tools, six read and two write, and if your role does not allow policy editing, the two write tools are not listed for you.

2. A write needs real approval.

When an agent tries to create or update a policy, Evo previews the change and sends an approval request to your client.

3. The agent cannot guess at your schema

Each query tool works against a query schema, which returns the exact fields available to you and their meanings. Fields you are not entitled to query are not returned and are not in the tool's input schema.

Ask it something

Wondering what your own estate looks like from inside the client you already work in? Point yours at https://evo.snyk.io/mcp and ask.