Validated-edge score: reports ONLY signals that passed our locked-holdout validation (strong-start mcap >=3x -> graduation 0.8%->33%, low reserve -> OR 0.35, fast-graduation rug risk). Descriptive base-rate shift, not a price prediction.
| Name | Required | Description | Default |
|---|---|---|---|
| mint | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full behavioral burden. It discloses that only validated signals are reported, that the result is descriptive rather than predictive, and it gives specifics about the validation criteria. It does not mention error behavior or data freshness, but for a lookup-style scoring tool it provides meaningful behavioral context.
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 only two sentences and front-loads the core behavior before the caveat. The parenthetical metric list is dense but compact, and there is no filler or redundant restatement of the tool name.
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?
With one required parameter and no output schema, the description gives a reasonable functional gist but leaves the output structure and exact interpretation (e.g., score scale, signal fields, return format) undocumented. It is enough to select the tool, but not fully self-contained for reliable invocation.
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?
The only parameter, 'mint', is a plain string with 0% schema description coverage, and the description never explains its expected format (e.g., token address, chain, or case sensitivity). The name is suggestive, but the description adds no parameter-level meaning beyond the schema's property name.
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 that the tool 'reports ONLY signals that passed our locked-holdout validation' and explicitly says it is 'not a price prediction,' which gives a specific verb, resource, and scope. It does not explicitly contrast with sibling tools like check_mint or track_record, so differentiation relies on the reader inferring the distinction.
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 implies when to use the tool: when validated, non-predictive base-rate signals are desired. The 'not a price prediction' phrase is a useful exclusion, but the description never names alternatives or gives explicit when-to-use versus when-not-to-use guidance relative to the sibling tools.
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.
Most tools target distinct actions (build a swap, check a mint, verify a claim, fetch pricing), and the descriptions make boundaries clear. The main risk is mild confusion between check_mint/score_mint and copy_signals/recent_events, as both pairs sit in adjacent signal/safety territory, but they are not interchangeable.
Most names follow a verb_noun pattern (build_swap, check_mint, score_mint, verify_claim, track_record). guard_pricing and recent_events break that pattern slightly, but the naming remains predictable and readable overall.
Nine tools is well within the ideal range and each tool earns a place in the safety/signal/trading workflow. It is neither bloated with near-duplicates nor too thin to define a useful server.
The server covers a coherent lifecycle: discovery (recent_events/copy_signals), safety and validation (check_mint/score_mint/verify_claim), execution (build_swap), and outcome auditing (track_record). Minor gaps exist, such as an EVM swap builder to complete the Robinhood check path, but the core workflow is usable.