@true402.dev/mcp-server

address_safety_bsc

Structural safety profile for ANY BNB Smart Chain (BSC) address — an EOA or an arbitrary contract — before an agent sends funds to it, approves it, or calls it.

Instructions

Structural safety profile for ANY BNB Smart Chain (BSC) address — an EOA or an arbitrary contract — before an agent sends funds to it, approves it, or calls it. Returns contract-vs-EOA, ETH + USDC balance, tx-count (activity), and for contracts: whether it is a recognised ERC-20, ownership state, a mint() selector, and whether it is an EIP-1967 upgradeable proxy (its logic can be swapped after you trust it). Coarse risk band + flags. On-chain reads only — no API key. POST { address }. Unpaid: free while the caller's IP has free-trial calls left that day (a small daily allowance shared across the trial stalls, no wallet); otherwise returns 402. (PAID x402 service — USDC on Base; the MCP server needs a funded wallet to settle.) Price: $0.005 USD (fixed).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "address": "<address>"
    },
    "name": "address_safety_bsc"
  }
}

Input Schema

Name	Required	Description	Default
`chain`	No	Chain to check; only 'bsc' is supported on this endpoint (default)
`address`	Yes	Any address (0x…) on BNB Smart Chain (BSC) — an EOA or a contract

Schema Changelog

Changes observed during successful MCP inspections.

Addedv1.3.0Oct 22, 2026

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 carries the full burden and does so: on-chain reads only, no API key, no side effects, daily free-trial allowance, the 402 fallback, the x402 USDC settlement requirement, and a fixed price. It also flags the EIP-1967 proxy caveat ('its logic can be swapped after you trust it'), which is exactly the kind of risk an agent cannot infer elsewhere.

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?

Front-loaded with purpose and trigger, then returns, then payment terms. Dense but nearly every clause earns its place; the payment/pricing sentences are the longest but are genuinely decision-relevant for an agent that may hit a 402.

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?

No output schema exists, and the description compensates by enumerating the returned signals (contract-vs-EOA, balances, tx-count, ERC-20 recognition, ownership, mint() selector, proxy status, risk band and flags). Combined with the disclosed payment model, an agent has everything needed to decide and call correctly.

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. The description still adds value by stating the wire format (POST `{ address }`) and reiterating that the address may be an EOA or an arbitrary contract, which is the semantic distinction that governs how the result should be interpreted. The `chain` parameter is not addressed, but the endpoint is single-chain by design.

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?

Names a specific verb+resource+scope: a structural safety profile for ANY BSC address (EOA or contract). The chain qualifier in the name and the opening line separate it cleanly from address_safety, address_safety_ethereum, and address_risk without opening a schema.

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?

Gives an explicit trigger: 'before an agent sends funds to it, approves it, or calls it.' That is a concrete use condition rather than an implied one. It stops short of naming an alternative or stating when-not to use it (e.g. when token_safety_bsc is the better fit for a token rather than an address).

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