Skip to main content
Glama

market_status

Read-onlyIdempotent

Check available spend before priced AI service invokes: hub health, remaining free trial uses, and prepaid USD balance. Use it before a run or after a payment refusal instead of retrying.

Instructions

Show what market_invoke can spend right now: the hub's health, how many free trial invokes this installation has left in the current window, and, when AIMARKET_API_KEY is set, its prepaid balance in USD. Call it before a run of priced invokes or after one is refused for payment, instead of retrying. Read-only, free, takes no input, never shows the key.

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": "market_status"
  }
}

Input Schema

NameRequiredDescriptionDefault

No arguments

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.6.4

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already cover readOnly, idempotent, non-destructive and openWorld, so safety is declared. The description adds value beyond them: the call is free, takes no input, the balance only appears when AIMARKET_API_KEY is set, and the key itself is never returned — an important privacy guarantee an agent could not derive from the annotations. It stops short of describing cost/rate-limit behavior of the status check itself.

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?

Front-loaded with the payoff, then a colon-delimited list of the three facts returned, then the call-timing guidance. Every clause earns its place, though the single long sentence carrying both semantics and usage is dense enough to reward a second read.

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 needn't be spelled out, and the description still summarizes the three visible signals. Combined with the free/read-only/key-safe disclosures, an agent has everything needed to decide to call it and to interpret a refusal-then-check workflow.

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?

Zero parameters, so the description only needs to confirm that calling requires no arguments, which it does explicitly ("takes no input"). Baseline for a parameterless tool; nothing further is owed.

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 and resource — "Show what market_invoke can spend right now" — then enumerates exactly what that means: hub health, remaining free trial invokes in the current window, and prepaid USD balance when AIMARKET_API_KEY is set. It names the sibling it relates to (market_invoke) and cannot be confused with market_search or web_search.

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?

Gives both a proactive trigger (before a run of priced invokes) and a reactive one (after an invoke is refused for payment), plus an explicit anti-pattern: "instead of retrying." That is a when-to-use, a when-else-to-use, and a do-not-do all in one clause.

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