Mindjack

token_web

Read-only

Find earlier launches tied to a token via shared wallets, listing wallets, outcomes, and peak market cap. Use when shared wallets exist to identify which launches are connected.

Instructions

[$0.04] Earlier launches tied to this token through shared wallets, with the wallets themselves, each launch's outcome and its highest recorded market cap. Use when token_identity reported shared wallets and you need WHICH launches. token_graph stays inside one token; this crosses tokens.

Example tool call

This call uses example arguments supplied in the tool’s input schema.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "mint": "6acH1iae44zL4haWNNCaqcTqS2Q7KNYsWErxCoLW9u9P",
      "min_shared": 5
    },
    "name": "token_web"
  }
}

Input Schema

Name	Required	Description	Default
`mint`	Yes	Solana token mint, base58.
`min_shared`	No	Minimum shared wallets. Default 3.

Output Schema

Name	Required	Description
`mint`	No
`says`	No	The finding in one plain sentence, safe to quote.
`_meta`	No
`tokens`	No	Launches sharing wallets with this one: mint, shared wallet count, outcome and the highest...
`common_wallets`	No	The shared wallets themselves, with which launches each ties.
`web_wallet_pool`	No	Wallets considered when building the web.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.4.4Aug 22, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds beyond that by disclosing the $0.04 cost, the tie-outcome details, and emphasizing this operation crosses token boundaries rather than staying within one token. No contradiction with annotations.

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?

Three short sentences front-load the cost and core output, then give the when-to-use rule and the contrast with a sibling. Every sentence contributes distinct information with no filler.

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?

For a 2-parameter read-only query tool with a full output schema and clear sibling positioning, this description is complete enough. It covers cost, triggering conditions, output semantics, and the tool’s cross-token scope. No critical gap remains.

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?

Input schema coverage is 100%, so both mint and min_shared are already documented in the schema. The description refers to 'shared wallets' and 'WHICH launches,' which aligns with min_shared, but adds no concrete syntax or behavioral detail beyond what the schema provides.

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 clearly identifies the resource (earlier launches tied to a token via shared wallets) and the output (wallets, outcomes, highest market cap). It explicitly differentiates from sibling tools by contrasting with token_graph, which stays within one token, and token_identity, which reports shared wallets.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit when-to-use guidance is provided: 'Use when token_identity reported shared wallets and you need WHICH launches.' It also gives a clear when-not/alternative statement by noting token_graph stays inside one token while this tool crosses tokens.

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