basescope

Name: basescope
Author: chasdaddy

by chasdaddy

Overview Schema Related Servers Score Discussions

TypeScript

basescope

The read-only safety layer for onchain AI agents.

basescope is a Model Context Protocol (MCP) server that gives AI assistants — Claude, Cursor, and any MCP client — safe, read-only onchain abilities on Base and other EVM chains. Its job is to answer one question before any wallet ever signs anything:

"Is this token / contract / approval actually safe?"

It checks for honeypots, rug-pull authority, hidden taxes, malicious addresses, and risky approvals — and looks up balances, ENS names, Basenames (*.base.eth), verified source, gas, and prices along the way.

Why it's different

🔒 Read-only by design. There is no code path that can sign or send a transaction, and no private key can ever be configured. It cannot move your funds because it literally has no way to. It's the inspector, not the wallet — a safe companion to transaction-capable agents.
🔑 No API keys required. Works out of the box on free, public data sources. (Optional keys can raise rate limits later, but nothing is required.)
🔵 Base-first, multichain-ready. Tuned for Base, and also supports Ethereum, Optimism, Arbitrum, and Polygon.
🧩 One question, cross-checked. Token safety is cross-referenced across two independent sources (GoPlus + honeypot.is) with provenance, so an agent can see when they disagree.

Quickstart

Add basescope to any MCP client — Claude Desktop (claude_desktop_config.json), Cursor (.cursor/mcp.json), or any other. No install step; npx fetches it on first run:

{
  "mcpServers": {
    "basescope": { "command": "npx", "args": ["-y", "basescope"] }
  }
}

Restart your client and ask something like "Use basescope to check if token 0x… on Base is safe."

git clone https://github.com/chasdaddy/basescope.git
cd basescope
npm install
npm run build

Then set the server command to node with args ["/absolute/path/to/basescope/dist/index.js"].

Related MCP server: Crest Counterparty Intelligence

Tools

All tools are read-only. chain accepts base (default), ethereum, optimism, arbitrum, or polygon. Address fields accept a 0x address, an ENS name, or a Basename (*.base.eth) — Basenames resolve automatically via the Base L2 Resolver.

Tool	What it does
check_token_safety	Honeypot / rug assessment: honeypot check, buy/sell tax, mint/blacklist/pausable/self-destruct authority, verified source, holder count → a normalized `riskLevel` (`critical`/`high`/`medium`/`low`). Cross-checks GoPlus + honeypot.is.
check_address_safety	Reputation check against known-malicious databases (phishing, sanctioned, scam, money-laundering, mixer, …).
get_token_approvals	Lists a wallet's outstanding ERC-20 approvals and flags risky spenders — the #1 wallet-drain vector — surfacing risky ones first.
get_verified_source	Whether a contract's source is verified (via Sourcify) + its name, compiler, and function list.
inspect_contract	Is the address a contract? Bytecode size + transaction count.
get_token_info	ERC-20 name / symbol / decimals, and optionally a holder's balance.
get_native_balance	Native coin (ETH / POL / …) balance of an address or ENS name.
resolve_ens_name / reverse_ens_lookup	ENS name → address, and address → primary ENS name (also reports the primary Basename on Base).
resolve_basename	Basename (`*.base.eth`) → address, via the Base L2 Resolver — Coinbase's ENS-compatible names on Base mainnet.
get_gas	Current gas price + EIP-1559 fee suggestion.
get_token_price	Current USD price for a token (via DefiLlama).
list_supported_chains	The chains this server can read.

Example — "is this token safe?"

// check_token_safety({ chain: "base", token: "0x…" })
{
  "riskLevel": "critical",
  "isHoneypot": true,
  "buyTaxPct": 0,
  "sellTaxPct": 99,
  "flags": [
    "cannot sell entire balance",
    "owner can mint more supply",
    "high sell tax (99%)"
  ],
  "sources": ["goplus", "honeypot.is"]
}

Configuration (all optional)

Everything works with no configuration. To use your own RPC endpoints (recommended for heavier use — public RPCs are rate-limited), set any of:

BASE_RPC_URL, ETHEREUM_RPC_URL, OPTIMISM_RPC_URL, ARBITRUM_RPC_URL, POLYGON_RPC_URL

Data sources

Standing on the shoulders of excellent free/open services: onchain reads via viem + public RPCs, token & address safety via GoPlus Security and honeypot.is, verified source via Sourcify, and prices via DefiLlama.

Limitations

basescope reports heuristics and signals, not guarantees, and is not financial advice. Safety APIs can be wrong or out of date; a "low risk" result is not a promise of safety. Always do your own research before transacting. On Base (an OP-Stack L2), get_gas reports L2 fees only — total cost also includes an L1 data fee.

Roadmap

Transaction / calldata simulation and decoding ("what will this actually do?")
Optional Etherscan V2 fallback for source & ABI/proxy resolution
More chains

License

Available Tools

6 tools

check_address_safetyCheck address reputationA

Check an address against known-malicious databases (phishing, sanctioned, scam, money laundering, etc.) via GoPlus. Read-only, no keys.

ParametersJSON Schema

Name	Required	Description	Default
`chain`	No		base
`address`	Yes	0x address or ENS name

TDQS

A3.6/5.0

Behavior3/5

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

With no annotations provided, the description carries full burden. It discloses that the tool is read-only and needs no authentication, but does not mention rate limits, side effects, or the exact nature of the search (e.g., whether it checks a local database or an API). It adds some value but is not exhaustive.

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 front-loads the core purpose, then adds the read-only and no-keys qualifier. Every word adds value with no waste.

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

Completeness3/5

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

The description is adequate for a simple check but lacks details about the output format (e.g., boolean, risk level) since no output schema exists. It also does not clarify how it differs from check_token_safety. It is minimally complete but has gaps.

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

Parameters2/5

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

Schema coverage is 50% (only address has a description). The tool description does not add meaning to the parameters beyond the schema: it mentions 'chain' implicitly via supported chains in the enum but provides no explanation of its role. The description should compensate for the 50% coverage but does not.

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 verb 'check' and the resource 'an address against known-malicious databases' with specific categories (phishing, sanctioned, etc.). It distinguishes from siblings like check_token_safety by focusing on addresses in general.

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 notes that it is read-only and requires no keys, implying safe usage without authentication. However, it does not explicitly state when to use this tool over alternatives like check_token_safety or when not to use it.

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

check_token_safetyCheck token safetyA

Assess whether an ERC-20 token is a honeypot / rug risk: honeypot check, buy/sell tax, mint/blacklist/pausable authority, verified source, and a normalized risk level. Cross-checks GoPlus + honeypot.is. Read-only, no keys. Best on Base and Ethereum.

ParametersJSON Schema

Name	Required	Description	Default
`chain`	No		base
`token`	Yes	ERC-20 token contract address

TDQS

A3.9/5.0

Behavior4/5

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

No annotations provided, so description carries full burden. It states 'Read-only, no keys' and cross-checks GoPlus + honeypot.is, but could add details on rate limits or error handling.

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, front-loaded with main purpose, no wasted words. Efficient and clear.

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 tool with 2 params and no output schema, description covers purpose, behavior, and supported chains. Could mention output format or errors, but adequate for most agents.

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

Parameters2/5

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

Schema covers 50% of parameters (token description). Description does not explain input parameters further; it focuses on output aspects. Chain enum is self-explanatory, but no additional context for token format.

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 assesses ERC-20 token honeypot/rug risk, listing specific checks. It distinguishes from siblings like get_token_price and check_address_safety.

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 mentions 'Best on Base and Ethereum' but lacks explicit guidance on when to use vs alternatives or when not to use. No exclusions or prerequisites.

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

get_gasGet gas priceA

Current gas price + EIP-1559 fee suggestion for a chain. Note: on Base (an OP-Stack L2) total tx cost also includes an L1 data fee. Read-only.

ParametersJSON Schema

Name	Required	Description	Default
`chain`	No		base

TDQS

A3.8/5.0

Behavior4/5

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

Explicitly labels as read-only and mentions the additional L1 data fee for Base, disclosing key behavioral traits. No annotations present, so description carries the full burden.

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 no fluff, front-loaded with the core purpose, and efficiently adds a caveat without extra verbosity.

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

Completeness3/5

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

With no output schema and only one parameter, the description could elaborate on return format (e.g., units) or error handling. The L1 fee note is helpful but the overall explanation feels minimal.

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?

Despite 0% schema description coverage, the description provides no information about the 'chain' parameter, its enum values, or default. Schema alone does not explain the purpose of each chain option.

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?

States the action (get) and resource (gas price) clearly, with elaboration on EIP-1559 fee suggestion. Differentiates from sibling tools about tokens and balances.

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?

Provides a specific use-case note about Base L1 fee, but does not explicitly contrast with other tools or state when to avoid using this tool.

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

get_native_balanceGet native balanceB

Read the native coin balance (ETH, MATIC, …) of an address or ENS name. Read-only.

ParametersJSON Schema

Name	Required	Description	Default
`chain`	No		base
`address`	Yes	0x address or ENS name

TDQS

B3.3/5.0

Behavior2/5

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

The description only mentions 'Read-only' as a behavioral trait. With no annotations, the description fails to disclose authorization needs, rate limits, or response format.

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, clear sentence with no extraneous information.

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

Completeness3/5

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

For a simple tool, the description is adequate but lacks details on response format and any context about when to use this over sibling tools.

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 50% (chain parameter lacks description). The description adds value by clarifying that address can be an ENS name, but does not elaborate on the chain parameter.

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 reads the native coin balance of an address or ENS name. It distinguishes itself from sibling tools like get_token_price and resolve_basename.

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?

No guidance on when to use this tool versus alternatives, nor any prerequisites or context are provided.

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

get_token_priceGet token priceA

Current USD price for a token, via DefiLlama. Read-only, no keys.

ParametersJSON Schema

Name	Required	Description	Default
`chain`	No		base
`token`	Yes	token contract address

TDQS

A3.5/5.0

Behavior3/5

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

The description discloses that the tool is read-only and requires no authentication, which is helpful given the absence of annotations, but lacks details on rate limits, data freshness, or other behaviors.

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 concise, using two short fragments and a sentence. No extraneous information, but could be slightly more structured.

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

Completeness2/5

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

With no output schema and sparse descriptions, the agent lacks information about the return format (e.g., price in USD as a number) and chain default behavior, making it incomplete for a simple tool.

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?

The schema covers the token parameter's purpose (contract address) but not chain; the description adds no new semantic meaning beyond 'via DefiLlama'. With 50% schema coverage, the description does not fully compensate.

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 retrieves the current USD price for a token via DefiLlama, distinguishing it from sibling tools like get_native_balance (which returns native coin balance) and others.

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 implies this tool is for token prices and is read-only with no keys needed, but does not explicitly state when to use it versus alternatives or provide exclusions.

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

resolve_basenameResolve BasenameA

Resolve a Basename (e.g. jesse.base.eth) to its address via the Base L2 Resolver. Basenames are Coinbase's ENS-compatible names on Base mainnet and are not resolvable by L1 ENS. Read-only.

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes	Basename, e.g. name.base.eth

TDQS

A4.2/5.0

Behavior3/5

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

No annotations are provided, so the description carries the full burden. It discloses 'Read-only' and the resolver used, but does not describe error behavior or return format.

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, no wasted words. Essential information is front-loaded.

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 resolver with one parameter and no output schema, the description covers purpose and usage. Missing explicit mention of return type, but implied.

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 description coverage is 100%, and the description adds value by providing an example and explaining what a Basename is, beyond the schema's brief description.

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 verb 'Resolve' and resource 'Basename' to an address via Base L2 Resolver. It distinguishes from L1 ENS and siblings are unrelated.

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 context that Basenames are ENS-compatible on Base and not resolvable by L1 ENS, implying when to use this tool. No explicit exclusions or alternatives mentioned.

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

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.9/5.0

Disambiguation5/5

Each tool targets a distinct functionality: token price, native balance, name resolution, token safety, address safety, and gas fees. No overlap or ambiguity.

Naming Consistency5/5

All tools use snake_case with consistent verb_noun pattern: get_, check_, resolve_. Verbs are descriptive and uniform.

Tool Count5/5

Six tools is a well-scoped set for a read-only blockchain utility server. Not too few to be trivial nor too many to overwhelm.

Completeness4/5

Core features are covered: price, balance, name resolution, safety checks, gas. Missing a token balance tool for ERC-20 tokens, which is a minor gap but the set feels sufficient for most basic queries.

Maintenance

ActivitySlowing

ResponsivenessSyncing

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

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
base-intel-mcp A
com.datakoot
Read-only on-chain intel for AI agents on Base: balances, tokens, gas, tx status. No API keys.
Blockchain Cryptocurrency Web3 & Decentralized Tech
52
Wolfpack Intelligence A
io.github.rok-labs
On-chain security and market intelligence for trading agents on Base.
Blockchain Finance Security
2
agentforge A
io.github.acarchidi
DeFi safety layer for AI agents: wallet safety, token risk, tx decode/simulate. 20 tools.
Blockchain Web3 & Decentralized Tech Autonomous Agents
2

Related MCP Servers

BlueAgent x402 Services
Blockchain Security Autonomous Agents
madebyshun
F
license
Not graded
quality
D
maintenance
Pay-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.
Updated 3 months ago (2026-06-07 17:46 UTC)
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 2 months ago (2026-06-23 22:20 UTC)
MIT
SENTINEL
teodorofodocrispin-cmyk
F
license
A
quality
C
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 a month ago (2026-08-05 00:38 UTC)
1
Base Intel MCP
Blockchain Cryptocurrency
datakoot
A
license
Not graded
quality
B
maintenance
Read-only on-chain intelligence for AI agents on Base, providing tools to read balances, token metadata, gas, and transaction status live from chain without API keys.
Updated a month ago (2026-08-02 23:31 UTC)
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/chasdaddy/basescope'

If you have feedback or need assistance with the MCP directory API, please join our Discord server