What can you do with this server?

The ThoughtProof MCP server verifies AI-generated reasoning and claims using adversarial multi-model consensus (Grok, Gemini, DeepSeek, Sonnet), helping you decide whether to trust and act on AI outputs. * Verify claims and reasoning: Submit any decision or reasoning claim via verify_claim / verify_reasoning to receive a verdict (ALLOW, HOLD, UNCERTAIN, or DISSENT), a confidence score, and up to 3 key objections explaining why a claim may be challenged * Domain-specific verification: Tailor analysis to financial, medical, legal, code, or general contexts for more accurate assessments * Risk-adjusted analysis: Set a stake level (low, medium, high, critical) to adjust confidence thresholds based on decision consequence * Adjust verification depth: Choose between fast (2 models), standard (4 models), or deep (5+ models) to balance speed and cost ($0.008–$0.08 per verification) * Check agent trust scores: Use check_agent_score to look up composite trust scores for specific agents, optionally filtered by domain * Guard against hallucinations: Use verdicts and objections to validate AI outputs before acting on them

Which integrations are available for this server?

Allows looking up agent trust scores on the ERC-8004 registry, an Ethereum-based autonomous agent registry.

thoughtproof-mcp

Official

by ThoughtProof

Overview Schema Source Related Servers Discussions Admin

JavaScript

Remote

thoughtproof-mcp

npm version HOL Guard Scanner License: MIT

thoughtproof-mcp — local stdio. Hero tool verify_decision (DQL spend / Sentinel irreversible exit). execute is true only on ALLOW.

MCP server for ThoughtProof — pre-execution decision verification for AI agents.

Hero tool: verify_decision. It routes inside the tool to DQL (spend / checkout) or Sentinel (irreversible exit) and returns a fail-closed execute flag. execute is true only on a native ALLOW.

This package is a local stdio MCP server (Node 18+) for Desktop / CLI hosts such as Cursor, Claude Desktop, Windsurf, and Cline. It is not a remote HTTP MCP server. It is not a Grok Web/Mobile custom connector.

Get keys at https://app.thoughtproof.ai/pricing.

Unpublished work is documented in UNRELEASED.md.

Quick Start

{
  "mcpServers": {
    "thoughtproof": {
      "command": "npx",
      "args": ["-y", "thoughtproof-mcp@0.3.2"],
      "env": {
        "DQL_API_KEY": "<YOUR_DQL_VERIFY_KEY>"
      }
    }
  }
}

Install with npx -y thoughtproof-mcp@0.3.2. Works with Claude Desktop, Cursor, Windsurf, Cline, and other local stdio MCP clients.

Related MCP server: agentshield-mcp

Tools

`verify_before_action` / `verify_decision` (hero)

verify_before_action is an alias of verify_decision (identical schema + handler). Soft fail-closed: host must honor execute=false.

Pre-execution gate for a proposed action. Routing is inside the tool — not an agent quiz.

Parameter	Type	Default	Description
`mandate`	string	(required)	User's stated goal / instruction
`proposed_action`	string	(required)	What the agent is about to do
`reasoning`	string	(required)	The agent's own plan / reasoning
`context`	string	(optional)	Extra evidence
`mode`	`dql` / `sentinel` / `auto`	`auto`	Explicit surface, or auto-route

Auto-route: spend / checkout / booking / purchase / payment / cart / Stripe / price / budget / cap → DQL. High-blast irreversible exit without that language (publish, delete, deploy, send-to-prod, memory write) → Sentinel. Unsure → DQL. Explicit mode wins. RV / PLV are not on this path.

Camera mandate: do not put the overshoot in proposed_action or reasoning (for example, do not write “price is above the cap”). The verifier has to find the mismatch.

Envelope (always this shape):

{
  "verdict": "ALLOW",
  "execute": true,
  "objections": [],
  "receipt_id": "dql_…",
  "surface": "dql",
  "axes": [],
  "recommendation": "execute"
}

execute is true only on ALLOW. REVIEW, UNCERTAIN, BLOCK, timeouts, HTTP 402/4xx/5xx, and missing keys return execute: false. Fail-closed is soft at the protocol layer — the tool does not hard-stop the host. Replan is a new call (new receipt).

`verify_claim`

Verify any claim or AI-generated reasoning via RV (POST /v1/check). Unchanged.

Parameter	Type	Default	Description
`claim`	string	(required)	The text to verify
`stakeLevel`	`low` / `medium` / `high` / `critical`	`medium`	Risk level — higher stakes trigger deeper verification
`domain`	`financial` / `medical` / `legal` / `code` / `general`	`general`	Domain context for specialized verification
`speed`	`fast` / `standard` / `deep`	`standard`	Verification depth

`check_agent_score`

Look up an agent's composite trust score on the ERC-8004 registry.

Parameter	Type	Description
`agentId`	string	Agent ID to look up
`domain`	string	Optional domain filter

`verify_trade`

Optional pre-execution gate for trading agents (Sentinel → RV). Not the default verify_decision path. See VERIFY_TRADE.md.

Configuration

Environment Variable	Default	Description
`DQL_API_KEY`	(none)	DQL key (`dqlk_…`) for the default `verify_decision` path. Alias: `THOUGHTPROOF_DQL_KEY`
`SENTINEL_API_KEY`	(none)	Optional. Required only when `mode=sentinel` or auto-route picks Sentinel. Fallback: `THOUGHTPROOF_API_KEY` as `X-Sentinel-Key`
`DQL_SANDBOX`	(off)	Set to `1` to send `sandbox: true` on DQL calls (local/dev only)
`THOUGHTPROOF_API_KEY`	(none)	Operator key for `verify_claim` / `verify_trade` / Sentinel fallback
`THOUGHTPROOF_BASE_URL`	`https://api.thoughtproof.ai`	RV API base URL (`verify_claim`)

A missing Sentinel key returns execute: false with “Sentinel key not configured” — it does not silently call DQL.

Development

git clone https://github.com/ThoughtProof/thoughtproof-mcp.git
cd thoughtproof-mcp
npm install
npm run build
npm test
npm run dev          # Run with tsx (hot reload)
npm run inspect      # Test with MCP Inspector

For local MCP clients, point command at node and args at dist/index.js after npm run build.

Security

See SECURITY.md for supported versions, private reporting (security@thoughtproof.ai), and key handling (dqlk_… for MCP hero — never commit real keys).

HOL listing / Guard scanner score is a review baseline only. It is not next-action authorization and not a substitute for fail-closed host behavior (execute: true only on ALLOW).

ThoughtProof — Decision verification for AI agents
pot-cli — CLI for reasoning verification
ERC-8004 — Autonomous Agent Registry

License

MIT — ThoughtProof

Available Tools

5 tools

check_agent_scoreD

ParametersJSON Schema

Name	Required	Description	Default
`domain`	No	Optional domain filter for the score
`agentId`	Yes	The agent ID to look up (e.g. 'agent_abc123xyz')

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

verify_before_actionA

ThoughtProof pre-action verification gate: verify before the agent pays, trades, writes, or deploys. Call this BEFORE any consequential tool (payment, trade, transfer, publish, delete, deploy, irreversible write). Returns { verdict, execute, objections, structured_objections, receipt_id, surface, loop, axes?, recommendation, in_reply_to? }. execute is true ONLY on ALLOW — on any other result do NOT execute (soft fail-closed; host must honor execute=false). If structured_objections have severity blocked_until, repair using repair_hints and call again with in_reply_to set to that objection_id (new receipt; prior ALLOW does not carry). Routes internally to DQL (spend/checkout) or Sentinel (irreversible exit). Camera mandate: you must NOT put the overshoot or constraint violation in proposed_action or reasoning (for example, do not write "price is above the cap"). Put the user goal in mandate, the action you are about to take in proposed_action, and your plan in reasoning — the verifier must find the mismatch. Optional mandate_kind / action_kind declare Sentinel ActionKind (informational | value_transfer | permission | deploy_ship | unknown) — omit rather than guess. Replan = new call = new receipt. Aliases: verify_decision, verify_before_action, verify_before_act.

ParametersJSON Schema

Name	Required	Description
`mode`	No	Routing override. auto (default) picks DQL for spend/checkout language and Sentinel for high-blast irreversible exits; unsure → DQL. Explicit mode wins.
`quote`	No	Optional verbatim excerpt of the user's mandate (copy the user instruction, do not paraphrase). Wired into Sentinel evidence for provenance. Must be at least 20 characters and an exact substring of mandate; otherwise the full mandate is used as the quote.
`context`	No	Optional extra evidence, tool outputs, or prior turns.
`mandate`	Yes	The user's stated goal or instruction the agent is acting on.
`reasoning`	Yes	The agent's own plan or reasoning. Do not include the overshoot; the verifier has to find the mismatch.
`action_kind`	No	Optional host-declared Sentinel ActionKind for the proposed action (action.kind). Values: informational \| value_transfer \| permission \| deploy_ship \| unknown. Sentinel prefers this over prose classification. Omit rather than guess.
`in_reply_to`	No	objection_id from a prior envelope structured_objections item. Marks this call as a repair. New receipt; prior ALLOW does not carry.
`mandate_kind`	No	Optional host-declared Sentinel ActionKind for the mandate (mandate.kind). Values: informational \| value_transfer \| permission \| deploy_ship \| unknown. Sentinel prefers this over prose classification. Omit rather than guess.
`proposed_action`	Yes	What the agent is about to do (pay/trade/write/deploy/…). Do not include the overshoot or constraint violation here.

TDQS

A4.6/5.0

Behavior5/5

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

With no annotations, the description fully discloses behavior: the return envelope fields, fail-closed contract ('execute is true ONLY on ALLOW'), the camera mandate to omit overshoot from proposed_action/reasoning, routing to DQL/Sentinel, and the rule that a new receipt invalidates prior ALLOW. This is far beyond a minimal statement.

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 long but dense; every sentence carries operational necessity, from call timing to fail-closed rules, repair flow, routing, and camera mandate. It front-loads the core purpose and layers essential details without filler.

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?

For a high-stakes tool with 9 parameters and no output schema, the description covers invocation timing, return envelope fields, failure semantics, repair loop, routing, and parameter usage. Nothing an agent needs to call it correctly is missing.

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

Parameters5/5

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

Although schema coverage is 100%, the description adds crucial operational meaning: the camera mandate explains how to populate mandate/proposed_action/reasoning, in_reply_to is tied to structured_objections with a new receipt, and action_kind/mandate_kind should be omitted rather than guessed.

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

Purpose4/5

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

The description states a specific purpose: a pre-action verification gate before payments, trades, writes, or deploys, and clarifies it returns a verdict and execute flag. However, it does not explicitly differentiate from sibling tools like verify_claim or verify_trade beyond listing verify_decision as an alias.

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?

Explicitly instructs to call before any consequential tool (payment, trade, transfer, publish, delete, deploy, irreversible write) and defines the repair flow with in_reply_to. It does not state when not to use it or point to alternatives for other verification tasks.

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

verify_claimD

ParametersJSON Schema

Name	Required	Description
`claim`	Yes	The claim or AI-generated reasoning to verify. Can be a statement, decision, analysis, or any text that needs adversarial verification.
`speed`	No	Verification depth. fast=$0.008 (2 models), standard=$0.02 (4 models), deep=$0.08 (5+ models). Default: standard
`domain`	No	Domain context for specialized verification. Default: general
`stakeLevel`	No	Risk level — higher stakes trigger more thorough verification. Default: medium

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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

verify_decisionA

ParametersJSON Schema

Name	Required	Description
`mode`	No	Routing override. auto (default) picks DQL for spend/checkout language and Sentinel for high-blast irreversible exits; unsure → DQL. Explicit mode wins.
`quote`	No	Optional verbatim excerpt of the user's mandate (copy the user instruction, do not paraphrase). Wired into Sentinel evidence for provenance. Must be at least 20 characters and an exact substring of mandate; otherwise the full mandate is used as the quote.
`context`	No	Optional extra evidence, tool outputs, or prior turns.
`mandate`	Yes	The user's stated goal or instruction the agent is acting on.
`reasoning`	Yes	The agent's own plan or reasoning. Do not include the overshoot; the verifier has to find the mismatch.
`action_kind`	No	Optional host-declared Sentinel ActionKind for the proposed action (action.kind). Values: informational \| value_transfer \| permission \| deploy_ship \| unknown. Sentinel prefers this over prose classification. Omit rather than guess.
`in_reply_to`	No	objection_id from a prior envelope structured_objections item. Marks this call as a repair. New receipt; prior ALLOW does not carry.
`mandate_kind`	No	Optional host-declared Sentinel ActionKind for the mandate (mandate.kind). Values: informational \| value_transfer \| permission \| deploy_ship \| unknown. Sentinel prefers this over prose classification. Omit rather than guess.
`proposed_action`	Yes	What the agent is about to do (pay/trade/write/deploy/…). Do not include the overshoot or constraint violation here.

TDQS

A4.3/5.0

Behavior5/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure, and it does so thoroughly. It explains the fail-closed semantics ('execute is true ONLY on ALLOW — on any other result do NOT execute'), the receipt/repair model, the camera mandate about not revealing overshoot in proposed_action/reasoning, and that replanning requires a new call. This goes well beyond the schema.

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

Conciseness4/5

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

The description is long but dense with critical behavioral rules—fail-closed behavior, camera mandate, repair flow, routing, and aliases. Each sentence earns its place, and the core purpose is front-loaded. A modest amount of redundancy exists around the camera mandate, but overall it is appropriately structured for a high-stakes verification tool.

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?

This is a complex tool with 9 parameters, 3 required, and no output schema. The description covers the return envelope fields, the execute flag semantics, the repair flow, routing modes, and the camera mandate—everything an agent needs to call it correctly. Nothing critical for safe invocation appears missing.

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?

Schema coverage is 100%, so the baseline is 3, but the description adds valuable usage semantics beyond the schema: it tells the agent to put the user goal in mandate, the action in proposed_action, and the plan in reasoning, and to omit rather than guess the optional kind fields. It could go further with concrete examples, but it meaningfully enhances the placeholder descriptions.

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

Purpose4/5

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

The description clearly states a specific verb and resource: it is a pre-action verification gate called before consequential actions like paying, trading, writing, or deploying. It is unambiguous about what the tool does, but it does not explicitly differentiate itself from sibling tools such as verify_claim or verify_trade—it lists aliases instead.

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 gives explicit when-to-use guidance: 'Call this BEFORE any consequential tool (payment, trade, transfer, publish, delete, deploy, irreversible write).' It also explains internal routing between DQL and Sentinel and the repair flow. It does not name alternative sibling tools or state when NOT to use this tool, so it misses the full when/when-not comparison.

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

verify_tradeD

ParametersJSON Schema

Name	Required	Description
`action`	Yes	The action the agent intends to execute, e.g. 'open 5x long BTC, 8000 USDC margin' or 'swap 10 ETH for USDC'.
`thesis`	Yes	The agent's one-line decisive rationale for the action.
`reasoning`	Yes	The full reasoning chain that produced the decision — the actual chain of thought, not a summary. This is what ThoughtProof verifies.
`situation`	No	Optional market/context snapshot WITHOUT the chosen action. Lets the adversarial panel form an independent view before seeing the decision (stronger verification).
`stakeLevel`	No	Stake level — drives the verdict threshold. Higher stake demands higher reasoning soundness to ALLOW: the SAME decision can ALLOW at low stake and BLOCK/UNCERTAIN at critical stake. Default 'high' (suitable for leveraged capital). 'micro' runs the fast Sentinel-only gate; everything else runs the full Sentinel→RV adversarial pipeline.

TDQS

D1/5.0

Behavior1/5

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

Tool has no description.

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

Conciseness1/5

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

Tool has no description.

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

Completeness1/5

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

Tool has no description.

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

Parameters1/5

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

Tool has no description.

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

Purpose1/5

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

Tool has no description.

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

Usage Guidelines1/5

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

Tool has no description.

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.

6 tool updatesv0.1.1Sep 15, 2026
- Addedcheck_agent_score
- Addedverify_before_action
- Addedverify_claim
- Addedverify_decision
- Removedverify_reasoning
- Addedverify_trade
1 tool updatev0.1.0Mar 21, 2026
- First observedverify_reasoning

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

C2/5.0

Scored 2026-09-15 23:50 across 5 tools

Disambiguation1/5

verify_decision and verify_before_action are exact duplicates of the same tool exposed as separate entries, and verify_claim/verify_trade also overlap with the general verification concept. An agent cannot reliably distinguish which verification tool to call.

Naming Consistency3/5

Most tools follow a verify_* pattern, but check_agent_score breaks it, and verify_before_action is just an alias of verify_decision rather than a distinct operation. The convention is readable but not cleanly consistent.

Tool Count4/5

Five tools is a reasonable size for a focused verification server, though two are duplicates and three lack descriptions, so the effective distinct surface is smaller than the count suggests.

Completeness2/5

The core pre-action verification gate is described, but verify_claim, verify_trade, and check_agent_score have no descriptions, making their coverage unknowable. There are also no tools for managing receipts, reviewing prior objections, or repairing blocked decisions beyond the inline repair hints.

Maintenance

ActivityMaintained

ResponsivenessWithin a week

Resources

Need Help?

Related Servers

Related MCP Connectors

EthersFlow — Trust Gate for AI Agents
io.github.Ethersflow
Trust gate for AI agents: multi-model adversarial consensus, signed and verifiable verdicts.
Security
11
Second Opinion A
com.secondopinionx402
Adversarial verification for AI agents - pay an independent skeptic per verdict in USDC via x402.
Security Cryptocurrency AI & Machine Learning
62
DCL Trust Oracle — AI/LLM Output Audit (x402 MCP)A
com.fronesislabs
AI/LLM agent output audit MCP: policy eval, tamper-evident chain, AI safety, x402 USDC on Base.
Security Observability Payments & Billing
1811
Iron City C
com.sovereigntyempire
Sovereign AI agent economy: oracle-verified tools, escrow, arenas; paid in USDC on Base via x402.
Cryptocurrency Blockchain Autonomous Agents
102

Related MCP Servers

Thoughtproof-mcp
Autonomous Agents Finance Security
ThoughtProof
A
license
Not graded
quality
C
maintenance
Adversarial multi-model reasoning verification for AI agents. Claude, Grok, and DeepSeek challenge each decision — returns ALLOW or HOLD with JWKS-signed attestation. x402-gated on Base.
Updated 4 months ago (2026-05-08 16:35 UTC)
1 npm
MIT
agentshield-mcp
Blockchain Web3 & Decentralized Tech Finance
yeick010
F
license
A
quality
Not graded
maintenance
Trust infrastructure for AI agents on Base. DEX Spread Oracle (live Uniswap V3 prices), on-chain escrow, insurance pool, and collective knowledge base. 7 smart contracts. Pay-per-query via x402 micropayments in USDC.
Updated 5 months ago (2026-04-19 19:02 UTC)
6
-
dyoe-agent-tools-mcp
Autonomous Agents Cryptocurrency Web Scraping
bjyoe2016
F
license
A
quality
C
maintenance
Pay-per-call tools for AI agents including trust checks, due diligence, market data, and human-verified approvals, settled in USDC on Base via the x402 protocol.
Updated 3 months ago (2026-07-01 10:19 UTC)
16
-
SENTINEL
Blockchain Security Autonomous Agents
teodorofodocrispin-cmyk
F
license
A
quality
B
maintenance
Agent-Level Transaction Safety Oracle. Before an AI agent signs a blockchain transaction, it returns a SAFE/UNSAFE verdict with a SENTINEL Score (AAA-D) and risk flags. Pay-per-call $0.005 USDC via x402 on Base.
Updated 8 days ago (2026-09-11 04:24 UTC)
1
-

thoughtproof-mcp

Quick Start

Tools

verify_before_action / verify_decision (hero)

verify_claim

check_agent_score

verify_trade

Configuration

Development

Security

Related

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

`verify_before_action` / `verify_decision` (hero)

`verify_claim`

`check_agent_score`

`verify_trade`