Why EVIDIQ Is an Open Agent Skill MCP, Not a Closed Plugin

Open Agent Skill vs. Closed Plugin: the Actual Difference

Picture this: your agent is about to wire funds to another agent's wallet. You want verification that doesn't require permission and whose math you can read. That's an open agent skill MCP — a machine-readable spec, usually a skill.md plus a public MCP server, installable in one line, forkable under MIT. EVIDIQ ships exactly that at evidiq.dev/skill.md.

The plugin world runs on "click Install, accept the EULA, hope the vendor behaves." Open skills don't. Three things are bundled inside every closed plugin: distribution, runtime, and the verification logic itself. Install it from a marketplace, it loads into one specific runtime, and you have no real way to inspect what it does once it's running. Want to know if it's phoning home? You don't. Want to fork it because the company pivots? You can't. Want to run it inside a customer's VPC? Sorry, no.

Open skills split those three things apart. The spec lives on disk as plain markdown. The runtime is whatever the developer chose. The verification logic is reproducible — you can read the code that computes the trust score and check the math yourself.

We chose the second path deliberately when we started EVIDIQ in 2026. The short version: if your agent makes trust decisions about other agents, the math behind those decisions shouldn't be a black box, and the install path shouldn't be a marketplace you don't control. That's the bet behind shipping EVIDIQ as an open agent skill MCP rather than another marketplace plugin.

What Vendor Lock-In Costs an Agent Builder

The cost isn't theoretical. We've watched teams ship agents into production only to discover their trust layer was a black box — and then spend three months re-architecting around it. Here are the concrete bills that come due:

• Audit cost. Closed plugins ship as compiled blobs or, worse, as a manifest that points at a remote server. You can't point a static analyzer at them. You can't read what the verifier actually checks. For regulated workloads — finance, healthcare, anything touching PII — that alone disqualifies them.
• Migration cost. When the vendor shifts pricing, sunsets a region, or pivots the product entirely, your agent stops working. Worse, your trust log becomes non-reproducible, because the verification math lived in their cloud. We've seen this exact failure mode twice in 2026 already.
• Self-host cost. No closed plugin can run inside an air-gapped cluster, a customer's VPC, or a sovereign cloud. The minute your customer asks "does this call home?" you have to say yes — and the deal's gone.

Open skills invert all three. Our probe code lives on GitHub under MIT. You can run it on your laptop, in CI, or against a fork of the MCP server. The score formula — identity*0.3 + capability*0.3 + reputation*0.2 + (100-risk)*0.2 — is right there in the source, line by line.

Determinism means anyone with the same inputs gets the same number. An auditor can rerun your verification six months later and confirm the verdict didn't change because the vendor tweaked an opaque model. Closed plugins structurally can't offer that.

For teams building serious agent infrastructure in 2026, this is the kind of property that shows up in procurement reviews. It's also why we recommend reading the EVIDIQ Sentinel docs before picking a verification approach — Sentinel is the live probe our skill relies on, and it's documented in the open.

Three Places the Same Code Lives

One question developers keep asking us: "if it's all open, where exactly do I look?" Fair question. We split the code into three repos on purpose, because each audience reads the code for a different reason. None of it is hidden. None of it requires a login.

1. evidiq.dev/skill.md — the spec. This is what an agent reads. Plain markdown declaring the inputs (agent address, declared capabilities, endpoint URL) and the outputs (a 0–100 trust score plus a recommendation: proceed, proceed_with_escrow, caution, or do_not_proceed). Not code — a contract. If you're integrating EVIDIQ into your own orchestrator, start here.
2. The MCP server repo at github.com/evidiq/mcp — the runtime. The actual Model Context Protocol server exposing how_to_install, get_evidiq_skill, and verify_agent. We mirror it on evidiq.dev/mcp for hosted convenience, but the source is MIT-licensed and self-hostable. The EVIDIQ docs cover the API surface in detail.
3. The skill spec repo at github.com/evidiq/evidiq-skill — the installer surface. The package your claude-code or cursor CLI pulls when you run the install one-liner. Bundles skill.md plus bootstrap logic.

Why three? Because the contract (skill.md) shouldn't change every time we refactor the server. Because the server shouldn't have to live next to a Claude-specific installer. Because when we want to add a third runtime — a LangGraph deployment, say, or an in-house orchestrator — the third repo is where the wiring goes, not the core math.

This separation also lets us add things like EVIDIQ Notary without polluting the basic skill. Notary is the tamper-evident layer — hashes the canonical report, anchors the evidence on 0G Storage mainnet, optionally runs an AI risk analysis on 0G Compute, and signs the verdict with the EVIDIQ key using EIP-191. Lives in its own package, gets pulled in only when you want it.

Honest take: we considered folding all three into a single repo to look tidier. We didn't, because the moment you split "what the agent reads" from "what the runtime executes" from "what the installer copies", debugging gets easier and integrations get cleaner. The duplication is intentional, and it's small.

Installing It Into an Agent You Don't Control the Runtime Of

Here's the practical test of an open agent skill MCP: can someone else install it into an agent you don't maintain? If the answer is "yes, in one line, without asking us", the design has done its job.

For Claude Code:

npx evidiq-skill install

For Cursor, you paste the MCP endpoint — https://evidiq.dev/mcp — into the MCP settings UI, and it picks up how_to_install and get_evidiq_skill automatically.

On the LangChain side, you pip install evidiq-skill, point at the MCP server, and wrap the result in a tool. The whole integration is a few lines of Python.

Why does this even work? Because the skill is a contract plus an HTTP endpoint — not a proprietary binary. The MCP protocol is documented, the JSON shapes are documented, and the score formula is documented. A closed plugin can't do this for the simple reason that it ships as a vendor-specific blob only one runtime knows how to load.

When we built the probe — the bounded ~6-second GET that checks TLS, reachability, and whether the agent serves a machine-readable surface — we kept it intentionally minimal. Same reason: anything heavier and it stops being installable into edge agents or constrained devices. The skill has to be cheap to call, or nobody calls it.

There's a real consequence here that isn't obvious until you've shipped: a closed plugin makes your agent dependent on a vendor's pricing page. An open agent skill MCP makes your agent dependent on a spec. Specs don't raise prices. Specs don't get acquired and sunset. Specs don't phone home unless you wire them to.

If you're running EVIDIQ inside your own infrastructure today, the EVIDIQ Operator docs walk through self-hosting the MCP server, pointing it at your own endpoint whitelist, and plugging the result into whatever orchestrator you already use. Same trust score, your hardware.