Skip to main content
Glama

Quote Buy

ai_quote_buy
Read-onlyIdempotent

Recommended first call for a new agent: quote how much $AI a given amount of HYPE buys right now, before slippage. Read-only, no wallet needed, no key, no transaction. To buy it for real, call ai_build_buy_tx next with the same hype amount.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
hypeYesHYPE amount as a decimal string, e.g. "1.5" (max 10000)

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
tokensOutYes
disclosureYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "properties": {
      +    "disclosure": {
      +      "type": "string"
      +    },
      +    "tokensOut": {
      +      "type": "string"
      +    }
      +  },
      +  "required": [
      +    "tokensOut",
      +    "disclosure"
      +  ],
      +  "type": "object"
      +}
  2. First observed

TDQS

A4.5/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds genuinely new context beyond the annotations: no wallet, no key, no transaction, and the pre-slippage nature of the quote.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences, front-loaded with the recommended-first-call guidance and the quote semantics, with the follow-up action last. No filler or repetition of schema content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

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 no explanation. For a one-parameter read-only quote tool, the description covers purpose, precondition (no wallet/key), caveat (pre-slippage) and next step, leaving nothing an agent needs missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with a single fully documented `hype` parameter (format and max), so the schema carries the load. The description only echoes the parameter by reference ("same hype amount") and adds no format or semantics beyond the schema; baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (quote) and resource ($AI bought per HYPE), including the pre-slippage qualifier that pins down what the number means. It is clearly distinguishable from ai_quote_sell and ai_build_buy_tx.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly positions itself as the recommended first call for a new agent and names the follow-up action, ai_build_buy_tx with the same hype amount. Both when-to-use and the alternative are spelled out rather than inferred.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources