What can you do with this server?

EVIDIQ MCP is a trust-layer server that helps agents verify, score, and assess the risk of counterparty agents before any value is exchanged. Tools available: * how_to_install (free): Step-by-step guidance on connecting the EVIDIQ MCP server or installing the EVIDIQ trust skill into your agent. * get_evidiq_skill (free): Fetches the latest EVIDIQ agent skill in markdown format, outlining the full verify → score → reputation → attest workflow and routing tables. * verify_agent (paid via x402): The primary function — performs a comprehensive trust check on a counterparty agent and returns: * A trust score (0–100) * A risk tier and risk breakdown * A recommendation (proceed, escrow, or walk away) * A signed attestation anchored on 0G Storage with on-chain reputation data Key notes: * Free tools require no authentication. * verify_agent is metered per call using the x402 pay-per-call protocol (EIP-3009 payment signature required). * Trust reports are backed by AI risk analysis via 0G compute/TEE and cryptographically attested using keccak256 + EIP-191 signatures.

Which integrations are available for this server?

Provides trust verification capabilities for agents on OKX's AI ASP and X Layer blockchain, enabling pay-per-call (x402) and on-chain reputation checks.

How do I use EVIDIQ MCP?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@EVIDIQ MCP verify counterparty 0x1a2b...3c4d" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

EVIDIQ MCP by evidiq

This is the EVIDIQ Model Context Protocol server — the remote endpoint that exposes EVIDIQ's trust tools to any MCP-capable agent. It verifies a counterparty's capability, scores its risk, checks its on-chain reputation, and returns a signed Trust Report so an agent can decide to proceed, escrow, or walk away — before any value moves.

Live at https://evidiq.dev/mcp (Streamable HTTP).

Connect

Claude Code:

claude mcp add --transport http evidiq https://evidiq.dev/mcp

mcp.json / .mcp.json:

{
  "mcpServers": {
    "evidiq": { "url": "https://evidiq.dev/mcp" }
  }
}

Related MCP server: aip-identity

Tools

Tool	Access	What it returns
`how_to_install`	free	How to connect the server or install the skill.
`get_evidiq_skill`	free	The latest EVIDIQ Agent Skill (open-skill markdown).
`verify_agent`	paid (x402)	A Trust Report: score (0–100), tier, risk breakdown, recommendation, and a signed attestation anchored on 0G.

Resource: evidiq://skill — the live skill document.

Pay-per-call (x402)

verify_agent is metered per call over x402. Unauthenticated calls receive an HTTP 402 challenge (scheme exact, EIP-3009); sign it and retry with a PAYMENT-SIGNATURE header. Pricing/discovery is at GET /x402. The free tools stay free, and the gate is a no-op until payment is configured, so the server runs in either mode.

How a check runs

probe endpoint  →  score identity · capability · reputation · risk
               →  AI risk analysis (GLM via 0G compute / TEE)
               →  attest: keccak256(report) + 0G Storage + EIP-191 signature
               →  Trust Report

Source layout

Path	Description
`route.ts`	MCP route handler — registers the tools + resource; mounts at `/mcp`.
`lib/x402/`	x402 pay-per-call gate (config, challenge, verify, facilitator).
`lib/trust/`	Endpoint probe, deterministic scoring, and report types.
`lib/og/`	0G Storage, compute (GLM / TEE), and attestation.
`lib/skill.ts`, `lib/install.ts`	The skill document + install instructions.
`lib/request-context.ts`	Per-request base URL + payment context.

The canonical deployment runs this handler as a Next.js Route Handler in the EVIDIQ platform. The skill it serves lives at evidiq/evidiq-skill.

License

Available Tools

3 tools

get_evidiq_skillGet the EVIDIQ trust skillA

Fetch the latest EVIDIQ agent skill (markdown, open-skill format) so you can load and act on it — the verify → score → reputation → attest workflow and routing tables. Free.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.6/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are present, so the description carries full burden for behavioral disclosure. It mentions the tool fetches data and labels it as 'Free,' but does not specify whether it is read-only, idempotent, or requires authentication. Safety and side effects are not addressed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that conveys purpose, format, and context efficiently with no redundant words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple no-parameter fetch tool, the description provides the output format and a workflow hint. However, it lacks details about the skill content or expected behavior after fetching, which could be useful but is not critical given the tool's simplicity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There are zero parameters, and schema coverage is trivially 100%. The description adds meaning by specifying the output format (markdown, open-skill format) and workflow context, which is helpful but not necessary given no parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Fetch') and resource ('latest EVIDIQ agent skill' in markdown format), and implicitly distinguishes from siblings (how_to_install and verify_agent) by focusing on fetching the skill itself.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description does not provide guidance on when to use this tool versus the sibling tools (how_to_install, verify_agent), nor does it mention prerequisites or context. The agent has no basis to decide between fetching the skill and performing other actions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

how_to_installHow to install / connect EVIDIQA

Explain how to connect the EVIDIQ MCP server or install the EVIDIQ trust skill into your agent. Call this when the user asks to install, add, set up, or onboard EVIDIQ. Free.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.5/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden. It accurately frames the tool as providing explanatory content (how-to instructions) with no destructive or unexpected side effects. It is transparent about its informational nature.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences long, front-loading the core action and then providing a clear trigger phrase. Every sentence earns its place with zero waste.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has no parameters, no output schema, and is purely informational, the description fully covers what the tool does and when to use it. No gaps or missing context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has no parameters, and schema description coverage is 100% (vacuously). The description adds no param-specific info, which is appropriate since there are none. A baseline of 4 is justified for a zero-parameter tool.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool 'explain how to connect the EVIDIQ MCP server or install the EVIDIQ trust skill into your agent'. This specific verb+resource combination distinguishes it from siblings like 'get_evidiq_skill' and 'verify_agent'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly says 'Call this when the user asks to install, add, set up, or onboard EVIDIQ.' This provides clear context for invocation, though it does not mention when not to use it or directly reference sibling tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

verify_agentVerify an agent and get a Trust ReportA

The core EVIDIQ trust check. Given an agent to transact with, verifies its capability, scores its risk, checks its on-chain reputation, and returns a Trust Report (score, tier, breakdown, recommendation) with a signed attestation anchored on 0G when configured. Supply everything you know about the counterparty for the sharpest verdict.

ParametersJSON Schema

Name	Required	Description
`target`	No	Alias for agentId.
`agentId`	No	REQUIRED. A stable identifier for the agent being checked (address, URL, name, or id). Send as camelCase "agentId". snake_case aliases agent_id / target / target_name are also accepted.
`context`	No	What the deal is about / why the check is being run.
`agent_id`	No	Alias for agentId.
`endpoint`	No	The agent's service URL / MCP endpoint. EVIDIQ probes it for a live trust signal.
`identity`	No	Identity anchors: EVM address, ENS, ERC-8004 id, domain.
`framework`	No	Framework the agent is built on (LangChain, AutoGen, …).
`target_name`	No	Alias for agentId.
`declaredCapabilities`	No	Capabilities the agent claims to have.
`declared_capabilities`	No	Alias for declaredCapabilities.

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It discloses that it probes the agent's endpoint for a live trust signal, performs capability verification, risk scoring, on-chain reputation check, and returns a signed attestation anchored on 0G. No contradictions or omissions noted.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise: three sentences front-load the core function, details, and guidance. No unnecessary words; each sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite lacking an output schema, the description explains the return value (Trust Report with score, tier, breakdown, recommendation, signed attestation). For a verification tool with 10 parameters, it covers the essential behavioral and output aspects, leaving limited gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description adds minor value by emphasizing that agentId is required (despite schema not marking it required) and listing alias names, but does not significantly enrich parameter understanding beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The title and description clearly state this is the core trust check tool that verifies agent capability, scores risk, checks on-chain reputation, and returns a Trust Report. It distinguishes itself from siblings like get_evidiq_skill and how_to_install.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage: verify an agent before transacting. It advises supplying all known counterparty info for best results. However, it lacks explicit when-not-to-use guidance or alternatives beyond context from sibling names.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

3 tool updatesv0.1.0Jul 15, 2026
- First observedget_evidiq_skill
- First observedhow_to_install
- First observedverify_agent

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4/5.0

Scored 2026-07-15 21:10 across 3 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: fetching a skill document, providing installation instructions, and performing a trust verification. No overlap in functionality.

Naming Consistency3/5

Names mix patterns: 'get_evidiq_skill' and 'verify_agent' follow verb_noun, but 'how_to_install' is a phrase. The inconsistency is noticeable in such a small set.

Tool Count5/5

Three tools cover the core operations of the server: skill retrieval, installation help, and agent verification. This is well-scoped for the server's purpose.

Completeness4/5

The tool set covers the primary workflows (skill loading, setup, trust checks). Minor gaps like managing multiple skills or reviewing past reports could exist, but the core is complete.

Maintenance

ActivityMaintained

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

Dominion Observatory
com.dominionobservatory
Trust checks for MCP servers: trust scores, tool-drift detection, signed diligence receipts. Free.
Security Observability
2
zeroidagent-mcp
com.clauxel.zeroidagent
A paid remote MCP for ZeroID, built to return verdicts, receipts, usage logs, and audit-ready JSON.
Security Legal & Compliance
2
AIﾉアカリ☆ Agent Trust Receipt A
ai.ai-akari
Read-only Remote MCP for externally grounded AI agent trust receipts.
Security Autonomous Agents
22
VerifyMCP A
io.verifymcp
Independent trust scores, tool surfaces and change history for MCP servers.
Developer Tools
91

Related MCP Servers

mcp-server-insumer
Blockchain Finance Security
douglasborthwick-crypto
A
license
A
quality
A
maintenance
MCP server for on-chain attestation and wallet trust profiles across 31 EVM chains and Solana. Privacy-preserving boolean verification, ECDSA-signed responses, compliance templates.
Updated 14 days ago (2026-09-02 21:48 UTC)
27
149 npm
1
MIT
aip-identity
Autonomous Agents Security
The-Nexus-Guard
A
license
A
quality
D
maintenance
MCP server for AI agent identity — verify agents with Ed25519 signatures, check trust scores, sign and verify content, exchange encrypted messages. Built on the Agent Identity Protocol (AIP).
Updated 6 months ago (2026-03-09 12:03 UTC)
8
MIT
AgentTrust
Security Autonomous Agents
raditotev
F
license
A
quality
D
maintenance
Reputation and trust scoring service for AI agents, exposed as an MCP server. Evaluate counterparties, report interactions, issue portable trust certificates, and detect Sybil attacks.
Updated 6 months ago (2026-03-22 16:24 UTC)
23
-
MCP Trust Gateway
Security Autonomous Agents
a2a-settlement
A
license
Not graded
quality
D
maintenance
Enables trust, reputation, and economic accountability for MCP by proxying between clients and servers, enriching every tool invocation with trust evaluation, KYA tiers, spending limits, and delegation chains.
Updated 6 months ago (2026-03-17 02:45 UTC)
MIT