SiteCheck Crypto & Finance

Recent event logs of a contract on Base from public RPC

crypto_basescan_contract_events

Read-only

Recent event logs of a contract on Base (chain 8453) from public RPC: block, time order, transaction hash, log index, event name (signature database), topics and data, with ERC-20/721 Transfer and Approval decoded to from/to/value. Look back up to 5,000 blocks (~2.8 h); optional event-signature filter. Internal transactions are not included. Takes about 14 s; allow a 30 s timeout. Related tools on this server, for a different need: crypto_subtensor_events when you need Recent Subtensor chain events, optionally filtered; crypto_smart_contract_verify when you need EVM contract verification status from Sourcify: match type. Price: $0.002 in USDC per successful call, paid with x402 (Base, Solana or Arc); failed calls are not charged.

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": "crypto_basescan_contract_events"
  }
}

Input Schema

Name	Required	Description
`limit`	No	Max logs returned, newest first, 1-200 (default 50)
`blocks`	No	How many recent blocks to scan, 1-5000 (default 500; Base makes a block every 2 s)
`topic0`	No	Optional event signature hash (0x + 64 hex) to keep only that event, e.g. the Transfer topic
`address`	Yes	Contract address 0x… (e.g. USDC on Base 0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913)

Output Schema

Name	Required	Description	Default
`logs`	No
`chain`	No
`count`	No
`source`	No
`address`	No
`chainId`	No
`toBlock`	No
`checkedAt`	No
`fromBlock`	No
`narrowedRange`	No
`totalLogsInRange`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 23, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Annotations only declare readOnlyHint and openWorldHint; the description adds the operational facts an agent actually needs: ~14 s runtime with a 30 s timeout allowance, a $0.002 USDC charge via x402 only on success (failed calls free, payable on Base/Solana/Arc), the 5,000-block scan ceiling, and the internal-transaction exclusion. That is substantial disclosure beyond what the annotations cover and does not contradict readOnlyHint.

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?

Purpose and scope are front-loaded, followed by limits, exclusions, latency, and cost in a compact single paragraph with no redundant sentences. It runs long and the 'Related tools on this server' enumeration plus pricing tail read as template scaffolding, which keeps it off a 5.

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?

An output schema exists, so return-shape explanation is unnecessary, and the description still covers everything else an agent needs before calling: time window, latency budget, cost and payment mechanics, ordering, and what is excluded. Nothing material is missing for a four-parameter read 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?

Schema description coverage is 100%, so all four parameters are already documented with ranges and defaults, making 3 the baseline. The description restates the block window and the signature filter and clarifies that Transfer/Approval get decoded into from/to/value, but adds no syntax, format, or edge-case meaning the schema does not already carry.

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 a specific verb and resource ('Recent event logs of a contract on Base (chain 8453) from public RPC') and then enumerates exactly what each log contains: block, time order, tx hash, log index, event name, topics/data, plus decoded ERC-20/721 Transfer and Approval fields. The chain ID and the decoding behavior make it unambiguously distinct from generic event-log or verification siblings.

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 concrete usage boundaries: look back up to 5,000 blocks (~2.8 h) and an optional event-signature filter, and explicitly excludes internal transactions. It also names two sibling tools with the condition that selects them, though crypto_subtensor_events and crypto_smart_contract_verify are only loosely adjacent needs rather than true substitutes, so the routing is more boilerplate than a real fork in the road.

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

All SiteCheck Crypto & Finance tools Inspect

Try in Browser

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

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?