Loading ToolBench
Six tools over stdio for pricing vanity patterns, appraising addresses, grinding keypairs locally, delegating hard grinds without exposing keys, and verifying proof-of-grind certificates. Pure maths and WebAssembly grinder with no network required for most operations.
Six tools with complete schemas, strong descriptions (avg 180 chars), and proper parameter typing. Tool names follow verb_noun pattern (vanity_quote, vanity_grind). All parameters have descriptions and types. Schemas use Zod with proper constraints. Security-conscious design (split-key avoids key exposure). Main gaps: no output schema documentation, limited error recovery guidance, no pagination/limits for results, and missing parameter constraints (e.g., max cores, rate limits). Tool annotations present (readOnlyHint, idempotentHint). Descriptions are domain-specific and actionable but could be more concise for LLM parsing.
Score how much grinding work an existing Solana address represents: which leading and trailing characters look deliberate, the expected attempts behind them, the rarity tier, and any pattern bonuses (dictionary word, palindrome, repeat run). Pure maths, no network.
The Base58 leading-character table showing exact probabilities over the whole 2^256 key space and how each character compares to the naive uniform model.
Grind a Solana keypair whose address matches a pattern, using every core of the machine running this MCP server. Returns the address and the 64-byte secret key. The key is generated here and never leaves this machine, but it DOES cross the MCP transport into the calling assistant, so treat the result as sensitive and prefer vanity_split_key_grind for anything valuable.
Exact difficulty for a Solana vanity pattern: probability, expected attempts, rarity tier and an ETA at a given rate. Uses an exact count over the whole 2^256 key space rather than the 58^n approximation, which is wrong by up to 17x on the leading character. Pure maths, no network, no payment.
Delegate a hard vanity pattern to a remote grinder using split-key arithmetic. A secret scalar a1 is generated here and never sent; the remote service searches offsets a2 against the public point P1 = a1*B and returns a2, which is useless without a1. The final key is combined and verified locally. The result is an expanded Ed25519 key (a raw scalar, not a seed): it signs correctly but seed-only wallet imports will reject it.
No documented output schemas. Tool descriptions explain what is returned (e.g., 'returns address and secret key'), but the response structure is not formally specified. LLMs cannot plan downstream tool calls or extract fields reliably without knowing the exact response shape.
vanity_grind and vanity_split_key_grind lack explicit error recovery guidance. Descriptions mention 'give up after this long' and 'maxRounds' but do not explain what happens on timeout, what the LLM should do next, or whether the operation is retryable. No actionable error messages defined.
Parameter constraints are incomplete. vanity_grind accepts 'cores' (integer) and 'timeBudgetMs' (integer) but no min/max bounds are documented. An LLM could pass cores=1000 or timeBudgetMs=999999999, causing resource exhaustion. Code caps timeBudgetMs at 120000ms but this is not reflected in the schema description.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 62 | 2026-07-28+ | v2 |
Verify a proof-of-grind certificate: signature, key ring membership, certificate id, pattern match, difficulty claim, rarity claim, freshness, and for split-key grinds the non-custody equation P1 + a2*B == address.
vanity_verify_certificate accepts a 'certificate' parameter of type 'object' with no schema or structure documentation. The description does not specify what fields the certificate must contain, what format it uses, or what validation is performed. This forces LLMs to guess the structure.
No pagination or result limits documented. vanity_difficulty_table returns 'the Base58 leading-character table' but does not specify how many rows, whether results are paginated, or if there is a size cap. Large result sets could exhaust context windows.