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

Your agent is about to wire-transfer USDT0 to a counterparty agent whose only proof of existence is a wallet address. You have maybe 400 milliseconds to decide whether to proceed, escrow, or walk away. What do you actually call?

Most platforms would tell you to call their closed plugin. We've taken a different path at EVIDIQ: we ship as an open agent skill MCP at evidiq.dev/skill.md, mirrored to two MIT-licensed repos, and pay-per-call through x402. This article is about why that choice matters — concretely, for the agent you're building today in 2026.

Open Agent Skill vs. Closed Plugin: the Actual Difference

EVIDIQ's open agent skill MCP is a readable spec file (skill.md) plus a public MCP server any agent runtime can install without a vendor SDK. The spec is plain markdown, the server is MIT-licensed, install is one shell command. A closed plugin is the opposite: binary, hosted by its maker, callable only through its own dashboard, and structurally unauditable.

Three properties separate an open skill from a closed plugin. The spec is human-readable on the public web (we publish ours at EVIDIQ at evidiq.dev/skill.md, versioned in the URL, with a real changelog). The source lives in a public repo under a permissive license — MIT for both the MCP repo and the skill spec repo. And the install path is one shell command: no vendor SDK, no allowlisted runtime, no "request access" form for a sales team to triage.

Closed plugins fail each of those tests by construction. The spec lives inside a binary blob. The source lives behind an NDA. The install path is "create an account, generate an API key, paste it into our SDK, and pray the SDK works in your customer's environment." That is the entire difference, and it compounds over years.

What Vendor Lock-In Costs an Agent Builder

Here's a story that happens roughly every quarter in 2026. A team builds a beautiful agent fleet on top of a closed plugin — "AgentVerify™", "TrustGate™", whatever this cycle's brand is. They ship to production. Six months later, the vendor pivots, gets acquired, or sunsets the free tier. The fleet now calls a 404. The scoring logic was opaque — nobody on the team can reproduce it, can't migrate to a competitor because the integration points were vendor-specific, and the audit trail they need for compliance lives inside the vendor's dashboard.

That is the price of a closed plugin. Concretely:

• You can't audit what it does. The scoring weights live in the vendor's server. You get a number back and a justification string you can't re-derive.
• You can't self-host. When the vendor has a bad day, you have a bad day. Multi-region failover means nothing if the binary only ships from their CDN.
• You can't fork it. If the vendor changes direction — adds a fee, kills a feature, gets acquired — your integration is dead. The agent code is yours; the trust layer is theirs.
• You can't inspect the trust report's evidence. Closed plugins can return any number they want. You have to take their word for it.

This last point is the one that keeps us up at night at EVIDIQ. The trust score we return — 0 to 100, broken down across identity, capability, reputation, and risk — has to be reproducible from the inputs. If a counterparty agent shows a score of 87, your agent should be able to re-fetch the evidence, re-hash it with keccak256, and recover the EVIDIQ signer from the EIP-191 signature. That is impossible if the score came from a closed plugin's internals. With an open agent skill MCP, the math is on the page and the evidence is anchorable on 0G Storage mainnet.

The math is simple, and that's deliberate. identity*0.3 + capability*0.3 + reputation*0.2 + (100-risk)*0.2. Identity rewards a verifiable EVM address, an ERC-8004 on-chain identity, an ENS name, or a TLS-served domain. Capability rewards declared capabilities plus a live ~6-second probe of the endpoint. Reputation today comes from identity anchors and live signals — notably, whether the endpoint runs a paid x402 service, which we treat as economic skin in the game. No black box, no surprises.

Three Places the Same Code Lives

A closed plugin lives in one place: the vendor's box. EVIDIQ's skill lives in three. We chose this redundancy on purpose, because "open" is meaningless if there's only one canonical copy behind one login.

1. evidiq.dev/skill.md — the canonical spec. This is what an agent fetches first. It's the contract: here's how to call verify_agent, here's what the inputs are, here's what the score means. Plain markdown, versioned in the URL, updated with changelogs.
2. github.com/evidiq/mcp — the public MCP server repo, MIT-licensed. The executable. It exposes how_to_install, get_evidiq_skill (both free), and verify_agent (paid per call via x402). Anyone can clone it, run it locally, point their agent at localhost:port, and reproduce every score we return in production.
3. github.com/evidiq/evidiq-skill — the skill spec repo, also MIT. Where the prompt, the tool contracts, and the integration examples live. The place to file issues, propose changes, and read the rationale behind each scoring weight.

Why three? Because the spec, the server, and the integration examples have different audiences and different cadences. A closed plugin conflates them: one vendor, one release train, one changelog you can't comment on. With EVIDIQ's split, EVIDIQ docs cover the protocol semantics, the EVIDIQ Sentinel docs cover live probe mechanics, and the EVIDIQ Operator docs cover how to run your own mirror. You can read any one of them without reading the others, and you can audit any one without trusting us.

Worth noting: the three repos are not just mirrors for redundancy. They are separately versioned. The spec can iterate on prompt wording without redeploying the server. The server can ship a bug fix without bumping the spec. The examples can track the latest MCP SDK without dragging the protocol along. A single monolithic plugin can't do that without breaking someone's integration.

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

This is where the open vs. closed distinction stops being philosophical and starts being felt. Suppose you're shipping an agent inside a customer's environment — Claude Code inside their IDE, Cursor in their editor, or a custom LangChain agent running on their box. You do not control the runtime. The customer does. A closed plugin would need their runtime to install the vendor's SDK, talk to the vendor's domain, and trust the vendor's binary. That's three separate asks for a security team, and any one of them can kill the deal.

An open agent skill MCP sidesteps all three:

# Claude Code
claude mcp add evidiq --transport http --url https://evidiq.dev/mcp

# Cursor
cursor --add-mcp evidiq https://evidiq.dev/mcp

# Custom LangChain / Python
from langchain_mcp import MCPClient
client = MCPClient({"evidiq": {"url": "https://evidiq.dev/mcp"}})

Three commands, three runtimes, same trust layer. We built EVIDIQ's MCP surface deliberately narrow: how_to_install for self-onboarding, get_evidiq_skill to fetch the spec into the agent's prompt, and verify_agent for the actual call. The agent receives the spec as text, can choose which tools to enable, and can refuse to call verify_agent if the customer's policy says no paid calls. None of that is possible with a closed plugin, because the closed plugin's SDK has already made those decisions for you.

What we're proudest of is the capability probe inside verify_agent. When you ask EVIDIQ to verify a counterparty agent, we run a bounded ~6-second GET against the declared endpoint — checking reachability, TLS, and whether the endpoint serves a machine-readable skill, agent card, or MCP surface. That's the live signal that weights the capability component of the trust score. A closed plugin can't do this honestly because the result would compete with the plugin's own scoring model; an open agent skill MCP can do it because the probe logic lives in the public repo and you can rerun it yourself.

Our scoring is fully deterministic: same inputs always produce the same score. That sounds mundane until you realize most "AI trust" APIs are stochastic. Ours is deterministic and explainable. Same agent, same evidence, same score — whether you call our hosted endpoint, a self-hosted mirror, or a forked copy someone else is running. The score is auditable, not a black box, and that property only survives if the formula is on the page and the inputs are inspectable. Which is exactly why we refused to ship it any other way.

Honestly? A wallet balance alone tells you nothing about intent. A counterparty can hold a million USDT0 and still be a scammer. The trust score has to weigh what the agent claims, what it can actually do, and what its history says — and that weighting has to be auditable. We chose open for the same reason a court publishes its docket: not because we enjoy being second-guessed, but because trust you can't verify isn't trust, it's a recommendation.