Skip to main content
Glama

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/mcp

MCP Tools

Tool

Description

Price

sentinel_guard

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, mcp 1.26+)

  • Manifest: mcp_server.py (FastMCP, @mcp.tool())

  • Payment: x402 micropayments on Base

  • This sentinel-public repo is the public MCP interface; the tool delegates execution to the live endpoint at https://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 authenticated

SENTINEL — Built in Bogotá, Colombia. Part of the M2M x402 model family (VeraData, Intelica, TrustBoost, SENTINEL).

Available Tools

1 tool
sentinel_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"}.

ParametersJSON Schema
NameRequiredDescriptionDefault
txNo
chainNobase
from_addrNo

TDQS

A4.6/5.0
Behavior4/5

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.

Conciseness4/5

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.

Completeness4/5

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.

Parameters5/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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. 1 tool updatev1.0.0
    • First observedsentinel_guard

TDQS

A4.7/5.0

Scored across 1 tool

Disambiguation5/5

Only one tool exists, so there is no possibility of confusion. The tool's purpose is clearly defined.

Naming Consistency5/5

The single tool name 'sentinel_guard' is descriptive and follows a clear pattern. Consistency is trivially maintained with one tool.

Tool Count4/5

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.

Completeness5/5

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

ActivityMaintained
ResponsivenessNo issues

Related MCP Connectors

Related MCP Servers

  • 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.
    6
    -
  • A
    license
    Not graded
    quality
    C
    maintenance
    Security layer for AI agents that evaluates transaction intents and returns verdicts (ALLOW/WARN/DENY) using deterministic rules, on-chain checks, and simulation.
    1 npm
    MIT