Open Agent Skill MCP: Why EVIDIQ Refuses the Walled Garden

You'll ship a trust-scoring agent, wire it into three runtimes, and feel productive. Then the vendor behind the only plugin that scores "trust" pivots to ads. Your pipeline is now a black box you can't inspect, can't self-host, and can't fork. That's the moment you find out what "plugin" really means.

Open Agent Skill vs. Closed Plugin: the Actual Difference

An open agent skill MCP is a publicly readable agent capability spec and matching Model Context Protocol server that any developer can install, audit, and self-host without a vendor SDK. EVIDIQ ships exactly that: a free skill spec at evidiq.dev/skill.md, an MIT-licensed MCP server, and a public mirror — so trust scoring is verifiable, forkable, and not locked to one platform.

Most teams don't notice the gap between these two models until it bites them. A "closed plugin" is whatever a single vendor decides to ship inside their walled garden — auth flows through their account, telemetry flows back to their servers, source is opaque, and the only way out is to rip it out and start over. An open agent skill MCP flips every one of those defaults: the spec is a plain markdown file, the server code is MIT-licensed and on GitHub, and your agent can talk to it without anyone at the vendor signing off.

Here's the thing. Trust scoring for AI agents is the worst possible category to lock up behind a plugin. If you can't read the formula, you can't audit a score. If you can't self-host, you can't run it inside an air-gapped compliance environment. If you can't fork it, you're stuck the day the vendor changes pricing, changes priorities, or stops answering email.

Our scoring formula is identity*0.3 + capability*0.3 + reputation*0.2 + (100-risk)*0.2. We publish that exact formula in the spec, we publish the probe code that produces the inputs, and we publish the rules for how evidence gets hashed and signed. A score of 73 in our system today will produce 73 tomorrow with the same inputs — because the math isn't running on someone else's hidden server. That's the structural difference, and it's the one that matters.

What Vendor Lock-In Costs an Agent Builder

Let's put numbers on the failure mode. Last year a payments-rails startup built their entire agent verification layer on a closed plugin from a "trust scoring" SaaS. The SaaS got acquired in 2026. Within a quarter, the plugin changed its API twice, doubled its price, and started requiring a per-agent license. The startup's engineering team spent six weeks rewriting around it. They never got back to building product.

That's the closed-plugin tax, and it has three concrete line items:

• Audit risk. You can't show a regulator, an auditor, or a customer how your trust score is computed if it lives inside someone else's binary. If you operate in any regulated vertical in 2026, this alone disqualifies a closed plugin.
• Self-host risk. PCI-scoped environments, on-prem customer deployments, and air-gapped test rigs all need local execution. A plugin that phones home is, by construction, not local.
• Fork risk. Vendor shuts off the API, pivots the company, or just stops shipping updates. You're now maintaining a fork under pressure with no upstream and no roadmap.

We built EVIDIQ the way we did because we watched this exact pattern play out three times in 2026 and 2026 across the agent infrastructure space. So the question for us wasn't "should we ship a plugin." It was "what's the minimum we need to publish so a builder never has to trust us again." That answer is a skill spec, an MIT-licensed server, and a public mirror — and that's it.

[IMAGE_PROMPT: A flat-vector illustration of a tall cinderblock wall on the left (labeled with a small padlock icon) and a developer on the right placing a glowing puzzle piece — shaped like a document — into an open archway. The wall has plug-shaped bricks; the archway is labeled with a small markdown document icon. Color palette: muted teal, soft amber, off-white background. Clean developer aesthetic, no logos.]

The cost of lock-in isn't hypothetical. It's the difference between a trust layer you can show your customer and a trust layer you have to apologize for.

Three Places the Same Code Lives

A closed plugin lives in one place — on the vendor's server, behind the vendor's auth. An open agent skill MCP lives in three places, in three different forms, all under MIT. Here's the layout.

1. evidiq.dev/skill.md — the canonical spec. This is the file every agent reads. It's plain markdown. It declares the three tool calls (how_to_install, get_evidiq_skill, verify_agent), their inputs, their outputs, and the JSON shape of a trust_report. A developer who has never talked to us can read this file and know everything the agent will do.
2. github.com/evidiq/mcp — the MCP server implementation. MIT-licensed. This is what actually answers the tool calls. It runs locally, talks to the EVIDIQ API over signed HTTPS, and never phones home for anything it doesn't need. You can fork it, change the verifier address, point it at your own EVIDIQ-compatible endpoint, and you've got a self-hosted trust layer. The full EVIDIQ docs walk through every field.
3. github.com/evidiq/evidiq-skill — the spec repo. This is where skill.md lives as code. Changes to the spec go through PRs with public review. Every version of the spec is tagged and immutable. If you pinned your agent to evidiq-skill@v1.4.2 in March, you can still read that exact spec today.

Why three places and not one? Because each one serves a different reader. Agents consume skill.md. Operators deploy the server. Spec authors audit the repo. None of them need to know about the others' existence to do their job, but they all converge on the same trust math.

Beyond those three repos, we keep the operator and sentinel surface area as their own documented subsystems, because once a builder is past "install the skill" they immediately ask "how do I run my own verifier" and "how do I anchor the evidence on-chain." Those answers live at EVIDIQ Sentinel docs and EVIDIQ Operator docs. The trust pipeline isn't one black box — it's four small boxes you can read.

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

Here's where the open agent skill MCP model gets really practical. A closed plugin has exactly one home — the vendor's marketplace, the vendor's auth flow, the vendor's runtime. An open skill can be installed into any runtime that knows how to read a markdown file, which in 2026 is most of them.

Claude Code:

/plugin marketplace add evidiq/evidiq-skill

That's the whole install. The runtime reads skill.md, registers verify_agent and how_to_install, and you're calling the trust endpoint on the next turn. No vendor account. No per-seat license. No OAuth handshake that breaks the moment the vendor's auth provider has a bad day.

Cursor: same idea — drop the skill file into .cursor/skills/, restart, and the agent now has the tools. The exact path lives in the EVIDIQ docs, but it's roughly:

curl -fsSL https://evidiq.dev/skill.md > .cursor/skills/evidiq.md

And for a custom LangChain agent: read skill.md, parse the JSON shapes, instantiate the MCP client. We wrote the spec so a competent engineer can do this in an afternoon without reading any of our prose. The math is simple. The schema is small. The tool calls are three.

The structural difference matters. A closed plugin is bound to the runtime that ships it — usually one vendor's IDE, one vendor's auth flow, one vendor's billing system. An open agent skill MCP is a contract, not a product. Your agent adopts the contract. Anyone can write an implementation. Nobody has to ask permission to add a new runtime.

[IMAGE_PROMPT: A flat illustration of three connected panels on a soft cream background. Left panel: a developer laptop showing a terminal window with a one-line install command. Center panel: a hexagonal MCP node glowing teal, labeled with subtle "MCP" text. Right panel: three small agent runtimes (a chat bubble, a code editor tab, and a graph node) all connected to the center node with thin lines. Modern flat design, developer aesthetic, no real brand logos.]

We also wrote the spec so it doesn't assume anything exotic about your stack. You don't need a specific MCP client version. You don't need a specific Node version. You don't need an account with us to install it. You need the spec, the server, and roughly ten minutes. That's the floor we wanted to set.

Moving from "install the skill" to "anchor my own evidence" is the next step. The answers live at EVIDIQ Sentinel docs and EVIDIQ Notary docs. Sentinel handles the live probe and risk analysis; Notary handles the canonical hashing, the 0G Storage anchor, and the EIP-191 signature. Neither of those steps requires us to be online. Neither of them locks you to our infrastructure.