Skip to main content
Glama

buy_tok_APTM

Paid. Apertum (APTM) price: live USD price, 24h change and market-cap rank. $0.05 USDC on Base or Solana. No account, no API key. Failed calls not charged. URL https://southpow.media/v1/price/APTM.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "buy_tok_APTM"
  }
}

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A3.8/5.0
Behavior4/5

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

With no annotations supplied, the description carries the full burden and does well: it discloses that the call is paid, the exact price ($0.05 USDC), the accepted chains (Base or Solana), that no auth is needed, and that failed calls are not charged. It omits rate limits, latency/freshness of the quote, and what an error response looks like.

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

Conciseness4/5

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

Very compact and front-loaded — the resource and returned fields come first, then cost and payment mechanics. The telegraphic fragments ('Paid.', trailing bare URL) read as machine-generated rather than prose, but no sentence is wasted.

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

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter, side-effect-free lookup with no output schema and no annotations, the definition covers capability, cost, payment rails, auth requirements, and refund behavior — enough for an agent to call it confidently. Only the response shape and failure modes are left unstated.

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

Parameters4/5

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

The tool takes zero parameters, so per the baseline this scores 4; there is nothing for the description to disambiguate. The endpoint URL is included, which is additive context rather than a parameter concern.

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

Purpose4/5

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

The description names the exact resource and verb scope: 'Apertum (APTM) price: live USD price, 24h change and market-cap rank', so an agent knows precisely what data comes back. It falls short of a 5 because it gives no sibling differentiation against the large buy_coin_* / buy_crypto_price family, and 'APTM' could be confused with the nearby buy_coin_APT (Aptos) entry.

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

Usage Guidelines3/5

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

Usage is only implied by the tool's subject matter — an agent would infer 'call this to get Apertum price data'. The description states prerequisites ('No account, no API key') but never says when to prefer this over buy_coin_APTM or buy_crypto_price, and offers no exclusions.

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