Start here (free, compact): 3 tools + prices + cluster do_not + honest usage. Pass detail=full for quota/pass/onboarding. Then get_liq_radar.
| Name | Required | Description | Default |
|---|---|---|---|
| detail | No | Default compact. full = quota/pass/onboarding. | |
| locale | No | Not a translation switch. Ignored. Catalog is English only. |
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 the operation is free, compact by default, and that passing detail=full provides additional quota/pass/onboarding info. However, terms like 'cluster do_not' and 'honest usage' are undefined, and no mention is made of side effects, permissions, or rate limits. It adds some context but leaves significant gaps.
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 concise at three sentences and front-loaded with 'Start here'. Each sentence serves a purpose: what it does, how to get more, and what to do next. However, the first sentence is dense and cryptic, using jargon that may confuse.
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 simple tool with two optional parameters and no output schema, the description gives a high-level summary of contents but leaves key terms ('cluster do_not', 'honest usage') undefined. It also doesn't clarify how this relates to swap_via_nattswap. It's adequate but not comprehensive.
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 baseline is 3. The description's parameter guidance ('Pass detail=full for quota/pass/onboarding') restates the schema's detail description without adding new semantics. The locale param is already well explained in the schema as ignored.
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 indicates the tool is a starting point that provides a catalog of 3 tools, prices, a cluster do-not list, and honest usage info. The verb is implicit ('Start here') and phrasing is cryptic, but it clearly positions itself as an entry point and differentiates from the sibling get_liq_radar by ordering the workflow.
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?
Explicitly says 'Start here' and 'Then get_liq_radar', establishing a clear usage sequence. It also advises using detail=full for quota/pass/onboarding, giving concrete parameter guidance. While it doesn't mention swap_via_nattswap, the primary alternative is addressed.
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.
The three tools are cleanly separated: one handles manifest/onboarding, one delivers liquidity radar data, and one executes swaps. The descriptions explicitly guide the intended order, so an agent is unlikely to choose the wrong tool.
The get_ prefix is used for the two read-oriented tools, and swap_via_nattswap is clearly an action tool. Everything uses snake_case and predictable verbs; the only minor deviation is the longer via_nattswap suffix on the swap tool.
Three tools is a tightly scoped set and each one earns its place: understand the server, read market terrain, act with a swap. The manifest even confirms the intentional three-tool design.
The tools form a coherent manifest-to-radar-to-swap workflow with no hard dead end. There are minor gaps such as no separate balance/status check or swap-history tool, but these feel outside the core scope rather than blocking.