Get a real-time Sell Now quote for any CoinSpot coin by entering the ticker and amount in coins or AUD.
Get a Sell Now quote.
Args:
cointype: Coin ticker such as BTC.
amount: Amount to sell.
amounttype: Whether amount is 'coin' or 'aud'.
| Name | Required | Description | Default |
|---|---|---|---|
| amount | Yes | ||
| cointype | Yes | ||
| amounttype | No | coin |
| Name | Required | Description | Default |
|---|---|---|---|
| result | Yes |
Changes observed during successful MCP inspections.
v0.1.1Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds nothing beyond the schema restated as Args — no note on quote validity windows, rate limits, or that the returned quote is indicative rather than an executed trade.
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?
Front-loaded with the one-line purpose, followed by a terse Args block. Nothing is padded, though presenting the parameters as 'Args' prose partly duplicates the schema rather than adding new information.
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?
An output schema exists, so return values need not be described, and the parameter meanings are covered. What remains missing is the operational context — when to call this versus the live price or order tools — which matters for a quote tool sitting among many pricing siblings.
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% with no enums, so the description carries the full burden and does compensate: it explains cointype as a ticker like BTC, amount as the quantity, and amounttype as 'coin' or 'aud'. This is the only source of meaning for those three fields, and it usefully exposes the two-value semantics that the schema omits.
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?
States a specific verb+resource: produces a 'Sell Now' quote, which parallels and is distinguishable from the sibling quote_buy_now and quote_swap_now by the resource qualifier. It never explicitly names an alternative, so differentiation relies on the agent inferring the buy/sell/swap split from names.
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?
There is no when-to-use statement, no mention of prerequisites or account access, and no comparison against get_sell_price or quote_buy_now. The agent must infer that this is the pre-trade pricing step from the word 'quote' alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.