Why EVIDIQ Ships as an open agent skill MCP, Not a Closed Plugin

A trust layer you can't read is just marketing with a JSON response. That's the line we kept circling back to in 2026 when we were deciding how to ship EVIDIQ. A closed plugin would have bought us friction-free distribution on two or three agent hosts. We chose not to take that deal. Instead we wrote a skill.md, stood up a public MCP server, and mirror-pushed the source under MIT to two repos. The choice looks like it from the product surface — and we want to be specific about why.

Open Agent Skill vs. Closed Plugin: the Actual Difference

An open agent skill MCP is a trust-verification capability exposed as a readable Markdown spec plus a public MCP server with MIT-licensed source, installable into any agent runtime. EVIDIQ ships exactly this way on purpose. The "open" part is the point: anyone can read what the skill does, audit the code, and run it without vendor permission.

Worth being precise about the vocabulary, because marketing teams love conflating these. A "skill" in the 2026 sense is a machine-readable instruction file — typically Markdown — that tells a capable agent what a service does, how to call it, and what it costs. Think of it as README.md but written for an LLM, not for a human. An MCP server is the running endpoint that exposes the actual tools (in our case how_to_install, get_evidiq_skill, and the paid verify_agent) over JSON-RPC. The skill tells the agent the server exists. The server does the work.

A closed plugin, by contrast, is a binary or sandboxed package hosted by a single platform. Your agent talks to it only through that platform's SDK, the source is opaque, the install path is mediated by the marketplace, and the upgrade cadence belongs to the vendor — not to you. The opinions start here: an open agent skill MCP treats the calling agent as a peer; a closed plugin treats it as a customer.

The distinction matters because the agent economy is not in a position where any single runtime will own it. Closing yourself into one of them is a fast way to lose.

What Vendor Lock-In Costs an Agent Builder

[IMAGE_PROMPT: Flat illustration of a single ornate padlock labelled "vendor" with a frustrated developer character on either side unable to reach a stack of open source code on the floor, secondary element of a stylised open book alongside an MIT badge, palettes of dark teal and warm coral on cream background, modern developer-tool aesthetic, no text in image, no real brand logos]

The closer question isn't philosophical — it's operational. What does a closed plugin model actually cost the engineer who has to ship a feature this quarter?

Three costs come up over and over:

• You can't audit it. A plugin runs in your agent's process or a vendor-hosted sandbox. You're trusting the marketplace summary and the review process. In 2026, with agents transacting real money, that's not a defensive posture.
• You can't self-host it. If the vendor's region goes down, your trust check goes with it. An open agent skill MCP can be mirrored inside your own VPC; a closed plugin cannot.
• You can't fork it. Vendors pivot. Vendors shut down. Vendors change pricing tiers overnight. The MIT-licensed mirror at github.com/evidiq/mcp means a hard fork is a git clone away.

Honestly? The big one is the third. We have watched good teams bind themselves to a single agent framework because one critical integration only existed inside that framework's walled garden, and within two years that framework had been deprecated. The math is simple — if the thing that decides whether to transact cannot be replaced, it is not a tool, it is a dependency you negotiated in a moment of convenience.

This is why our EVIDIQ Sentinel docs ship the scoring formula in full: identity*0.3 + capability*0.3 + reputation*0.2 + (100-risk)*0.2. Same inputs, same number. That's not a vendor promise; it's a property of the math, and it is what makes a trust score auditable rather than asserted. Sentinel is the part of our system that runs the live probe against the agent's endpoint — a bounded ~6-second GET checking reachability, TLS, and whether the surface is a machine-readable skill or MCP card. Without that probe, a "trust score" is just vibes with a number on top.

Three Places the Same Code Lives

A skill spec and a server are two artifacts. We keep three copies of them — deliberately — because each one has a different failure mode to absorb, and decoupling them is what makes the open form factor work.

1. evidiq.dev/skill.md — the canonical skill. This is what an LLM fetches when it wants to learn how to call us. Plain Markdown, single file, revision-controlled. The agent reads it once and pins the version it saw; we keep prior versions reachable so an older agent never breaks against a newer spec. Our EVIDIQ docs go deeper on the surrounding spec.
2. github.com/evidiq/evidiq-skill — the spec source. Same content as skill.md, but as a repo so changes are diff-able, review-able, and tag-able. MIT license. If you want to vendor a fork with a different paid endpoint, this is where you start.
3. github.com/evidiq/mcp — the running server. The actual Python MCP server that exposes how_to_install, get_evidiq_skill, and verify_agent. Same license. Same repo, mirrored. The two repos stay separate on purpose: a change to the spec doesn't have to ship with a server change, and vice versa.

Coupling them is how closed plugins happen accidentally. Each artifact points at the others. The skill reads its own server URL; the server README references the skill. If you pull any one of them, you can reach the other two. We don't believe in a single source of truth that nobody can read — we believe in three redundant, MIT-licensed, diff-able ones.

A small but important detail: the spec, the repo, and the runtime intentionally disagree on little things. The skill file mentions the latest server endpoint. The repo README can lag behind — that's the human-facing changelog. The server pins a minimum-spec version it understands. If a downstream agent pulls an old skill.md, it still works because the server advertises backward compatibility. None of that flexibility is achievable in a single packaged plugin.

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

[IMAGE_PROMPT: Split-screen flat illustration: left half shows a clean bash terminal with a one-line install command for an MCP skill targeting Claude Code, right half shows the same skill being loaded into a custom LangChain agent graph, both versions execute successfully with green checkmark, arrow lines converging on a shared central EVIDIQ trust icon at the middle, palette of slate blue and amber accents on cream background, no real brand logos, no text in image]

Here's where this design pays for itself. You don't need our permission, our SDK, or a marketplace account. You install the same skill into whatever runtime hosts your agent — three concrete one-liners, as of this article in 2026:

• Claude Code. Add the MCP server to your .mcp.json and the skill URL to your project's CLAUDE.md. Restart the session. The agent fetches the skill, learns the tools, and the trust check is one function call away.
• Cursor. Cursor's 2026 release reads MCP servers natively. Point it at https://evidiq.dev/mcp and add the skill URL to its rules.
• A custom LangChain, CrewAI, or hand-rolled agent. Fetch skill.md with httpx, parse the skill manifest, and instantiate the MCP transport against our public endpoint. You literally write the integration yourself — and that's the point.

A closed plugin cannot do this. A plugin is structurally tied to the marketplace that distributes it; you cannot run a Cursor plugin from inside LangChain without the plugin author shipping a Cursor-specific build. The open agent skill MCP form factor was designed for this exact situation: heterogeneous agents, heterogeneous runtimes, one trust layer. Our EVIDIQ Operator docs walk through the LangChain wiring if you want a concrete example, including how to capture the EIP-191 signed report and verify the signer address offline.

Worth noting: the install tools (how_to_install and get_evidiq_skill) are free per call. Only verify_agent is paid — settled in USDT0 on X Layer via the x402 scheme with EIP-3009 transferWithAuthorization. So you can wire the trust check in, dry-run it against your own dummy agents to make sure your fallback path is correct, and only pay when you actually need a verdict on a counterparty. We don't charge for inspection; we charge for attestation.