We Chose to Ship EVIDIQ as an Open Agent Skill MCP. Here's Why.

Most "AI agent plugins" you've seen are really a vendor's leash. They live behind a marketplace login, depend on a closed SDK, and disappear the moment the company pivots or gets acquired. EVIDIQ's trust score doesn't work that way — and that decision came before a single line of scoring code. We chose to ship as an open agent skill MCP with a public spec and an MIT-licensed mirror, because trust infrastructure that can't be audited by the agent using it isn't trust infrastructure. It's a recommendation engine dressed up as a service.

Open Agent Skill vs. Closed Plugin: the Actual Difference

An open agent skill MCP is a machine-readable skill file paired with a public Model Context Protocol server that any agent can install and audit without a vendor SDK. EVIDIQ ships exactly this shape: the spec lives at evidiq.dev/skill.md, the reference MCP server is MIT-licensed, and the trust score is fully reproducible.

Here's the thing. The label "plugin" gets thrown around loosely. In agent infrastructure it usually means a closed binary or service that requires the vendor's runtime, the vendor's auth, and the vendor's blessing to deploy. When that vendor changes direction, you're stuck. When they get acquired, you're stuck. When they sunset the product, you're rebuilding from scratch — usually right before a deadline.

We've watched this happen to enough developer tools to know better than to build one that way. So we picked three concrete properties that any honest open agent skill MCP has to satisfy:

• A readable spec — usually a skill.md document — that names every input, output, and scoring dimension in plain text.
• Installable from a URL into Claude Code, an MCP-aware IDE, or a custom runtime, with no proprietary SDK in the loop.
• A reference implementation whose source is public, forkable, and re-runnable by anyone who disagrees with our defaults.

That's the bar. We don't claim moral superiority — those are just the properties that make the trust score reproducible, which is the whole point. A recommendation that can't be checked isn't really a recommendation; it's marketing with a JSON envelope.

What Vendor Lock-In Costs an Agent Builder

Now let's get specific. Vendor lock-in in agent infrastructure shows up as a stack of small frictions that compound into a re-platforming project the day the vendor decides to move.

[IMAGE_PROMPT: A modern flat illustration showing an isometric view of a small developer workspace. On the desk, a laptop displays a wall of red padlock icons behind a glass barrier, with developer hands reaching through cutouts in the glass. Adjacent, a faded grey filing cabinet sits locked. Soft mint and coral accent colors, clean tech aesthetic. No text, no real brand logos.]

The costs are concrete, not theoretical:

• You can't audit what it does. A closed plugin returns a verdict — "safe" or "risky" — and you have to take its word. For trust scoring, the one piece of your agent that decides whether to send funds, "take its word" is not an acceptable answer in 2026.
• You can't self-host. If the vendor has a regional outage, your risk layer has the same outage. We've watched production agents cascade-fail because their trust check sat on somebody else's single-region API.
• You can't fork it. Vendor pivots from "agent trust" to "agent ads" and your dependency vanishes overnight. Vendor gets acquired, the roadmap quietly shifts, and your scoring dimensions change without notice.
• You can't write your own probe. A live endpoint probe is part of how our capability score gets measured. If that probe is closed, you can't write your own version for an air-gapped deployment or a regulated environment.

The math is simple. The closer the plugin is to your money-flow, the more catastrophic the lock-in. EVIDIQ is the closest thing in the stack to your money-flow — it sits between intent and settlement — which is exactly why we ship it as an open agent skill MCP rather than a vendor-locked product. The whole EVIDIQ Operator docs page is essentially a guide for teams who want to do exactly that: run the probe, run the scoring formula, and verify the verdict without ever talking to our servers if they don't want to.

Worth noting: this is also why the EVIDIQ Sentinel docs describe how to compose the score with your own constraints. Lock-in by omission — "we don't expose the formula so you can't tune it" — is the same trap with better PR.

Three Places the Same Code Lives

We keep the same primitive in three deliberately separate places. That sounds like duplication. It's not — it's separation of concerns so no single repo becomes a critical monoculture.

1. evidiq.dev/skill.md — the spec. A single Markdown file with the EVIDIQ skill description, the scoring formula, the inputs, and the output schema. This is what an agent fetches to understand what EVIDIQ even is. It's versioned, dated, and meant to be diffed.

2. github.com/evidiq/mcp — the reference MCP server. Implements how_to_install, get_evidiq_skill, and verify_agent. MIT licensed. This is what most teams actually run.

3. github.com/evidiq/evidiq-skill — the skill spec repo. Where the canonical skill.md is maintained and changes get reviewed. Anyone can open a PR against the scoring formula itself; we don't gatekeep the spec behind a private channel.

Why three repos and not one mega-repo? Because skill spec, transport implementation, and reference server have completely different release cadences and audiences. The skill spec changes when our scoring changes — maybe twice a year. The reference server changes when MCP changes — more often. Mixing them means a one-line MCP dependency bump forces a versioned change to a document that describes trust semantics, which is silly.

What the spec also names, and this is where we get opinionated, is what counts as reputation today. We derive it from identity anchors plus live signals — the biggest of which is whether the endpoint runs a paid x402 service, the economic skin in the game. We're not pretending to be a mature on-chain reputation registry yet (that's roadmap, not shipped), but the formula is in the open and you can replicate it with the same inputs.

It's also why every artifact is MIT-licensed. If you want to vendor the spec into your own internal registry, the license permits it. If you want to mirror our MCP server and add a custom probe for your own fleet, the license permits it. The whole EVIDIQ docs tree is structured around this principle: read the spec, run the code, or fork both.

Honestly? The licensing is the load-bearing decision. Everything else is implementation.

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

Here's where the shape pays off. A closed plugin installs through the vendor's dashboard, with the vendor's API key, into a runtime the vendor also controls. An open agent skill MCP installs the way a Unix tool installs: paste a URL, restart, done.

[IMAGE_PROMPT: A modern flat illustration of a terminal window showing three short installation command lines (using npx, claude mcp add, and curl), with a friendly robot icon and a green play button floating nearby. The terminal sits on a clean desk with a coffee mug, plants, and a notebook in the background. Soft teal and amber accent palette. No text, no real brand logos.]

A few real install paths, taken straight from the EVIDIQ Notary docs:

1. Claude Code — claude mcp add evidiq --transport http --url https://evidiq.dev/mcp. Restart. The agent now has verify_agent available as a first-class tool.

2. Cursor — drop the MCP URL into .cursor/mcp.json, restart the IDE. Same tool surface, same scoring formula, no extra SDK.

3. Custom LangChain agent — npm i @evidiq/mcp-client, point it at the public MCP server, expose verify_agent as a tool. Your runtime, your logging, your redaction policy.

The reason a closed plugin structurally can't do this is the SDK dependency. The moment a plugin requires "Plugin SDK v3.2," you've committed to a runtime you didn't pick. With an open agent skill MCP the spec is text and the transport is HTTP — both replaceable. If you hate our server, you point the skill at your fork. If you hate the spec, you publish your own skill.md and tell your agents to read that instead.

This matters most in environments you don't control: an enterprise agent behind a corporate proxy, an air-gapped deployment for a defense customer, a regional rollout where the public MCP endpoint is firewalled. A closed plugin in any of those contexts is a ticket back to the vendor. An open agent skill MCP is a git clone and a config file.