An Open Agent Skill MCP Is the Only Sane Way to Verify One — Here's Why We Built EVIDIQ That Way

You ship an agent. It calls three other agents to complete a workflow — one to fetch a price, one to settle a payment, one to file a record on-chain. Each of those three returns a "trust score." Now what?

Here's the thing: if you can't read the scoring logic, can't host it yourself, and can't fork it when the vendor pivots — you don't actually have a trust signal. You have a recommendation from a black box that holds your agent's reputation hostage. That's the problem we're solving with an EVIDIQ open agent skill MCP at evidiq.dev/skill.md, and that's the reason we refuse to ship it as a closed plugin.

Open Agent Skill vs. Closed Plugin: the Actual Difference

An open agent skill MCP is a verifiable, installable, MIT-licensed specification that any agent runtime can consume without a vendor SDK. EVIDIQ ships this way: a readable skill.md, a public remote MCP server, and mirror repos on GitHub — so trust verification isn't gated behind a closed plugin you have to take on faith.

The terminology gets blurry, so let's pin it down. In 2026 the term "agent skill" has come to mean roughly the same thing as an MCP tool — a callable capability a model can invoke, usually advertised in a manifest or skill file. The interesting question isn't what it's called; it's who controls the source.

An open skill has three properties that a closed plugin structurally can't match:

• The spec is human-readable. You can open skill.md in a browser and read what every tool does, what it returns, and how it computes a result.
• It installs without a vendor SDK. You point an MCP-compatible runtime at the URL or drop the file into a folder and it works.
• The source lives on GitHub under a permissive license (we chose MIT). Anyone can fork it, audit it, mirror it, or run their own instance.

A closed plugin, by contrast, is a binary or a vendored SDK that ships as compiled or obfuscated code you can't audit end-to-end, requires you to register with the vendor and paste an API key, and locks your agent's behavior to the vendor's roadmap, pricing changes, and continued existence.

If your agent is calling a "trust verification" service and that service is closed, you've replaced one trust problem (is this counterparty honest?) with a bigger one (is the verifier honest?). That's not a trade we were willing to make at EVIDIQ, and it's the structural reason we shipped the whole stack as an open agent skill MCP rather than a private plugin.

What Vendor Lock-In Costs an Agent Builder

The cost of a closed plugin isn't theoretical. We've watched builders hit these walls, and we've felt them ourselves with other vendors in 2026.

Here are the concrete failure modes:

• Auditing the scoring logic is impossible. The provider hands you a 0–100 number and a verdict, but the formula is proprietary. When a regulator, an auditor, or a sharp customer asks how that number was computed, you have nothing to show.
• Self-hosting is off the table. If the vendor's SaaS goes down, your agent's trust check fails. We've seen production agents degrade to do_not_proceed the moment a verifier endpoint had a 30-second hiccup — and there was nothing the agent could do.
• Forking isn't an option when the vendor pivots, gets acquired, sunsets the product, or doubles the price. You're scrambling to rip out the integration while your agents are still calling it.
• Extending it beyond the vendor's roadmap is blocked. Their roadmap doesn't include your use case — say, weighting ERC-8004 identity anchors differently — and there's no plugin API to do it yourself.
• Moving the data out is paywalled. Audit logs and historical verdicts live in the vendor's database, exportable only if you pay the enterprise tier.

Honestly? The worst one is the last. Trust history is the only durable asset your agent builds over time, and a closed plugin owns it. Fork it and you start at zero reputation.

We built EVIDIQ differently on purpose. Every report is hash-anchored on 0G Storage, the verdict is signed with the EVIDIQ EIP-191 key, and the evidence is re-fetchable by anyone. You can read exactly how the EVIDIQ Sentinel docs compute the live probe and how the EVIDIQ Operator docs walk you through running your own scoring against any agent.

Three Places the Same Code Lives

To make an open agent skill MCP actually open, you can't just publish a spec and call it a day. The code that scores an agent has to live somewhere a curious developer can read, run, and modify. We keep three mirrors of the same logic, each one with a slightly different audience:

1. evidiq.dev/skill.md — The canonical skill manifest. This is what an MCP client downloads when it asks "what can EVIDIQ do?" It's the readable spec: tool names, parameter shapes, response formats, and the deterministic scoring formula written out in plain language. It's the thing a runtime ingests to know how to call us.
2. github.com/evidiq/mcp — The public remote MCP server. This is the actual service your runtime connects to over HTTP. It's MIT-licensed, so anyone can clone it, run it locally against their own agent fleet, and inspect every line that touches a request. It exposes how_to_install, get_evidiq_skill, and verify_agent (paid, x402).
3. github.com/evidiq/evidiq-skill — The skill spec repo. This holds the raw skill.md plus the versioned changelog. If we change the scoring formula, bump a tool name, or add a field, the diff lands here first. It's the auditable history.

Why three and not one? Because they answer different questions. The skill.md tells a runtime what to do. The MCP repo tells a developer how it does it. The spec repo tells a reviewer what changed and why. Collapsing them into a single repo looks tidier on a GitHub profile but it makes the audit trail harder to follow, and the audit trail is the whole point.

Worth noting: all three are MIT-licensed. The full EVIDIQ docs sit alongside them, including the deeper EVIDIQ Notary docs that walk through how the tamper-evident evidence anchoring works under the hood.

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

The real test of an open agent skill MCP is what happens when you can't modify the runtime. Most agent frameworks in 2026 — Claude Code, Cursor, custom LangChain or CrewAI harnesses — all speak MCP, but they each install tools slightly differently. A closed plugin forces you into a single path. An open skill lets you choose.

For Claude Code, you add a single line to your project's MCP config:

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

For Cursor, you open Settings → MCP → Add Server, paste the URL, and it auto-discovers the tool list from skill.md.

For a custom LangChain or CrewAI agent, you instantiate the MCP adapter and point it at the same URL. No SDK download, no API key upfront, no vendor onboarding.

Here's why a closed plugin can't structurally do this:

• Closed plugins ship as platform-specific binaries (a .dylib for one runtime, a .node for another) and the vendor only ships the targets they care about. An open skill is a URL plus a manifest — the runtime figures out the rest.
• Closed plugins often require a vendor account and a per-seat license. An open skill is fetched the same way an LLM is fetched: anonymously, then metered at the point of use.
• Closed plugins break the moment the runtime updates its ABI. An open skill is versioned by the skill.md itself; older skills keep working while newer ones ship.

In practice this means an EVIDIQ consumer can integrate us in a single afternoon, and an EVIDIQ auditor can read every byte that touched a verdict before lunch. That's the entire tradeoff. We think it's a good one.