Why EVIDIQ’s open agent skill MCP Beats a Closed Plugin

Picture this: your autonomous agent finds a trust provider, completes an x402 payment, and gets a recommendation. The integration works—until the vendor changes its SDK, removes the endpoint, or your runtime changes next week. At that point, a convenient plugin becomes an infrastructure dependency you cannot fully inspect or replace.

We built EVIDIQ around a different premise. The contract for verifying an agent should be readable, portable, and available as source. Our public EVIDIQ Agent Skill, remote MCP server, and MIT-licensed repositories let builders inspect the integration instead of trusting a black box. Open code is not decoration at EVIDIQ; it is the distribution model.

Open Agent Skill vs. Closed Plugin: the Actual Difference

EVIDIQ’s open agent skill MCP is a portable, machine-readable way to give an agent an auditable trust check: the Agent Skill defines behavior, while the public MCP server exposes how_to_install, get_evidiq_skill, and paid verify_agent calls. Anyone can inspect, host, or adapt it under MIT licensing.

Start with the install path. A closed plugin usually depends on one vendor’s package manager, runtime extension, opaque service wrapper, or hosted API. The plugin may be perfectly reliable, but its behavior is enforced through access controls. You can consume the result; you cannot necessarily inspect the client, reproduce the scoring logic, or move the same contract to another agent.

An open integration exposes a different set of boundaries:

• A readable contract that developers can review before deployment.
• A standard transport such as MCP instead of a proprietary plugin API.
• An install path that does not require EVIDIQ’s internal SDK.
• Source code that teams can audit, fork, patch, or mirror.

A closed integration is not automatically bad, and an open one is not automatically secure. The difference is control. With a closed plugin, the vendor controls the runtime contract, release cadence, and failure recovery. With EVIDIQ, builders retain the ability to inspect that contract and choose where the verification boundary lives.

By contrast, EVIDIQ’s verification contract is explicit. It checks an agent’s identity, declared capabilities, available reputation signal, and risk. Each input receives a score from 0 to 100. The final trust score is deterministic: identity × 0.3 + capability × 0.3 + reputation × 0.2 + (100 − risk) × 0.2. EVIDIQ also returns an explicit recommendation: proceed, proceed_with_escrow, caution, or do_not_proceed.

The short version: an open skill gives your agent a trust decision it can inspect. A trust score without a disclosed formula is merely another opaque API. We would rather publish the calculation and let builders challenge it.

What Vendor Lock-In Costs an Agent Builder

The bill arrives later. Migration work, lost auditability, emergency rewrites, and the uncomfortable possibility that a vendor pivot strands an otherwise healthy agent ecosystem. An open agent skill MCP turns those risks into ordinary engineering decisions instead of permanent constraints.

These are the concrete failure modes:

• Audit failure: You cannot determine which identity anchors or endpoint signals entered the calculation.
• Runtime failure: Your agent moves to a new host, but the vendor has not published an adapter.
• Fork failure: A security fix or product pivot is needed, but source access is restricted.
• Economic failure: Pricing or policy changes cannot be evaluated against an inspectable local contract.

This is where EVIDIQ’s live capability probe matters. The verifier performs a bounded request of roughly six seconds, checking reachability, TLS, and whether the endpoint exposes a machine-readable skill, agent card, or MCP surface. Your agent does not need to accept a vendor’s declaration that another agent is online and capable; it can verify the surface described by the contract.

The open agent skill MCP also separates evidence from authority. EVIDIQ produces a report and recommendation, but it never holds funds or grants execution authority. The parties decide whether to settle directly, use escrow, or define dispute rights. proceed_with_escrow is a recommendation, not EVIDIQ reaching into either wallet.

A plugin can be replaced, but a portable trust contract can move with the agent. That distinction becomes material when the runtime is rented, regulated by internal policy, or simply outside your control.

Three Places the Same Code Lives

The word “same” matters conceptually, not as a claim that three unrelated projects were copied without review. The open agent skill MCP contract is distributed across three surfaces: the canonical skill served publicly, the MCP implementation repository, and the skill specification repository. Each surface has a distinct job.

Start with evidiq.dev/skill.md. This is the readable Agent Skill entry point builders and agents can fetch directly. It explains what EVIDIQ is, which tools are available, how installation works, and how the verification result should be interpreted. Because it is Markdown, the contract survives proprietary build tools and can be reviewed in any normal source viewer.

The public remote server lives at evidiq.dev/mcp. It exposes how_to_install and get_evidiq_skill as free tools, while verify_agent is a paid per-call operation using x402. The challenge uses the x402 v2 accepts[].amount field and settles exact payments through EIP-3009 transferWithAuthorization on X Layer in USDT0. The corresponding EVIDIQ MCP repository is MIT-licensed, so the server’s public nature is backed by source you can inspect.

Finally, the Agent Skill repository keeps the skill specification itself open. This separation prevents an implementation detail from silently becoming the only definition of the contract. Changes to a server can be reviewed in the MCP repository; changes to the skill’s instructions remain visible in their own repository. Both use the same MIT license, and no private source is required to understand the public contract.

Separating those surfaces also gives builders a practical recovery path. Pin the Agent Skill digest in a build, review repository changes before upgrading, and retain the public MCP endpoint independently. If your team is connecting the agent side rather than operating a client, the EVIDIQ Operator docs provide the relevant next reference point.

Verification extends beyond the numeric response. EVIDIQ canonicalizes a verified report and hashes it with keccak256. Evidence is anchored on 0G Storage mainnet, which returns an on-chain transaction. When requested, AI risk analysis can run on 0G Compute with GLM-5.2 inside a TEE, recording the provider address and request ID before the verdict is signed with the EVIDIQ key using EIP-191.

Anyone can re-fetch the evidence, re-hash the report, and recover the signer. Teams working with that evidence trail can consult the EVIDIQ Sentinel docs, while cryptographic report details belong in the EVIDIQ Notary docs. The evidence chain is tamper-evident, but it is not magic: local builders must still verify the returned fields and signatures.

Reputation needs precise language. In 2026, EVIDIQ scores reputation from identity anchors and live signals, including whether the endpoint operates a paid x402 service. It is not yet a full historical on-chain reputation registry. Calling it one would overstate the product, so we treat “available reputation signal” as the honest boundary.

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

Runtime ownership changes the installation strategy. A closed plugin normally ships for supported hosts and asks you to adapt your agent to its package. EVIDIQ exposes standard endpoints and readable instructions, so the same open agent skill MCP contract can be consumed by several kinds of clients.

1. Claude Code: register the public HTTP MCP server with claude mcp add --transport http evidiq https://evidiq.dev/mcp. The client receives the public EVIDIQ tool definitions; paid verification calls retain their x402 payment boundary.

2. Cursor: bootstrap a local MCP bridge with npx -y mcp-remote https://evidiq.dev/mcp, then add that local process through Cursor’s MCP configuration. If the deployed Cursor build supports remote HTTP MCP servers directly, point it at https://evidiq.dev/mcp instead. The important part is the endpoint, not a Cursor-specific EVIDIQ package.

3. Custom LangChain agent: fetch the canonical contract without inventing a private package:

   python -c "import urllib.request; open('evidiq-skill.md','wb').write(urllib.request.urlopen('https://evidiq.dev/skill.md').read())"

A custom runtime has no honest universal pip install evidiq command because it may use different message formats, policies, and MCP clients. That one-liner installs the source of truth into the build. Your loader can then parse the instructions, expose the MCP tools, and decide how the resulting recommendation affects tool execution.

We built EVIDIQ’s interfaces this way so integration does not depend on EVIDIQ controlling your agent. The Agent Skill is portable text, the public MCP server is a standard remote service, and both implementation repositories are MIT-licensed. Our scoring formula and evidence pipeline are also inspectable, making the open agent skill MCP useful even when the host vendor never ships a plugin.