Query Your Fleet's AI Activity From Claude: Anomity's MCP Server Is Live
- The Anomity MCP server is live in the Claude directory. Add the connector, sign in, and ask your fleet a question in plain English.
- No dashboard, no filters. Which of our machines can reach production data through an agent? is now one sentence instead of ten minutes and three screens.
- Ten views: fleet status, devices, findings, MCP servers by trust level, capability surface, exposed secrets, skill risk, AI accounts, compliance readiness across SOC 2, ISO 42001, NIST AI RMF and the EU AI Act, and the 90-day audit trail.
- Every tool is read-only. Nothing can change a policy, resolve a finding or touch a device, so connecting it cannot make your posture worse.
- It sees exactly what you see. Each person signs in as themselves and inherits their existing role, so the connector cannot surface anything they could not already open.
- Not Claude-only. Any MCP client works, ChatGPT included.
- Available to every Anomity customer today at no extra cost. Not a customer yet? Book a demo and we will show it against real data.
An alert lands. You want to know which machines are running the MCP server it came from, whether any of them also hold a plaintext credential, and whether any of that changed in the last week. The data exists. Your team has it. It is three screens and a set of filters away, and that distance is the reason the question often does not get asked at all.
The Anomity MCP server is now live in the Claude directory. Add the connector, sign in with your existing Anomity account, and ask.
https://app.anomity.ai/mcpWhat your team can ask on day one
No tool names, no query language, no new console to learn. Questions like:
- Which unknown MCP servers are installed on the most devices?
- What changed on our fleet in the last seven days, and who changed it?
- Show me every open critical finding and the devices it sits on.
- Where are we failing EU AI Act requirements?
- Which of our machines can reach production data through an agent?
That last one is the interesting case. No single dashboard view answers it, because the answer lives in the capability surface crossed with the device list. The assistant combines them for you. Questions that used to be a person, a spreadsheet and an afternoon become a sentence.
Where it earns its keep
| Situation | What changes |
|---|---|
| Investigating an alert | You stay in the tool you are already working in. No context switch to the console and back, which is where the follow-up question usually gets dropped. |
| Preparing evidence for an audit | Compliance readiness and the 90-day audit trail come back as answers you can paste, mapped to the controls each finding affects. |
| The weekly AI activity report | Ask for it instead of assembling it. What was added, what was removed, what got riskier. |
| Answering the board | The cross-cutting questions leadership asks are exactly the ones a dashboard is worst at and an assistant is good at. |
The ten views behind it
Everything your team already sees in the console, available as a question:
- Fleet overview - device counts by status, online, stale and offline, plus open and critical finding counts
- Devices - every managed machine, filterable by that same status
- Findings - policy violations by status: open, acknowledged, resolved
- MCP inventory - every MCP server detected across managed devices, grouped official, community or unknown-origin
- Capability surface - inferred permissions across MCP servers, flagging overprivileged devices and risky combinations
- Secret exposure - plaintext credentials in AI configuration files, ranked by severity and pattern type, never by value
- Skill and instruction-file risk - CLAUDE.md-class files flagged by on-device scanning for prompt injection, exfiltration patterns and unsafe directives
- AI accounts - which devices use corporate versus personal accounts, plus data-sharing and BYOK settings
- Compliance status - readiness across SOC 2, ISO 42001, NIST AI RMF and the EU AI Act
- Audit trail - 90 days of change history, every MCP server added or removed, every permission modified, on every device
Safe to connect, by design
Attaching an AI assistant to your security platform is a reasonable thing to be cautious about. Three properties make this one a low-risk adoption:
Every tool is read-only. Nothing the connector exposes can change a policy, resolve a finding, revoke a grant or touch a device. This is not a v1 limitation we plan to relax casually. An assistant is reachable by whatever text reaches it, including text from a web page or a repository issue, which is the mechanism behind indirect prompt injection. Against a read-only connector the worst case is data shown to someone already entitled to see it. Against a write-capable one, the worst case is an attacker's text talking your assistant into dismissing the finding that would have caught them. A security tool that can be argued out of its own findings is worse than no tool.
It sees exactly what you see. Sign-in is required and authorization is per user, not per organization. Each person authenticates as themselves and inherits their existing role, so the tool list is filtered before anything is registered. Connecting the assistant grants it nothing you did not already have.
Nothing leaves unless you ask. Anomity never pushes data to an assistant. A query travels only when someone in your organization initiates it, and the connector inherits the platform's collection limits, so it cannot return what was never collected. Secrets come back as a type, a severity and a location, never a value.
One thing we would rather say ourselves
Our listing sits at the Community tier, which Anthropic labels plainly: automated review, not verified by Anthropic, only connect developers you trust.
We are quoting that in our own announcement on purpose. Anomity exists because organizations kept treating presence in a registry as evidence that someone had checked, and our Skill Risk Index exists because that assumption does not survive contact with the data. Having made that argument about public MCP registries, we are not going to invite you to read our own directory entry as a seal of approval. Evaluate the connector on what it can and cannot do. That is the standard we would want applied to anything you attach to your fleet, ours included, and it is the same reasoning we brought to enterprise-managed MCP connectors and to MCP security generally.
Getting it
Included for every Anomity customer at no extra cost. Add the connector URL above, sign in, and the tools appear filtered to your role. The documentation covers the endpoint, the sign-in flow, what each view returns and what the connector deliberately never returns.
Not a customer yet? Book a demo and we will stand up an environment so you can ask your own questions against real data.
Frequently asked questions
What can I actually ask it?
Anything you would otherwise build a dashboard filter for. The four that come up most: which unknown MCP servers are installed on the most devices, what changed on our fleet in the last seven days and who changed it, show me every open critical finding and the devices it sits on, and where are we failing EU AI Act requirements. It also handles the harder cross-cutting questions that no single dashboard view answers, like which machines can reach production data through an agent, because the assistant can combine the capability surface with the device list rather than making you do it by hand.
Is it safe to connect to our security platform?
It is read-only, entirely. All ten tools are queries: there is no tool that changes a policy, resolves or dismisses a finding, revokes an OAuth grant, enrolls or removes a device, or writes anything at all. This is enforced in the tool registry rather than left to convention, and each tool declares its read-only status explicitly so the assistant can show you what a call will do before it runs. Connecting the server cannot change your posture, only describe it.
Can it see more than the person asking?
No. Authorization is per user rather than per organization, and sign-in is required. Each person signs in as themselves, the connector resolves that identity to the same role the dashboard uses, and the tool list is filtered by that role before anything is registered. An analyst sees the findings and audit-trail tools; a viewer does not. The role ladder is read from one shared source rather than copied into the MCP layer, so the connector cannot drift from the dashboard and start showing someone more than they should see.
Does connecting it send our security data to Anthropic?
Only what you ask for, when you ask for it. Nothing is sent unless an authorized user in your organization initiates a query, and Anomity never pushes data to an assistant on its own. The connector also inherits the platform's collection limits, so it cannot return what Anomity never collected: secrets come back as a type, a severity and a location, never a value, and skill scanning returns a rule identifier rather than the text it matched.
Which assistants can connect to it?
Any MCP client that supports remote servers over Streamable HTTP with OAuth 2.0. Claude and ChatGPT both qualify. The directory listing makes it a one-click connector in Claude, but the server is not Claude-specific and discovery is standards-based, so a conforming client finds the sign-in endpoint on its own with no Anomity-specific configuration.
What does the Community label on the listing mean?
Anthropic groups directory connectors into tiers, and Community is the tier that has passed automated review rather than Anthropic's own verification. The directory says so directly: community connectors have undergone automated reviews but are not verified by Anthropic, and you should only connect developers you trust. That applies to our listing exactly as it applies to every other one at that tier, which is why we would rather you evaluated the connector on what it can and cannot do than on where it is listed.
How much does it cost and how do I get it?
It is included for every Anomity customer at no extra cost. Add the connector in Claude or any other MCP client, sign in with your existing Anomity account, and the tools appear filtered to your role. The documentation covers the endpoint, the sign-in flow, what each view returns and what the connector deliberately never returns. If you are not a customer yet, book a demo and we will set you up with an environment so you can try it against real data.
