Preview the exact lamport fee the given Solana wallet would pay for its next paid validation (fees escalate with consecutive failures).
| Name | Required | Description | Default |
|---|---|---|---|
| wallet_address | Yes | Solana wallet address. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It adds useful context by disclosing that fees escalate with consecutive failures, and the word 'Preview' implies a read-only operation without side effects. It does not detail other behavioral aspects like rate limits or exact calculation inputs, but covers the most important trait.
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 action ('Preview the exact lamport fee') and immediately identifies the target. Every word earns its place; there is no redundancy or filler.
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 one-parameter, no-output-schema tool, the description is complete enough: it states what the fee is for, for which wallet, and the key escalation behavior. It omits any explicit mention of return format or error conditions, but these are not necessary given the simplicity and the 'exact fee' implication.
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 fully describes 'wallet_address' as 'Solana wallet address', achieving 100% schema description coverage. The description only references 'the given Solana wallet' and adds no new detail about parameter format or requirements, so a baseline score of 3 is appropriate.
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 uses a specific verb 'Preview' and identifies a distinct resource 'exact lamport fee' for a given Solana wallet's next paid validation. This clearly differentiates it from sibling tools like get_pricing, which likely covers general pricing, or get_network_stats.
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 provides clear context that the tool is for previewing the fee before a paid validation, and notes that fees escalate with consecutive failures. However, it does not explicitly state when to use this over alternatives or exclude scenarios, so it misses the top score.
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 concerns: stats, pricing, profiles, fee previews, feature requests, and scoring. The main ambiguity is between get_pricing and preview_fee, but their descriptions clarify that one is the general pricing manifest and the other is a wallet-specific quote.
The majority of tools follow a readable snake_case verb_noun pattern, such as get_network_stats, list_profiles, preview_fee, request_feature, and score_text. The outlier is storelayer_widget_menu, which is a noun phrase rather than a clear verb action, and the retrieval verbs vary slightly, but the overall pattern is consistent enough.
Seven tools is a reasonable size for a scoring and benchmarking platform and stays well within the ideal range. However, storelayer_widget_menu feels like an unrelated promotional addition that does not earn its place alongside the scoring-focused tools.
The free scoring path, profile listing, pricing, and network stats are present, but the paid validation workflow via POST /api/simulate, progress reports via POST /api/progress, and bundle purchases are only described in get_pricing rather than exposed as MCP tools. This leaves a notable gap in the core paid workflow, though agents could fall back to REST.