DEV Community

Cover image for The ZizkaDB MCP Server Scores 100/100 on AddonAudit: What It Means and Why MCP Audits Matter
Mir Arshad Ali Talpur
Mir Arshad Ali Talpur

Posted on

The ZizkaDB MCP Server Scores 100/100 on AddonAudit: What It Means and Why MCP Audits Matter

The ZizkaDB MCP server has a 100/100 metadata score on AddonAudit, an independent directory that sandboxes and checks MCP servers. Its listing carries Audited status, and every audit check on version 0.1.12 passed. That is a result we can point to, and anyone can verify it on the public page. Here is what it covers, what it does not, and why it matters.

What AddonAudit checked

AddonAudit sandboxes popular add-ons and publishes the results. For our server, it audited version 0.1.12 of the zizkadb-mcp package from PyPI on 2 November 2026. Here is what its page reports:

Check Result
Version Pinned to zizkadb-mcp 0.1.12
Known vulnerabilities No critical, high, medium, or low advisories returned
License MIT
Install scripts No preinstall, install, postinstall, or prepare script
Credential patterns None found in the published package
Package size 11.0 KB
Maintainer activity Active within the last few days
Sandbox MCP handshake completed with 13 tools listed, with network disabled

Each audit check is marked Pass. The repository was also marked as active within the last 180 days, with a recognized license identifier and high metadata quality.

What the 100/100 means, and what it does not

If you quote the score, quote it as AddonAudit does. The page states that the score of 100 uses public metadata only, and that it is separate from the audit tier. It describes the sandbox run as an automated smoke test and not a security guarantee. It also says that compatibility with clients such as Claude, Cursor, and Codex is based on the listing and package type, and is not a certification from those products.

So the honest reading is this:

What it does show: the package is small, openly licensed, free of install-time scripts, free of known advisories, actively maintained, pinned to a specific version, and starts cleanly in an isolated sandbox without network access.
What it does not show: that the code is free of bugs, that no future version could introduce a problem, or that the tools behave safely in every environment. The tool count was measured offline, and some servers expose more tools when connected.

We think that framing is what gives the score credibility. A reviewer who sees a clear list of passed checks with stated limits can decide how much weight to give it, and nothing here needs defending. The page also says that payment does not change a listing score, which is the property you want from any directory that people use to decide what to install.

Why this matters: MCP turned tools into a supply chain

The Model Context Protocol lets an AI agent call tools on a server. That is the point of it, and it is also the risk. Installing an MCP server means running someone else's code next to your agent, often with access to files, credentials, and internal systems.

The security community has been direct about this. The OWASP MCP Security Cheat Sheet describes MCP as a new attack surface in which language models decide which tools to call and with what parameters, combining prompt injection, supply chain attacks, and confused deputy problems. The Cloud Security Alliance notes that the protocol specification offers no native defenses against tool poisoning, rug pull attacks, or cross-server tool shadowing, and that package impersonation and repository compromise are early, observable routes for attackers. Its 2025 incident list includes prompt injection against the GitHub MCP server, unauthenticated remote code execution in an MCP developer tool, and malicious npm packages.

The scale is worth noting too. PointGuard AI applied its scoring method to 36,527 public MCP servers on GitHub and headlined that about two thirds are not safe for enterprise use. One academic study, as summarized by security writers, found tool poisoning in about 5.5 percent of 1,899 servers examined. These are third party figures from different methods, so treat them as direction and not as precise measurement. The direction is consistent: most servers have not been vetted, and buyers know it.

Why it matters for a product that stores audit evidence

ZizkaDB is an audit trail and causal database for AI agents. Our MCP server lets an agent, or a developer inside an editor, log events, search memory, trace why a step happened, and verify the integrity chain. That puts the server close to some of the most sensitive material a team has: what its agents did and why.

If the component that records the evidence is itself a risk, the whole idea collapses. An audit trail is only useful if the people relying on it can trust the thing writing to it. This is why we care about boring properties: a tiny package, no install scripts, a permissive license anyone can read, pinned versions, and no secrets in the artifact.

What this means if you are evaluating us

For a security reviewer or procurement team, an external audit page changes the conversation in three ways:

It shortens the first pass. Basic hygiene questions about licensing, install scripts, advisories, and secrets have a public answer you can check yourself.
It gives you something to pin. The result applies to a specific version. Pin that version in your configuration and review upgrades before accepting them, which is also what the OWASP guidance recommends.
It focuses the real review. With hygiene covered, you can spend your time on what only you can judge: which credentials the server gets, what network it can reach, and which tool calls need human approval.

A minimal, pinned configuration looks like this:

json
{
"mcpServers": {
"zizkadb": {
"command": "uvx",
"args": ["zizkadb-mcp==0.1.12"],
"env": { "ZIZKADB_HOST": "http://localhost:8000" }
}
}
}
What we are not claiming

We are not claiming that a 100/100 listing replaces your own review, a penetration test, or a formal certification. We are not claiming perfect security, because no one honest can. The result covers one version on one date, and every new release needs fresh scrutiny. We also have no information about how AddonAudit weighs its checks beyond what its page states, so we describe only what the page reports.

What we will do next

We will keep releases small and keep the package free of install-time scripts. We will pin and name the version in our documentation, and we will ask for a re-check when we ship a meaningful change. If your security team finds something the audit missed, we want to hear about it directly.

Want to test ZizkaDB on your agent? Try our open source version here: https://github.com/ZIZKA-AI-SL/ZizkaDB

Interested in a design partnership? Fill in the form on our site or reach me directly at founder@zizka.ai

Sources: ZizkaDB MCP server on AddonAudit · OWASP MCP Security Cheat Sheet · Cloud Security Alliance, MCP Security Crisis · Cloud Security Alliance, Agentic MCP Security Best Practices · PointGuard AI, 36,500 public MCP servers · Practical DevSecOps, MCP Security Statistics 2026 · zizkadb-mcp on PyPI

Top comments (0)