Why EVIDIQ Ships as an Open Agent Skill MCP — Not a Closed Plugin

Picture this: your agent just paid 47 USDC to an endpoint that looked legitimate, served a perfect machine-readable manifest, and quoted a reasonable price. Twelve minutes later the wallet is empty and the operator's site is offline. There's no receipt, no audit trail, and no way to claw it back — because the trust score the closed plugin gave you was a black box.

We built EVIDIQ to never put you in that position. And the way we ship it is the whole point.

Open Agent Skill vs. Closed Plugin: the Actual Difference

An open agent skill MCP is a readable spec — like EVIDIQ's /skill.md — that any runtime can fetch and install without a vendor SDK. EVIDIQ ships as an open agent skill MCP with MIT-licensed source and a public MCP server, so builders can audit, self-host, or fork the trust layer that scores counterparties. The closed-plugin alternative binds you to one vendor.

The line between an open skill and a closed plugin isn't philosophical. It shows up in concrete things you can and cannot do.

This spec lives at a well-known URL — we use evidiq.dev/skill.md — and any agent runtime can fetch, parse, and install it. A closed plugin is the opposite: a binary or SDK that only the vendor's runtime knows how to load. The first can be audited in your text editor. The second is a black box wrapped in a license agreement.

Three things separate them in practice:

• Install path: an open skill can be loaded with a one-liner or a manifest URL — no SDK account, no API key gate. A closed plugin needs a vendor-approved installer and usually a registered application.
• Auditability: a skill.md file is something a security engineer can read, diff, and PR against. A closed plugin's internals are typically obfuscated and bound by a license that forbids reverse engineering.
• Portability: an open agent skill MCP works in Claude Code, Cursor, a homegrown LangChain agent, or whatever runtime shows up next year. A closed plugin works where the vendor's runtime exists — and nowhere else.

Honestly? Most of the "agent platforms" shipping in 2026 are just closed plugins with a marketing site. The day you want to take your scoring logic and run it on a different runtime, you can't.

What Vendor Lock-In Costs an Agent Builder

[IMAGE_PROMPT: A flat editorial illustration showing a small developer character trapped inside a translucent padlock made of interlocking gears and code blocks, with a giant vendor logo silhouette looming in the background. Stacks of code and license agreements float around the lock. Color palette: deep navy, soft red-orange, and muted teal accents. No real brand logos, no readable text.]

The math on lock-in is brutal once you write it down. Imagine you wired your treasury agent to a closed-plugin trust gate in 2026. By 2026 three things have likely happened:

1. The vendor pivoted from "trust scoring" to "agent orchestration," and your trust gate got buried under a rebrand.
2. A CVE landed on the plugin's native dependency, and the vendor shipped a fix three weeks later — after your agent had already approved a malicious counterparty.
3. You tried to move to a cheaper runtime and discovered the plugin's installer refuses to load anywhere else.

Each of those has a price. The pivot costs you a re-integration sprint. The CVE costs you a postmortem and probably some lost funds. The migration costs you the whole trust layer, because the plugin's decision logic never lived anywhere you could read.

Here's the thing: in the agent economy, the trust layer is the part you absolutely cannot afford to rent from someone who can revoke it. If you need to self-host the live endpoint probe on your own infrastructure, our EVIDIQ Sentinel docs walk through the deployment. The EVIDIQ Operator docs cover the policy side — what to do with a proceed_with_escrow verdict, how to gate a payment on a 70+ score, and how to log the audit trail yourself.

Closed plugins make all three of those steps impossible without a sales call.

Three Places the Same Code Lives

When you point your agent at EVIDIQ, you're pulling from three repositories that we keep deliberately separate but consistently MIT-licensed. We do this on purpose, and the structure tells you something about our threat model.

1. evidiq.dev/skill.md — the spec. A single Markdown file that any agent runtime can fetch over HTTPS. It declares the tool surface (how_to_install, get_evidiq_skill, verify_agent), the x402 payment flow, and the canonical request/response shapes. This is the file your agent reads first.

2. github.com/evidiq/mcp — the MCP server. This is the executable that the skill describes. It speaks the Model Context Protocol, exposes the same three tools, and implements the live probe against a target agent's endpoint (a bounded ~6 second GET that checks reachability, TLS, and a machine-readable surface). The EVIDIQ docs page links straight to the repo.

3. github.com/evidiq/evidiq-skill — the skill spec source. A canonical, version-controlled home for skill.md so PRs against the spec are reviewable and auditable, not silently rewritten by a vendor.

Why three repos and not one? Because the spec is a contract. The server is an implementation. Mixing them turns the contract into a moving target. A builder who reads the spec today should be able to run a server against it tomorrow and get the same verdict, byte for byte. Our scoring formula — identity*0.3 + capability*0.3 + reputation*0.2 + (100-risk)*0.2 — is in the open and not in the server. That's deliberate. You can read it, test it, and if you don't agree with a weight, fork it.

We don't want to be the only place trust can be computed. We want to be the easiest place to compute it correctly.

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

[IMAGE_PROMPT: A clean developer-style illustration of a terminal window emitting a glowing skill.md file, which transforms into a network of connected agent nodes — Claude Code, Cursor, and a custom LangChain agent — all linked by subtle trust-score badges with numeric values 70, 82, 95. A small EVM wallet icon sits at the center. Color palette: off-white background, charcoal text, mint-green and electric-blue accents. No real brand logos, no readable text beyond a stylized .md file extension.]

Here's where the open agent skill MCP shape really earns its keep. If you're a developer reading this, you've probably got an agent running inside someone else's product — Claude Code, Cursor, a hosted LangChain — and you've got no say over what plugins it accepts. Closed plugins can't get in without the platform vendor's blessing. An open skill can, because it travels as a file.

The install path looks like this in practice:

1. Claude Code: add the MCP server config to your project's .mcp.json. One URL, one transport, no auth handshake beyond the x402 challenge on paid calls.
2. Cursor: drop the same server URL into the MCP settings pane. Cursor will fetch the tool list and surface verify_agent next to your other tools.
3. Custom LangChain agent: httpx.get('https://evidiq.dev/skill.md'), parse the tool surface, and you've got a structured trust query in three lines.

That's the structural win. A closed plugin would need three separate vendor relationships, three separate SDKs, and probably three separate billing portals. The open agent skill MCP shape gives you one spec, one server URL, one payment rail, and three runtimes. A wallet balance alone tells you nothing about intent — that's the gap EVIDIQ closes — but a wallet balance plus a live probe plus an identity anchor is a trust score you can defend to your CFO.

The other thing an open agent skill MCP lets you do is fail gracefully. If our hosted probe goes down, the spec is still readable, the server is still forkable, and the EVIDIQ Notary docs explain how to anchor the canonical report yourself on 0G Storage while you wait for us to come back. A closed plugin returns a 500 and your agent has no fallback. Our entire reason for being open is that trust infrastructure is too important to be a single point of failure — including ours.