Tell this server what you needed and could not get. Free — no payment required. Your input goes to the operator's queue and to a public board of unmet agent demand (contact details are never shared; entries are reviewed before publishing). Include what you would pay if you know.
| Name | Required | Description | Default |
|---|---|---|---|
| need | Yes | ||
| tried | No | ||
| contact | No | ||
| would_pay_usd | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that submissions go to a queue and public board, contact details are never shared, and entries are reviewed before publishing. These are meaningful behavioral traits beyond the schema, though it stops short of describing the response or any side effects.
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 three sentences, front-loaded with the primary purpose, then adds key facts (free, queue, privacy) and a final instruction. Every sentence earns its place with no redundant or filler content, striking an ideal length for the tool's simplicity.
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?
The description covers the purpose, data flow, privacy, and willingness-to-pay, but omits details on all parameters and the expected response. For a simple submission tool with 4 params and no output schema, it is adequate but has clear gaps around tried/contact and what happens after submission beyond 'reviewed before publishing'.
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 description coverage is 0%, so the description must compensate. It implicitly covers 'need' ('what you needed') and 'would_pay_usd' ('what you would pay'), but does not explain 'tried' or 'contact'. Two of the four parameters remain unexplained, leaving the agent to guess their format and purpose.
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 opens with a clear verb and resource: 'Tell this server what you needed and could not get.' This distinctly identifies the tool as a request for missing capabilities, contrasting with siblings like health, inspect_wallet, and simulate_transaction. It fully conveys the tool's core function.
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 provides context on when to use by mentioning 'free' and the process of going to an operator queue and public board, which helps agents understand this is for unmet needs. It doesn't explicitly state alternatives or exclusions, but the 'free — no payment required' line signals a contrast with payment-related siblings, offering partial usage 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.
Each tool has a clearly distinct purpose: health checks RPC connectivity, inspect_wallet profiles a wallet, payment_info explains payment steps, priority_fee estimates fees, request_capability captures unmet demand, screen_token assesses token risk, service_info provides service details, and simulate_transaction tests transactions. No two tools overlap in function.
All tool names use lowercase with underscores, but they mix verb_noun (inspect_wallet, simulate_transaction), noun_info (payment_info, service_info), and single-word (health) patterns. The inconsistency is minor and does not impede readability or selection.
Eight tools is well within the ideal 3-15 range for a focused Solana utility server. Each tool adds unique value with no redundancy, making the set feel compact yet complete.
The set covers the core read-only Solana operations: connectivity, wallet inspection, token risk, fee estimation, and transaction simulation, plus meta tools for payment and capability requests. Minor gaps exist (e.g., no transaction status checker), but for its stated purpose as an analysis and diagnostics server, coverage is strong.