nosis-bunker

Official

Overview Schema Source Related Servers Discussions Admin

Scan crypto addresses for public key exposure

scan_addresses

Read-onlyIdempotent

Classify public crypto addresses across 100+ networks, validate checksums, and report whether each exposes its public key with an ordered action plan. Runs offline and rejects secrets.

Instructions

Classify public crypto addresses (more than 100 networks, with checksum validation) and report whether each one exposes its public key. Returns a summary, one result for each address, and an ordered plan. Runs offline. Input: public addresses only, one per line, an optional label after a space. Never pass seed phrases or private keys: they are rejected.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "scan_addresses"
  }
}

Input Schema

Name	Required	Description	Default
`lang`	No	Language of the explanations and the plan.	en
`text`	No	Alternative to addresses: one address on each line.
`answers`	No	Has the address ever sent a transaction or signed a message? Map of address to yes, no or unsure.
`addresses`	No	Public addresses. An optional label can follow after a space. Bare 64 hex is treated as a possible private key: write 0x in front for Sui, Aptos or IOTA, and near: in front for a NEAR implicit account.

Output Schema

Name	Required	Description	Default
`ok`	Yes
`plan`	No
`error`	No
`results`	No
`summary`	No
`planText`	No
`disclaimer`	No
`attribution`	No
`schemaVersion`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.2.2Nov 12, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Beyond the annotations, the description discloses that the tool runs offline, performs checksum validation, returns a summary plus one result per address, and produces an ordered plan. It also discloses a safety behavior: seed phrases and private keys are rejected. Since the annotations already cover read-only, idempotent, non-destructive, and closed-world behavior, this adds useful operational context.

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 dense and front-loaded: purpose, return structure, offline behavior, input format, and safety exclusion all appear in a few sentences. There is little or no filler, and the critical input constraint is stated plainly at the end.

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?

The tool has four parameters, a nested answers object, rich annotations, and an output schema, so much of the structured context is already supplied. The description covers purpose, output shape, offline execution, and sensitive-input rejection, which is enough for correct invocation. It does not discuss the answers parameter or contrast with list_networks, leaving minor contextual gaps.

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 input schema already documents the four parameters, including address formatting and the answers map. The description reinforces the address input format and adds a rejection rule for sensitive inputs, but it does not explain lang or answers beyond what the schema provides. With full schema coverage, the baseline of 3 is appropriate.

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 and resource: classify public crypto addresses and report whether each exposes its public key. It adds concrete scope with more than 100 networks and checksum validation, so an agent can distinguish this as an exposure-scanning tool rather than a generic network listing tool.

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 input context: public addresses only, one per line, with an optional label after a space. It also explicitly excludes seed phrases and private keys, stating that they are rejected. It does not name or contrast with sibling tools such as list_networks, so the when-to-use guidance is clear but not alternative-routing.

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

Deploy Server