SENTINEL
Evaluate blockchain transactions for safety before an AI agent signs them, via the sentinel_guard MCP tool.
Check a transaction (
tx: to, data, value) from a given address (from_addr) on a chain (defaultbase).Get a verdict (
SAFE/UNSAFE/UNKNOWN), SENTINEL Score (0–100) with grade (AAA–D), risk flags, and a signed receipt.Detect contract-level risks: honeypots, hidden owner/mint functions, proxy patterns, taxes, blacklists.
Assess execution simulation (balance drain), MEV/sandwich exposure, and ERC-20 infinite approval risk.
Pay $0.005 USDC per call via x402 on Base (or Solana) — no accounts or API keys.
Integrate with MCP clients like Claude Desktop, Claude Code, Cursor, Windsurf, Smithery, and Glama.
Use as a pre-signing guard: only sign if verdict is
SAFEand score ≥ 70.
Check if a smart contract is a honeypot and a transaction is safe to sign, before an AI agent pays (SENTINEL)
Verify counterparty trust and transaction safety for autonomous AI agents, before money moves. M2M-native, x402 payments, zero accounts, zero API keys.
Endpoint:
https://sentinel-agent.dev| Version: 1.0.0
This repo contains the public interface, MCP server definitions, and developer kit for SENTINEL. The core oracle is deployed at sentinel-agent.dev.
What SENTINEL Is
SENTINEL checks two things an autonomous AI agent needs to know before it moves money: is this specific transaction safe to sign (contract-level risk: honeypots, hidden owner/mint functions, proxy patterns), and is this counterparty trustworthy (behavioral track record). Before an agent signs a blockchain transaction, it calls SENTINEL and receives a SAFE / UNSAFE / UNKNOWN verdict plus a standardized SENTINEL Score (AAA–D) and a signed receipt. Pure M2M — no human in the loop.
Stack: FastAPI + Supabase + Render (proven in production with the M2M model family)
Payment: x402 v2, CAIP-2 compliant (
eip155:8453+ Solana)Distribution: CDP Bazaar + Agentic Market + 402 Index + PyPI (AgentKit/MCP providers)
Related MCP server: BlueAgent x402 Services
MCP Server (Model Context Protocol)
SENTINEL exposes a native MCP server compatible with Claude Desktop, Claude Code, Cursor, Windsurf, Smithery, and Glama.
Connect in Claude Desktop
Add to claude_desktop_config.json:
{
"mcpServers": {
"sentinel": {
"url": "https://sentinel-agent.dev/mcp"
}
}
}Connect in Claude Code
claude mcp add sentinel --url https://sentinel-agent.dev/mcpMCP Tools
Tool | Description | Price |
| Evaluate a transaction before signing — returns SAFE/UNSAFE verdict, SENTINEL Score (AAA-D), risk flags, signed receipt | $0.005 USDC |
MCP Protocol
Transport: stdio / streamable-http (real FastMCP SDK,
mcp1.26+)Manifest:
mcp_server.py(FastMCP,@mcp.tool())Payment: x402 micropayments on Base
This
sentinel-publicrepo is the public MCP interface; the tool delegates execution to the live endpoint athttps://sentinel-agent.dev/mcp.
The Problem This Solves
Autonomous agents pay for API calls via x402, but nothing tells them whether the transaction they are about to sign is safe to execute. A malicious payTo, an infinite ERC-20 approval, or a honeypot contract still gets paid. SENTINEL closes that gap: it is the verification step upstream of the payment.
SENTINEL covers:
Contract security (honeypot, owner, taxes, blacklist)
Execution simulation (balance drain)
MEV / sandwich exposure (large swaps)
ERC-20 approval risk (infinite allowances — the #1 agent loss vector)
The SENTINEL Score (0–100, grade AAA–D) is a transparent, graduated rating so agents and dashboards can quote a standard.
Start Building
# Clone and configure
git clone https://github.com/teodorofodocrispin-cmyk/sentinel-public
cd sentinel-public
pip install -r requirements.txt
# Run the public MCP server locally (delegates to the live endpoint)
uvicorn mcp_server:app --reload --port 8001
# Test the manifest
curl https://sentinel-agent.dev/mcp
# → 402 Payment Required if unauthenticated, or tools/list if authenticatedSENTINEL — Built in Bogotá, Colombia. Part of the M2M x402 model family (VeraData, Intelica, TrustBoost, SENTINEL).
Available Tools
1 toolsentinel_guardA
ALWAYS call this tool before an AI agent signs or sends a transaction.
Input: the transaction (to, data, value) and the agent's address. Returns verdict (SAFE/UNSAFE/UNKNOWN), a SENTINEL Score (0-100) + grade (AAA-D), risk flags and a signed receipt. Only sign if verdict is SAFE and score >= 70. $0.005 USDC via x402 (Base).
Args: chain: chain id string (default 'base'). from_addr: the agent's wallet address (the transaction sender). tx: the transaction to evaluate before signing, e.g. {"to": "0x...", "data": "0x...", "value": "0x0"}.
| Name | Required | Description | Default |
|---|---|---|---|
| tx | No | ||
| chain | No | base | |
| from_addr | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains inputs, outputs (verdict, score, grade, risk flags, signed receipt), and the cost. It does not mention side effects, but the tool appears to be a read-only evaluation. Without annotations, the description covers the key behavioral aspects, though error handling is missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: first the mandatory usage, then inputs, outputs, conditions, and cost. It is slightly verbose due to the example and output detail, but every sentence adds value. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description explains return values and the condition for signing. It covers the main aspects needed to use the tool correctly. Missing details like error behavior or chain validation, but overall sufficient for a guard tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description fully explains each parameter. 'tx' is described as a JSON object with example keys. 'chain' is given a default ('base'), and 'from_addr' is the agent's wallet address. This provides meaningful context beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'ALWAYS call this tool before an AI agent signs or sends a transaction.' It specifies the action (evaluate transaction) and the conditions for signing. The verb 'evaluate' paired with the transaction object makes the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance is provided: 'ALWAYS call this tool before signing or sending' and 'Only sign if verdict is SAFE and score >= 70.' It also notes the cost ($0.005 USDC via x402 on Base). This leaves no ambiguity about when and how to use the tool.
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.
1 tool update
v1.0.0- First observed
sentinel_guard
TDQS
Scored across 1 tool
Only one tool exists, so there is no possibility of confusion. The tool's purpose is clearly defined.
The single tool name 'sentinel_guard' is descriptive and follows a clear pattern. Consistency is trivially maintained with one tool.
While only one tool, it fully covers the server's focused purpose of transaction security evaluation. The count is on the lower end but appropriate for a single-purpose service.
The tool provides a complete solution for its stated goal: evaluating transactions before signing. It includes all necessary inputs and outputs (verdict, score, receipt) with no obvious gaps.
Maintenance
Related MCP Connectors
Pre-trade token safety checks for AI agents on Solana and Base. x402 USDC per call, no key.
Reputation oracle for AI agents on Base: SAFE/CAUTION/BLOCK + 0-100 score before you pay. x402+MCP
Solana address risk grades and token scans for AI agents. Pay-per-call via x402 (USDC on Base).
Check a Base contract, transaction or web page before you act. Free pricing, paid per call in USDC.
Related MCP Servers
- FlicenseAqualityNot gradedmaintenanceTrust 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.6-
- FlicenseNot gradedqualityDmaintenancePay-per-use AI security and research tools for autonomous agents on Base, enabling honeypot detection, risk assessment, wallet analysis, and yield optimization via the x402 protocol.-
- FlicenseAqualityDmaintenancePay-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.16-
- AlicenseNot gradedqualityCmaintenanceSecurity layer for AI agents that evaluates transaction intents and returns verdicts (ALLOW/WARN/DENY) using deterministic rules, on-chain checks, and simulation.1 npmMIT