SiteCheck Agent Intel & Dev

Contracts created by a deployer wallet on Ethereum

agent_intel_deployer_rug_forensics

Read-only

Contracts created by a deployer wallet on Ethereum, from its most recent 50 transactions (Blockscout public API): creation hash, time and new contract address. Only that recent page is read, so older launches are missing. No rug-pull or abandoned-pool judgement: liquidity history is not included. Price: $0.003 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": "agent_intel_deployer_rug_forensics"
  }
}

Input Schema

Name	Required	Description	Default
`address`	Yes	Deployer wallet address 0x... (40 hex characters)

Output Schema

Name	Required	Description	Default
`note`	No
`chain`	No
`source`	No
`address`	No
`checkedAt`	No
`olderPagesExist`	No
`contractCreations`	No
`scannedTransactions`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 23, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Beyond the readOnlyHint and openWorldHint annotations, it discloses the pricing model ($0.003 USDC per successful call via x402 on Base/Solana/Arc), that failed calls are not charged, the upstream dependency (Blockscout public API) and the pagination ceiling (only the recent page is read). These are exactly the operational traits an agent needs before paying for a call.

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?

Four sentences, each carrying distinct information: scope, limitation, non-coverage, and price. The scope and the 50-transaction cap are front-loaded where an agent will read them first, with no redundant restatement of the title.

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-value detail is not required, yet the description still names the returned fields (creation hash, time, new contract address). Combined with the coverage limitation and cost terms, 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.

Parameters3/5

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

Schema coverage is 100% for the single required address parameter, so the baseline is 3. The description adds only mild context by implying the address must be an Ethereum deployer wallet, but gives no format, checksum, or chain-disambiguation guidance beyond the schema's '0x... (40 hex characters)'.

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 (contracts created), a specific resource (deployer wallet creation history on Ethereum), and a specific data source (Blockscout public API) with concrete returned fields. It also explicitly bounds the operation to the most recent 50 transactions, which separates it from broader sibling tools like agent_intel_wallet_forensic_profiler or agent_intel_liquidity_lock_inspector.

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?

It clearly states when the tool is insufficient: older launches are missing and no rug-pull or abandoned-pool judgement is offered, which steers an agent away from using it for liquidity-risk questions. It does not, however, name a sibling alternative to use instead for those cases, so routing requires inference.

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

All SiteCheck Agent Intel & Dev tools Inspect

Try in Browser

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?