Trap check for a fresh Solana mint (pump.fun focus): rug-check verdict, dev first-buy SOL, reserves, liveness. Safety screen, not a profit claim; verify via track_record. Free 10/day, then $0.01/check (see guard_pricing).
| Name | Required | Description | Default |
|---|---|---|---|
| mint | Yes | Solana mint address (base58) |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does so well by disclosing the check outputs, the safety-screen caveat, and the 10/day free tier followed by paid checks. It makes clear that this is a safety screen, not an investment guarantee, which is useful behavioral context beyond the schema. The only minor gap is that it does not specify the exact response shape or define 'fresh' precisely.
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?
Two dense sentences front-load the core function and output categories, then add the safety caveat and pricing note. Every clause earns its place, and there is no redundant restatement of the schema.
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?
For a single-parameter tool with no output schema and no annotations, the description provides sufficient context for correct invocation: what it checks, what categories it returns, and how to interpret it. It also points to relevant sibling tools for track-record verification and pricing, making the surrounding workflow clear.
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 input schema already documents the single 'mint' parameter as a base58 Solana mint address with 100% schema description coverage. The tool description adds extra selection-relevant meaning by narrowing the intended input to a fresh mint with a pump.fun focus, helping the agent understand what kind of address to pass. This exceeds the baseline for fully documented params.
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 states a specific verb-plus-resource action: 'Trap check for a fresh Solana mint' with a pump.fun focus, and enumerates concrete outputs such as rug-check verdict, dev first-buy SOL, reserves, and liveness. It also disambiguates itself as a safety screen rather than a profit claim, which clearly separates it from score_mint and related tools.
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?
It explicitly frames when to use the tool: as a safety screen for a fresh mint, and when not to rely on it, since it is 'not a profit claim' and directs verification via track_record. It also points to guard_pricing for the free quota and paid checks, giving the agent actionable routing guidance.
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 clearly distinct actions (build, check, score, verify, track), and the detailed descriptions separate chains and purposes. The main ambiguity is between check_robinhood and check_robinhood_honeypot, which both assess Robinhood Chain tokens but via different methods.
Most names follow a verb_noun pattern with a consistent 'check_' family for safety tools. Minor deviations like recent_events, guard_pricing, and track_record break the pattern but are still readable.
Ten tools is well within the ideal range and covers safety checks, signal intelligence, execution, pricing, and verification without feeling padded. Each tool has a distinct role in the guarded-trading workflow.
The surface covers the core non-custodial trading/intelligence loop: assess, score, copy, build, pay, and verify claims. Minor gaps exist around historical signal filtering or arbitrary-wallet deep dives, but they are workarounds rather than dead ends.