Which integrations are available for this server?

Provides a Coinbase AgentKit ActionProvider for M2M Sentinel, enabling autonomous agents on Base to perform deterministic EVM bytecode capability intelligence, EIP-1967 proxy resolution, and preflight guards for contract interactions.

M2M Sentinel

Official

by M2M-Sentinel

Overview Schema Source Related Servers Discussions Admin

JavaScript

Hybrid

M2M Sentinel SDK & MCP Server

Official multi-language client library, Model Context Protocol (MCP) server, and Coinbase AgentKit ActionProvider for M2M Sentinel — deterministic EVM bytecode capability observations and common-proxy resolution for autonomous applications operating on Base. Callers own transaction policy.

npm version PyPI version License: MIT Smithery

⚡ 1. Model Context Protocol (MCP) Server

Connect M2M Sentinel directly to Claude Desktop, Cursor, Windsurf, or any MCP-compliant LLM agent.

Option A: 1-Click via Smithery

npx -y @smithery/cli mcp add M2M-Sentinel/m2m-sentinel-sdk --client claude

Option B: Local Stdio (`claude_desktop_config.json`)

{
  "mcpServers": {
    "m2m-sentinel": {
      "command": "npx",
      "args": ["-y", "m2m-sentinel-sdk"],
      "env": {
        "M2M_SENTINEL_API_KEY": ""
      }
    }
  }
}

Option C: Remote Streamable HTTP

Current MCP endpoint: https://api.m2msentinel.com/mcp
Legacy HTTP+SSE compatibility: https://api.m2msentinel.com/sse with messages at https://api.m2msentinel.com/messages

Related MCP server: agentradar

🤖 2. Coinbase AgentKit Integration

import { AgentKit } from "@coinbase/agentkit";
import { m2mSentinelActionProvider } from "m2m-sentinel-sdk";

const agentKit = await AgentKit.from({
  walletProvider,
  actionProviders: [
    m2mSentinelActionProvider({
      apiKey: process.env.M2M_SENTINEL_API_KEY
    })
  ]
});

📦 3. JavaScript / TypeScript Client

npm install m2m-sentinel-sdk

const { M2MSentinelClient } = require('m2m-sentinel-sdk');

const client = new M2MSentinelClient();

async function main() {
  const audit = await client.auditContract('0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913');
  console.log('Proxy Detected:', audit.audit.proxyResolution.isProxy);
  console.log('Proxy Target:', audit.audit.proxyResolution.targetAddress);
  console.log('Capabilities:', audit.audit.verdict.executableCapabilities);
  console.log('Evidence:', audit.audit.dissection.capabilities);
}

main().catch(console.error);

🛡️ Base Account `wallet_sendCalls` Guard

The public SDK includes guardWalletSendCalls, a customer-side execution-identity boundary for Base Account / EIP-5792 batches. It preflights the anchor call and evaluates its caller policy before scheduling any remaining call, then pins remaining calls to the first trusted block identity in waves of at most four. Each settled wave is validated and policy-checked in ascending request-index order before a later wave starts; a failure or rejection stops later scheduling. The original detached request is forwarded only after all checks pass. It does not sign, broadcast, custody funds, infer inner UserOperation semantics, or make a safety claim. See examples/base_account_paymaster_guard.js for a no-network fixture.

🐍 4. Python Client

pip install m2m-sentinel

from m2m_sentinel import M2MSentinelClient

client = M2MSentinelClient()
audit = client.audit_contract("0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913")
print("Proxy detected:", audit["audit"]["proxyResolution"]["isProxy"])
print("Proxy target:", audit["audit"]["proxyResolution"].get("targetAddress"))
print("Capabilities:", audit["audit"]["verdict"]["executableCapabilities"])
print("Evidence:", audit["audit"]["dissection"]["capabilities"])

Transaction-specific preflight example

The public repository includes a standalone, mock-only transaction boundary example at examples/transaction_preflight.js. From this repository root, run:

node examples/transaction_preflight.js

It observes one caller-supplied Base transaction, passes the observation to a caller-owned policy, and reaches only a mock signing/send callback. It refuses to continue on unverified evidence, unresolved execution, an observation mismatch, or a missing Diamond selector mapping. It never signs or sends a transaction; optional live mode uses only a caller-supplied API-key header and remains the caller's responsibility.

💳 5. Autonomous x402 Micropayments (Headless M2M)

import { x402SignerClient } from "m2m-sentinel-sdk";

const client = new x402SignerClient({
  walletSigner: myAgentWallet,
  baseUrl: "https://api.m2msentinel.com"
});

const result = await client.request("/v1/audit/0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913");

📜 License

Available Tools

6 tools

m2m_audit_contractA

Read-onlyIdempotent

Inspect static bytecode capabilities (e.g. mint, pause, freeze, upgradeability slots), common proxy target resolution, and coverage index for a single Base contract address. Factual capability observation only, not a safety or exploitability guarantee. Distinguishable from m2m_get_service_status (infrastructure status) and legacy score-only endpoints.

ParametersJSON Schema

Name	Required	Description	Default
`address`	Yes	Base contract address (0x-prefixed 40-hex string, chainId 8453) to inspect.

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds the critical nuance that this is 'factual capability observation only, not a safety or exploitability guarantee,' which goes beyond annotation defaults and prevents misuse.

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?

Two sentences with zero fluff. The main action is front-loaded, followed by the safety disclaimer and then sibling differentiation. Every clause serves a distinct purpose.

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 single-parameter read-only tool with strong annotations, the description covers purpose, scope, limitations, and distinguishes from siblings. While there's no output schema, the enumerated capabilities imply the return content, making it sufficient for correct invocation.

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 address parameter is fully documented (format, chainId). The description adds no new semantic information about the parameter beyond restating 'single Base contract address.' Baseline 3 applies.

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 states a specific verb ('Inspect') and resource ('static bytecode capabilities... for a single Base contract address'), and enumerates example capabilities (mint, pause, freeze, upgradeability slots). It explicitly distinguishes from sibling tools, leaving no ambiguity about scope.

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 when to use the tool (to inspect a single Base contract's bytecode capabilities) and names alternatives (m2m_get_service_status and legacy score-only endpoints) with their focus, giving the agent routing context. It lacks an explicit 'when not to use' statement, but the distinction is clear.

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

m2m_get_dex_liquidityA

Read-onlyIdempotent

Fetch aggregate pool reserve, depth, and volume metrics across tracked Base DEX liquidity pools. Reports tracked-pool metrics only and does not filter by individual trading pair; contrast with m2m_get_token_price, which observes token spot prices.

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?

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive behavior, so the burden is lower. The description adds useful scope constraints: tracked-pool metrics only and no pair-level filtering, which clarifies what the result will and will not represent.

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?

Two focused sentences with no filler. The core scope is front-loaded, and the contrast with the sibling tool is placed efficiently at the end.

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 parameterless, read-only, idempotent tool, the description fully captures purpose and scope, and the output is reasonably inferable from the stated metrics. There are no missing inputs or hidden invocation requirements.

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 tool has zero parameters, so the schema provides no semantic burden. The description still supplies meaningful context about what is being fetched, which is more than enough for a parameterless call.

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 names a specific verb ('Fetch') and resource ('aggregate pool reserve, depth, and volume metrics across tracked Base DEX liquidity pools'). It also draws a clear boundary by stating it does not filter by individual trading pair and contrasts itself with m2m_get_token_price.

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 clearly frames this as the tool for tracked-pool aggregate DEX metrics and notes that pair-level filtering is not available. It names a sibling, m2m_get_token_price, as the spot-price alternative, though it does not explicitly say 'use X when you need spot prices'.

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

m2m_get_gas_metricsA

Read-onlyIdempotent

Fetch current Base gas price in wei/gwei with RPC provenance for the upstream observation. Read-only telemetry; does not inspect contract code, return token/DEX pricing, or authorize or submit transactions.

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?

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds valuable context beyond annotations: 'RPC provenance for the upstream observation' indicates the data source, and the explicit exclusions (no contract inspection, no token/DEX pricing, no transaction authorization) clarify boundaries. This enriches the behavioral model without contradicting annotations.

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 with no redundancy. The primary purpose is front-loaded in the first sentence, and the second sentence provides necessary exclusions. Every word adds value; there is no filler or repetition.

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 simple read-only telemetry tool with no parameters and no output schema, the description covers everything an agent needs: what it returns (gas price with units), where data comes from (RPC provenance), and what it explicitly does not do (inspect contracts, return pricing, handle transactions). No additional details like pagination or authentication are necessary for this scope.

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 tool has zero parameters, and schema coverage is 100% (empty schema). The description does not need to explain parameters. Per the baseline for 0-parameter tools, a 4 is appropriate. It adds no parameter-specific info because none exist, but it does clarify output units (wei/gwei), which is useful context for interpreting results.

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 a specific verb ('Fetch') and resource ('current Base gas price') with units (wei/gwei). It also explicitly distinguishes itself from sibling tools by listing exclusions: 'does not inspect contract code, return token/DEX pricing, or authorize or submit transactions.' This makes its purpose unambiguous and differentiates it from m2m_audit_contract, m2m_get_token_price, m2m_get_dex_liquidity, and m2m_get_whale_signals.

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 provides clear context for when to use the tool: whenever a current gas price is needed. It gives negative guidance by stating what it does not do (inspect contract code, return pricing, authorize transactions), which implies those tasks belong to other tools. However, it does not explicitly name sibling alternatives or state conditions for choosing this tool over them, so it falls just short of a 5.

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

m2m_get_service_statusA

Read-onlyIdempotent

Fetch operational status, upstream Base RPC quorum status, and persistence availability for M2M Sentinel infrastructure. Does not return blockchain or market telemetry.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, covering the safety profile. The description adds scope by specifying what exact statuses are returned and clarifying exclusions, but does not disclose additional behavioral traits like output format or failure modes. With annotations present, the description adds some context but not a rich behavioral picture.

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 with no filler. It front-loads the core purpose and then immediately provides an exclusion, making it highly scannable for an agent.

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 there are no parameters, no output schema, and rich annotations, the description provides enough context for an agent to decide whether to call it and what to expect. It enumerates the three status areas and clarifies exclusions. However, the lack of output schema means the exact response format is not described, which could be a minor gap, but the description compensates by listing the data categories.

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 is empty with zero parameters, so schema coverage is trivially 100%. Per the baseline for zero-parameter tools, the description earns a 4; there are no parameters to describe, and the description adds no misleading information.

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 fetches operational status, upstream Base RPC quorum status, and persistence availability for M2M Sentinel infrastructure. It also explicitly states what it does not return (blockchain or market telemetry), which distinguishes it from sibling tools like m2m_get_token_price and m2m_get_dex_liquidity.

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

Usage Guidelines3/5

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

The description provides implicit usage guidance: it is for infrastructure health checks, not for blockchain or market data. However, it does not explicitly name alternative tools or state 'use this when you need operational status,' so the context is implied rather than explicit.

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

m2m_get_token_priceA

Read-onlyIdempotent

Fetch the median Base DEX spot price in USD across up to five deepest indexed pools, with contract address, decimals, and pool provenance for one allowlisted token symbol (e.g. USDC, WETH, AERO). Does not return historical price series; contrast with m2m_get_dex_liquidity, which returns aggregate pool reserve depth rather than an asset price.

ParametersJSON Schema

Name	Required	Description	Default
`symbol`	Yes	Allowlisted token symbol on Base (e.g. USDC, WETH, AERO). Lookups are case-insensitive single symbols.

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already cover read-only, idempotent, and non-destructive traits. The description adds meaningful behavioral context: median across up to five deepest indexed pools, return contents including contract address, decimals, and pool provenance, and an explicit exclusion of historical series. Minor gaps around error handling for non-allowlisted symbols remain.

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?

Two well-structured sentences: the first front-loads the core operation and result contents, the second adds a key exclusion and sibling contrast. No unnecessary content.

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 one-parameter read-only tool with full schema coverage and strong annotations, the description covers purpose, return contents, and a key limitation. The absence of an output schema is mitigated by the explicit mention of the returned fields.

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 coverage is 100% and the schema description already documents allowlisted Base symbols and case-insensitive single-symbol lookups. The description repeats the symbol concept and examples but does not add new parameter semantics beyond what the schema provides.

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 names a specific verb ('Fetch') and resource ('median Base DEX spot price in USD across up to five deepest indexed pools'), and includes concrete token examples. It also distinguishes itself from m2m_get_dex_liquidity, making the tool's purpose immediately clear.

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?

It explicitly states a major limitation ('Does not return historical price series') and contrasts itself with the sibling m2m_get_dex_liquidity, telling an agent when not to use this tool and which sibling to consider instead.

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

m2m_get_whale_signalsA

Read-onlyIdempotent

Fetch up to 50 tracked recent high-value ERC-20 transfer signals on Base with transaction hashes, token/sender/receiver addresses, amounts, and valuation provenance. Observes large on-chain transfer events without query parameter limits; does not inspect contract bytecode or query DEX pricing.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive, so the safety profile is covered. The description adds valuable behavioral context beyond annotations: the 'up to 50' result cap, 'recent' and 'tracked' scoping, and explicit exclusions (does not inspect bytecode or query DEX pricing). It does not discuss pagination or rate limits, but given the annotation coverage, this is sufficient.

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 with no filler. The first sentence front-loads the core action, result limit, and key fields; the second adds behavioral limitations. Every phrase earns its place, and the structure is easy to scan.

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 no-parameter read-only tool with strong annotations, the description is nearly complete: it specifies the domain (Base, ERC-20), the result cap, the included data fields, and what it does not do. Minor gaps include unclear terms like 'tracked' and 'valuation provenance,' and no mention of formatting or error behavior, but these are not blocking for a correct call.

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 tool has 0 parameters and the schema coverage is vacuously 100%, so the baseline is 4. The description adds no parameter-specific semantics (there are none), but it does clarify that the tool operates 'without query parameter limits,' which is relevant to how an agent should think about invocation. Nothing is missing here.

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 states a specific verb ('Fetch'), a precise resource ('tracked recent high-value ERC-20 transfer signals on Base'), and enumerates the returned data fields (transaction hashes, addresses, amounts, valuation provenance). It clearly distinguishes this from sibling tools like m2m_get_token_price or m2m_audit_contract by focusing on transfer signals rather than pricing or bytecode inspection.

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 clear context for when this tool is appropriate (tracking large ERC-20 transfers on Base) and provides negative guidance ('does not inspect contract bytecode or query DEX pricing'), which implicitly routes agents away from sibling tools. However, it does not explicitly name specific alternative tools or state 'use this when...', leaving some inference to the agent.

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.

10 tool updatesv1.2.6Sep 15, 2026
- Removedaudit_contract
- Removedget_capability_score
- Removedget_dex_metrics
- Removedget_gas_fees
- Removedget_token_price
- Removedget_whale_signals
- Changedm2m_audit_contract1 field changed
  - changedInput schema / properties / address / description
```
Previous value: -"Base contract address (0x...)"New value: +"Base contract address (0x-prefixed 40-hex string, chainId 8453) to inspect."
```
- Changedm2m_get_dex_liquidity1 field changed
  - removedInput schema / properties / pair
```
Removed value: -{
-  "type": "string"
-}
```
- Changedm2m_get_token_price1 field changed
  - changedInput schema / properties / symbol / description
```
Previous value: -"Token symbol (USDC, WETH)"New value: +"Allowlisted token symbol on Base (e.g. USDC, WETH, AERO). Lookups are case-insensitive single symbols."
```
- Changedm2m_get_whale_signals1 field changed
  - removedInput schema / properties / limit
```
Removed value: -{
-  "type": "number"
-}
```
12 tool updatesv1.2.5Sep 7, 2026
- First observedaudit_contract
- First observedget_capability_score
- First observedget_dex_metrics
- First observedget_gas_fees
- First observedget_token_price
- First observedget_whale_signals
- First observedm2m_audit_contract
- First observedm2m_get_dex_liquidity
- First observedm2m_get_gas_metrics
- First observedm2m_get_service_status
- First observedm2m_get_token_price
- First observedm2m_get_whale_signals

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.4/5.0

Scored 2026-09-15 09:05 across 6 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: contract auditing, gas metrics, DEX liquidity, token price, whale signals, and service status. Descriptions explicitly contrast overlapping tools (e.g., token price vs. liquidity) to eliminate ambiguity.

Naming Consistency5/5

All tools follow a consistent m2m_ verb_noun pattern using snake_case (e.g., audit_contract, get_gas_metrics). The only variation is the verb (audit vs. get), but that is appropriate given the different action.

Tool Count5/5

6 tools is well-scoped for a blockchain monitoring server, covering contract auditing, gas, liquidity, price, whale signals, and service status. Each tool earns its place with no redundancy.

Completeness5/5

The tool surface fully covers the server's stated purpose of read-only blockchain telemetry and monitoring. It includes all essential data types (gas, price, liquidity, whale activity, contract audit, and status) with no obvious dead ends.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

Wolfpack Intelligence A
io.github.rok-labs
On-chain security and market intelligence for trading agents on Base.
Blockchain Finance Security
2
Base Intel MCP A
com.datakoot
Read-only on-chain intelligence for AI agents on Base: balances, tokens, gas, tx status.
Blockchain Web3 & Decentralized Tech
51
Base Intel MCP A
io.github.selflabbs
Read-only on-chain intelligence for AI agents on Base: balances, tokens, gas, tx status.
Blockchain Cryptocurrency Web3 & Decentralized Tech
2
VulnHunt Security Intelligence C
io.github.owenkingva-web
Read-only smart-contract security intelligence for autonomous agents.
Blockchain Penetration Testing Code Analysis
111

Related MCP Servers

MCPAGENT
Blockchain Cryptocurrency Agent Orchestration
lordbasilaiassistant-sudo
A
license
Not graded
quality
C
maintenance
Enables AI agents to discover and interact with onchain agent infrastructure on Base, including identity, micropayments, and tool capabilities via MCP.
Updated 13 days ago (2026-09-13 22:37 UTC)
4
MIT
agentradar
Blockchain Cryptocurrency Web3 & Decentralized Tech
Bichev
A
license
A
quality
F
maintenance
Trust scoring, scam detection, and EAS attestations for ERC-8004 + x402 agents on Base.
Updated 3 months ago (2026-06-17 01:08 UTC)
18
36 npm
1
MIT
Crest Counterparty
Blockchain Cryptocurrency Autonomous Agents
andysalvo
A
license
Not graded
quality
C
maintenance
Enables agents to assess counterparty risk, token danger, and wallet creditworthiness on Base by analyzing contract powers and controlling wallet reputation.
Updated 3 months ago (2026-06-23 22:20 UTC)
MIT
basescope
chasdaddy
A
license
A
quality
D
maintenance
basescope is a read-only onchain safety layer for AI agents: it answers "is this token/contract/approval safe?" on Base and EVM chains (honeypot/rug checks, risky-approval detection, verified-source lookup, balances, ENS/Basenames, gas, prices), with no private keys and no required API keys.
Updated 2 months ago (2026-07-19 13:05 UTC)
13
7 npm
MIT

M2M Sentinel SDK & MCP Server

⚡ 1. Model Context Protocol (MCP) Server

Option A: 1-Click via Smithery

Option B: Local Stdio (claude_desktop_config.json)

Option C: Remote Streamable HTTP

🤖 2. Coinbase AgentKit Integration

📦 3. JavaScript / TypeScript Client

🛡️ Base Account wallet_sendCalls Guard

🐍 4. Python Client

Transaction-specific preflight example

💳 5. Autonomous x402 Micropayments (Headless M2M)

📜 License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Option B: Local Stdio (`claude_desktop_config.json`)

🛡️ Base Account `wallet_sendCalls` Guard