robinx_verdictComposite BUY-RISK verdict for a Robinhood Chain memecoin: deployer reputation + insider-distribution flags + on-chain activity → signal (trusted/mixed/avoid/serial_spammer/new_deployer) with reasons. Works on a token that launched seconds ago (scores WHO deployed it). (paid $0.02 — see instructions)
| Name | Required | Description | Default |
|---|---|---|---|
| token | Yes | Token contract address 0x… |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds behavioral traits: it combines multiple data sources, mentions a cost of $0.02, and emphasizes it works on very new tokens. This provides useful context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the core purpose, lists input factors, specifies output format, and includes a key usage characteristic and cost note. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately explains inputs (deployer reputation, insider flags, on-chain activity) and outputs (signal with reasons and possible values). It also mentions the cost and applicability to new tokens. Lacks mention of prerequisites or additional constraints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already describes the single 'token' parameter as a contract address. The description adds no further parameter details, meeting the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: providing a composite BUY-RISK verdict for a Robinhood Chain memecoin by combining deployer reputation, insider-distribution flags, and on-chain activity to output a signal (trusted/mixed/avoid/serial_spammer/new_deployer) with reasons. This distinguishes it from sibling tools that provide individual components (e.g., robinx_deployer, robinx_token).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies that the tool works on tokens that just launched ('seconds ago'), indicating its suitability for new tokens. It also implies a composite verdict versus individual data points, but does not explicitly list when to use this versus alternatives or state exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool targets a distinct aspect of Robinhood Chain token analysis: deployer reputation, on-chain stats, social sentiment, wallet history, etc. Even overlapping concepts like verdict and report are clearly differentiated by scope and detail.
All tools follow a consistent 'robinx_<single_word_noun>' pattern, making it easy for an LLM to predict tool names and understand their purposes at a glance.
12 tools is optimal for a domain-specific server covering deployer analysis, token stats, social signals, wallet reputation, and composite reports. The count feels neither sparse nor bloated.
The tool set covers the core token analysis workflow: search, deployer check, on-chain stats, holder structure, social pulse, and comprehensive reports. Minor gaps like batch operations or historical comparisons exist but do not severely hinder usability.