Skip to main content
Glama

Rule-based signal score

get_signal_score
Read-onlyIdempotent

A -100 to +100 score for one coin from fixed, published rules over trend, 24h momentum, RSI, funding, open interest, account crowding, Fear & Greed and major news, with each component's input and points and a label (strong_bearish to strong_bullish). Use as one input to your own decision and show the components. Not for placing orders (use preview_order); not advice or a forecast. Input: symbol (base coin). Rules in method. Next: size_position.

Input Schema

NameRequiredDescriptionDefault
symbolYesBase coin, e.g. BTC

Output Schema

NameRequiredDescriptionDefault
as_ofYesISO 8601 UTC
labelYesstrong_bearish, bearish, neutral, bullish or strong_bullish
scoreYes-100 (all components bearish) to +100 (all bullish)
methodYesThe fixed rules
symbolYesBase coin
horizonYesThe time frame the inputs describe
coverageYesShare of the possible points whose data was available, 0-1
componentsYesEach input with its points
not_adviceYesWhat the score is and is not
deprecationNoPresent only while this tool is deprecated: replacement, removal_date, changelog

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already cover the safety profile (readOnlyHint, idempotent, non-destructive), and the description adds genuinely new context: the score derives from fixed, published rules rather than a model forecast, the response includes each component's input and points plus a categorical label from strong_bearish to strong_bullish, and the result should be surfaced to the user. It also explicitly disclaims advisory/forecast status, which is behavioral information absent from the annotations.

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?

The score range and factor list are front-loaded, and the exclusions plus next-step are packed into short clauses with no filler sentences. The final 'Input: symbol (base coin)' restates the schema and is the one line that does not earn its place.

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 shape need not be re-explained, yet the description still signals that components and a label come back. For a single-parameter, read-only analytical tool with a defined downstream workflow (preview_order, size_position), nothing an agent needs in order to call it correctly is missing.

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?

Schema coverage is 100% and the single parameter is already documented as 'Base coin, e.g. BTC'; the description's 'Input: symbol (base coin)' reinforces the same meaning without adding new syntax or format constraints. With one fully documented parameter this meets the baseline, but adds little beyond the schema.

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?

The description names a specific verb-derived resource ('A -100 to +100 score for one coin') and enumerates the exact factors feeding it (trend, 24h momentum, RSI, funding, open interest, account crowding, Fear & Greed, major news). This clearly separates it from neighbors like get_technical_indicators or get_market_positioning, which supply raw inputs rather than a composite labeled score.

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?

Explicit routing is given in both directions: 'Use as one input to your own decision and show the components', 'Not for placing orders (use preview_order)', and 'Next: size_position.' It states when to use, when not to use, the alternative to pick instead, and the follow-on tool.

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