We Built EVIDIQ as an Open Agent Skill MCP — Here's Why

Three weeks ago a builder in our Discord pasted a screenshot of an "agent verification plugin" he'd been evaluating. The plugin lived inside a single SaaS dashboard. To use it, his agent had to send every verification request through the vendor's hosted endpoint, the source was nowhere, the SDK was a closed .whl, and pricing was a single line: "Contact sales." He wanted to know what EVIDIQ would do if we got popular and a hyperscaler offered to acquire us.

Honest answer: nothing. We can't rug you. Our code isn't ours to rug. That's the entire point of shipping an open agent skill MCP.

Open Agent Skill MCP vs. Closed Plugin: the Actual Difference

An open agent skill MCP is a verifiable, installable capability for an AI agent whose specification is published in plain text, whose reference implementation lives in a public MIT-licensed repository, and which any agent runtime can adopt without a vendor SDK or a per-seat license. EVIDIQ ships exactly this way: skill at evidiq.dev/skill.md, server at evidiq.dev/mcp, code mirrored on GitHub.

Here's the distinction that actually matters day to day. A closed plugin is something you consume. You paste an API key into an environment variable, you pray, and when the vendor changes pricing you find out via invoice. An open agent skill MCP is something you adopt. You can read the spec on your phone, fork the reference server, point your agent at your own fork if you want, and the worst case scenario is you revert to a known-good commit. There's no version of vendor lock-in that survives "the source is on GitHub under MIT."

Practically, three properties separate the two:

• The skill spec is a plain Markdown file at a stable URL — no auth, no obfuscation, no "request access" form.
• The MCP server is open source, so any runtime (Claude Code, Cursor, LangChain, raw mcp-cli) can integrate without waiting for the vendor to publish bindings.
• The license is MIT, which means a downstream agent builder can vendor our code into their own stack without paying us, asking us, or even telling us.

That's what makes the word open mean something in this context. It's not a marketing label. It's a structural guarantee.

What Vendor Lock-In Costs an Agent Builder

The hidden cost of a closed plugin isn't the line item. It's everything around the line item.

First, auditability dies. If a verification result says "trust score 73," and that score comes from a black-box endpoint, your downstream code is acting on a number with no provenance. Did the vendor run the same probe your agent expected? Did they quietly downgrade a competitor? You can't tell. With EVIDIQ the score formula is public — identity0.3 + capability0.3 + reputation*0.2 + (100-risk)*0.2 — and the inputs are reproducible. Same agent, same call, same number, every time.

Second, you lose the ability to self-host. A vendor-hosted MCP server means your agent's verification calls traverse their infrastructure, get logged on their side, and depend on their uptime SLA. If they have a bad week, your agent has a bad week. Our reference server is small enough to fork and run on a $5 VPS, and a serious builder can absolutely do that.

Third — and this is the one nobody talks about — a closed plugin can pivot underneath you. We watched three "AI agent infrastructure" startups in 2026 change their trust scoring models mid-year without notice, and their users had no recourse because the scoring logic was proprietary. Builders who'd wired those scores into autonomous transaction logic woke up to agents that started declining counterparties the builder's business actually depended on. With an MIT-licensed open agent skill MCP, that whole failure mode is structurally impossible. The old scoring weights are pinned in git history. If we ever change them, the diff is public.

The math is simple. When a vendor owns the spec, the implementation, and the server, every dependency in your stack has the lifespan of that vendor's runway. When the spec is a public URL and the implementation is on GitHub, your dependency has the lifespan of the URL and the repo. We've seen which one survives.

Three Places the Same Code Lives

A builder asked us last month why we keep three separate repositories instead of one mega-monorepo. The answer is that each artifact serves a different audience, and conflating them would defeat the point of being open.

1. evidiq.dev/skill.md — This is the spec. It's a single Markdown file that any agent runtime can fetch and parse. It declares what EVIDIQ does, what inputs it expects, what outputs it returns, and how to install it. It changes slowly. If you're a builder deciding whether to integrate us, this is the file you read first. We treat it like an API contract.

2. github.com/evidiq/mcp — This is the public MCP server. It's the reference implementation of the spec, written in TypeScript, MIT-licensed, and small enough to read in an afternoon. It's what Claude Code and Cursor pull in when you run evidiq install. If you want to see exactly what verify_agent does — the probes it runs, the headers it sets, the timeout it enforces — you read this repo.

3. github.com/evidiq/evidiq-skill — This is the skill spec repo. It holds the canonical Markdown manifest, example payloads, and the changelog that documents every breaking change. The skill spec and the MCP server evolve at different speeds, and keeping them in separate repos means a builder can pin one without pinning the other.

Why does the separation matter? Because if the spec, the server, and the example payloads all lived in one repo, a single breaking change to any one of them would force a synchronized upgrade across the whole stack. With three repos, you can adopt a new MCP server version without re-reading the spec, and you can update the spec documentation independently of when we cut a release. That's the boring kind of engineering that makes integration actually pleasant.

The license is MIT across all three. We're not trying to build a moat — we're trying to build a protocol.

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

Here's the part that makes a closed plugin jealous. Because the skill is a published Markdown file and the server is an open-source binary, you can install EVIDIQ into a runtime whose source code you don't own and whose vendor you don't control. We do this ourselves in three places.

For Claude Code, the install is a one-liner. You run claude mcp add evidiq -- npx -y @evidiq/mcp-server, paste your endpoint URL, and the runtime picks up verify_agent, how_to_install, and get_evidiq_skill as native tools. No SDK wrapper. No "EVIDIQ Claude Edition." The runtime doesn't know or care that we exist as a company — it just sees a server speaking MCP.

For Cursor, the flow is similar but uses Cursor's mcp.json. You drop the server config in, restart, and the tools appear under your agent's tool palette. We've watched non-developers do this in under five minutes. The reason it works is that MCP is a protocol, not a product, and our server speaks it correctly.

For a custom LangChain agent — or any runtime that exposes an MCP client — you point your client at https://evidiq.dev/mcp and authenticate using the x402 flow we detail in the EVIDIQ docs. For free tools (how_to_install, get_evidiq_skill) there's no payment at all. For verify_agent, the runtime receives an HTTP 402 challenge, signs an EIP-3009 authorization in USDT0 on X Layer, retries, and gets the score. The whole thing is auditable from the runtime's own logs.

The reason a closed plugin can't do this is structural. A closed plugin lives behind a vendor SDK, which lives behind a vendor API key system, which lives behind a vendor authentication flow. If you don't control the runtime, you can't install the SDK, and if you can't install the SDK, you can't use the plugin. An open agent skill MCP sidesteps all of that because the artifact being installed is the spec — a public URL that any conforming runtime already knows how to consume.

We've also seen teams vendor the MCP server directly into their own agent's image. That's the "if we get acquired" safety net, and it works because of MIT. If EVIDIQ the company disappeared tomorrow, your agent would still function. You'd point it at a self-hosted fork, update the endpoint in one config file, and ship.