We Shipped EVIDIQ as an Open Agent Skill MCP — On Purpose

Picture this: you're running an autonomous procurement agent. It needs to call another agent — a logistics API run by a stranger you've never vetted. Before sending $50,000 of inventory authority to that counterparty, you'd really like a second opinion. The vendor who sold you the "trust plugin" went bankrupt in March. Your plugin is now a dead binary. Your agent is making trust decisions blind.

That's the failure mode we built EVIDIQ to prevent — and the reason we ship it as an open agent skill MCP instead of a closed plugin.

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

An open agent skill MCP, in EVIDIQ's case, is a verifiable trust-layer runtime delivered as a public Markdown spec, an MIT-licensed MCP server, and a mirror repo anyone can fork. It verifies an agent's identity, capability, and reputation and returns a 0–100 trust score with an explicit proceed, proceed_with_escrow, caution, or do_not_proceed recommendation. No vendor lock-in, no black box.

Here's the actual difference, stripped of marketing. A closed plugin is a binary you install inside one host — usually a marketplace, sometimes a vendor SDK — and you cannot read, host, or fork what it does. You agreed to a click-through license, and the source lives in a repo you can't access. An open agent skill MCP is the opposite: the spec is a public Markdown file, the server is MIT-licensed code on GitHub, and the install path is a one-liner that any MCP-aware agent runtime can consume.

Worth noting: "open" isn't a vibe. It's three concrete properties:

• Readable spec — anyone can hit evidiq.dev/skill.md and understand what the skill claims to do, what it costs, and what it returns.
• Installable without a vendor SDK — the runtime talks standard MCP, so any MCP-aware host can call it.
• Source-available under MIT — the canonical code is on GitHub, with no telemetry you can't inspect.

A closed plugin might have one of these. An open agent skill MCP has all three, by construction.

What Vendor Lock-In Costs an Agent Builder

We learned this the hard way at previous jobs. Closed trust plugins look fine in a demo and rot in production. The failure modes cluster into four buckets:

• Audit gap — when the vendor's plugin produces a recommendation your agent acts on, you can't independently verify the heuristic. You're trusting the plugin to be honest about its reasoning.
• Hosting gap — most closed plugins run inside the vendor's cloud. Their outage, their pricing change, their policy change — all become yours.
• Forking gap — if the vendor pivots, gets acquired, or sunsets the product, your agent loses the trust layer mid-flight. Migration becomes a project, not a config change.
• Composability gap — a closed plugin usually only talks to its host's marketplace. An open skill can be embedded into any runtime that speaks the protocol.

The economics matter too. When trust logic is closed, every agent team reinvents the same scoring heuristic in private — wasted engineering. By shipping the spec and the source openly, we let builders spend their time on agent behavior instead of rebuilding trust primitives.

This is also why we keep the EVIDIQ Sentinel docs public. Sentinel is the verifier component — the part that actually probes an agent's endpoint and computes the capability score — and we don't want anyone to wonder what it's doing under the hood. Read the doc, read the code, run it yourself. That's the bar.

Three Places the Same Code Lives

Our trust logic lives in three places, intentionally. They are not duplicates; they are different artifacts with different consumers.

1. evidiq.dev/skill.md — the canonical human- and LLM-readable spec. This is what an agent's prompt ingests to discover what the skill can do, what it costs, and how to call it. Plain Markdown, version-controlled, single source of truth.
2. github.com/evidiq/mcp — the public MCP server implementation, MIT-licensed. This is the code that exposes three tools — how_to_install, get_evidiq_skill, verify_agent — over the MCP transport. Clone it, run it locally, point it at your own keys.
3. github.com/evidiq/evidiq-skill — the skill spec repo. Houses the canonical Markdown, schema files, and example invocations. This is where contributions happen.

Why three repos instead of one? Because the consumers differ. The skill spec is read by LLMs and humans. The MCP server is read by developers integrating it. Keeping them separate but MIT-licensed means each audience sees what they need without dragging in the others' concerns — nobody has to learn MCP to read the spec; nobody has to read the spec to deploy the server. The EVIDIQ homepage links to all three.

The signing story also spans these repos. EVIDIQ signs verified reports with an EIP-191 signature tied to a public key you can recover. Anyone with the report and the key can re-verify the signature. That property only holds because the key isn't buried in a vendor SDK — it's published, and the verifier code is MIT. The full flow lives in the EVIDIQ Notary docs.

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

Here's where the structural difference becomes a practical one. If you're shipping an agent inside a managed runtime — Claude Code, Cursor, a hosted LangChain deployment — you usually cannot install a closed plugin. The host doesn't allow it, or the plugin isn't published in that marketplace, or it requires a vendor SDK you don't have.

An open agent skill MCP sidesteps every one of those gates. The install path is a one-liner any MCP-aware host speaks natively. We test installs against three target runtimes:

• Claude Code — claude mcp add evidiq https://evidiq.dev/mcp registers the remote MCP server in your project's .mcp.json. From that point, the agent can call verify_agent directly.
• Cursor — same registration flow, different config file. Cursor reads .cursor/mcp.json and exposes the tools to the composer.
• Custom LangChain or LangGraph agent — point an MCP client adapter at the endpoint. No SDK lock-in. The protocol is the contract.

Step-by-step, the typical install is:

1. Add the remote MCP endpoint to your host's MCP config — one line of JSON.
2. Confirm the three tools (how_to_install, get_evidiq_skill, verify_agent) appear in your agent's tool list.
3. Call verify_agent against the counterparty agent's identifier. Receive a 0–100 trust score with a recommendation and the deterministic breakdown.
4. Pipe the recommendation into your own decision logic. You can ignore it, weight it, or act on it directly — EVIDIQ never holds funds, never grants authority.

Notice step 4. EVIDIQ produces evidence and a recommendation; the calling agent decides what to do with it. That's the right separation of concerns for a trust primitive, and it's only possible because the skill is open enough that you can read exactly what it returns.

If you're operating your own agent fleet, the EVIDIQ Operator docs belong open in a tab. Operator is the side that runs trust checks on demand and surfaces the results to your internal dashboards. Same protocol, different consumer.

The verification itself is deterministic. Same inputs — identity anchors, declared capabilities, live endpoint probe results — always produce the same score. Our scoring formula is identity*0.3 + capability*0.3 + reputation*0.2 + (100-risk)*0.2, auditable in the source. A closed plugin cannot structurally promise this — you can't audit what you can't see. Identity anchors in 2026 include verifiable EVM addresses, ERC-8004 on-chain identity ids, ENS names, and TLS-served domains, and capability scoring rewards declared capabilities plus a live ~6-second probe of the agent's endpoint.