RSI, MACD, Bollinger Bands, ATR ($0.003 USDC)
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | No | BTCUSDT | |
| payment | No | Optional. Base64 x402 payment payload you signed yourself (ERC-3009 TransferWithAuthorization, USDC on Base). Call without it once to receive the payment requirements, sign those, then call again with this argument. This server forwards the payload and never holds a key. | |
| interval | No | 1h |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Input schema / properties / paymentAdded value: +{
+ "description": "Optional. Base64 x402 payment payload you signed yourself (ERC-3009 TransferWithAuthorization, USDC on Base). Call without it once to receive the payment requirements, sign those, then call again with this argument. This server forwards the payload and never holds a key.",
+ "type": "string"
+}Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry behavioral context. It reveals a per-call cost in USDC and a payment payload requirement, which is useful, but it omits any mention of the likely flow (call first without a payment token to get payment requirements, then re-call with the signed payload). It also doesn't disclose that the server forwards the payload and never holds a key, even though the schema's payment description does. The description is too short to fully disclose payment and failure behavior.
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 extremely concise: a short list of indicators and a cost. Nothing is wasted. It is not as richly structured as it could be; a single sentence with a verb would be clearer, but it remains scanable and adequate.
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?
The description covers what the tool returns and its nominal cost, which is the most mission-critical information. However, it lacks a mention of the two-call payment flow and any detail about return shape. Since there is no output schema and no annotations, one extra sentence about how payment is provided would meaningfully improve an agent's chance of invoking it correctly.
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?
Only about 33% of parameters are described in the schema, so the description adds value by naming the computed indicators and payment requirement. The interval enum is self-explanatory and symbol has a default, so the agent can still call the tool correctly. Some details about payment flow are in the payment parameter description, but the description itself reinforces the cost.
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 names a concrete resource (technical indicators) and lists the specific indicators (RSI, MACD, Bollinger Bands, ATR), which distinguishes it from broader or sentiment-based siblings. It does not explicitly state 'retrieve' or 'get', but the tool name covers that verb. Overall, an agent can identify what this tool does and which type of data it returns.
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 implies the tool is used to fetch technical indicators for a symbol at a given interval, with a payment requirement. It does not explain when to choose this over similar siblings like get_volatility, get_market_pulse, or get_support_resistance. It also lacks explicit alternative/routing guidance, so an agent would rely on name matching and the indicator list.
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.
Most tools target clearly distinct metrics, but the paid/free sample pairs (get_crypto_prices/try_crypto_prices, etc.) and overlapping summary tools (get_market_overview, get_market_pulse, get_overnight_risk_brief) create some selection ambiguity. Descriptions list components, so an agent can disambiguate with effort, but the boundaries between bundles and single-purpose tools are not always obvious.
Tool names consistently follow a verb_noun pattern: get_ for data retrieval, try_ for free samples, and watch_condition for persistent monitoring. All names use lowercase snake_case with no mixed conventions, making the naming predictable and easy to navigate.
34 tools is well above the comfortable range for a typical MCP server and feels heavy even for a broad crypto data domain. The count is inflated by paid/free sample duplicates and multiple bundle variants that could have been consolidated.
The surface covers a wide range of crypto data: prices, funding, sentiment, arbitrage, derivatives, on-chain metrics, signal history, and monitoring. Minor gaps exist—such as no obvious generic signal discovery tool or order-book/trade-level data—but the core domain of market data with checkable records is thoroughly served.