Perpetual-swap funding rates; optional comma-separated coins filter. Pay per call via x402 ($0.003, USDC on Base), or 1 credit(s) with a prepaid session.
| Name | Required | Description | Default |
|---|---|---|---|
| coins | No | e.g. BTC,ETH |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With annotations already declaring readOnlyHint=true and openWorldHint=true, the description adds valuable behavioral context by specifying the exact cost structure ($0.003 USDC on Base per call or 1 credit with prepaid session). It also notes the optional comma-separated coin filter, which is a behavioral input trait. No contradictions with annotations are present.
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, compact sentence that includes the core purpose, the optional filter behavior, and the payment model in a clear and efficient manner. Every part of the sentence adds value, with no redundant or fluff content. It is ideally front-loaded with the primary functional description.
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?
Given that this is a simple read-only data-fetching tool with a single optional parameter, the description provides sufficient context for invocation: what it returns (funding rates), how to filter (comma-separated coins), and what it costs. The absence of an output schema is acceptable here because the resource type is self-explanatory and no complex return structure is implied.
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 schema covers the single parameter 'coins' with an example, but the description adds the crucial 'comma-separated' format and explicitly marks it as optional. This enriches the parameter meaning beyond the schema's minimal type/example. Since schema coverage is 100% and the description adds format detail, the score is above the baseline.
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 clearly identifies the tool's purpose as providing perpetual-swap funding rates, which is a specific financial resource distinct from the sibling tools. It lacks an explicit verb like 'get' or 'fetch', but the noun phrase 'Perpetual-swap funding rates' communicates the resource unambiguously. The optional coins filter is also mentioned, adding scope clarity.
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 does not provide any guidance on when to use this tool versus alternatives such as crypto_price or catalog. It mentions the optional comma-separated filter, which is parameter usage rather than tool-selection guidance. There are no explicit usage scenarios, prerequisites, or conditions when this tool should be chosen over others.
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: catalog for discovery/pricing, chat for LLM completion, crypto_price for spot prices, funding_rates for perp funding, and random for randomness. There is no overlap or ambiguity between any two tools.
All tool names follow a consistent lowercase_with_underscores pattern (catalog, chat, crypto_price, funding_rates, random). No mixing of conventions or inconsistent verb styles.
With 5 tools, the set is well-scoped for a multi-purpose utility API. Each tool provides a distinct service, and the count is within the ideal 3-15 range.
The tool surface covers the apparent domain (paid utility endpoints) well, including a catalog for discovery and payment instructions. A minor gap is the lack of an explicit balance/session status tool, but this is not critical for the core workflows.