Skip to main content
Glama

Top Losers Screener

top_losers
Read-only

Return top losers for an exchange and timeframe. Supports crypto (KUCOIN, BINANCE, MEXC) and stocks (EGX, BIST, NASDAQ).

Returns ``list[dict]`` on success. On ANY failure returns a structured
error envelope ``{"error": {"code": ..., "retryable": ...}}``.

Input Schema

NameRequiredDescriptionDefault
limitNo
exchangeNoKUCOIN
timeframeNo15m

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.5/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so safety is covered. The description adds genuinely useful behavior beyond that: it declares the success type (list[dict]) and, more valuably, that ANY failure returns a structured error envelope with code and retryable fields, telling the agent how to branch on failure.

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?

Two short sentences, purpose front-loaded, then the return/error contract. No filler, though the success-type sentence is partly redundant against the existing output schema.

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 read-only, fully-defaulted 3-param screener with an output schema, the description covers purpose, valid venues, and error behavior adequately. The remaining gap is that timeframe and limit semantics are undocumented anywhere.

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 description coverage is 0% for all three parameters, so the description carries the burden. It partially compensates by enumerating valid exchange values (KUCOIN, BINANCE, MEXC, EGX, BIST, NASDAQ), which meaningfully constrains the 'exchange' param, but 'limit' and 'timeframe' (and their accepted formats/defaults of 25 and 15m) are left entirely unexplained.

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 states a specific verb and resource ('Return top losers for an exchange and timeframe'), which an agent can immediately distinguish from siblings like top_gainers or stock_screener. It stops short of explicitly naming a sibling it is not, so it lands at clear-but-not-differentiating.

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

Usage Guidelines2/5

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

It tells the agent which venues are valid (crypto vs stocks) but gives no when-to-use guidance, no comparison against top_gainers or the many screener siblings, and no prerequisites. The agent must infer selection criteria entirely from the tool name.

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.