Free, and how you read meaning into a phase. For each one it shows what usually happens next, how often a trend keeps running, and how the typical move rewarded you against how far it drew down first. Every figure comes with the number of past cases behind it. It's a behavior model built from years of Bitcoin history, not live per-coin data, so pair it with get_phase.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint=true, the description still adds meaningful behavioral context by disclosing that the statistics are derived from years of Bitcoin history rather than live data, and that every figure includes a case count. This helps the agent interpret the results appropriately. No contradiction with the annotation is present.
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?
Most sentences earn their place by describing output semantics, data source, and pairing guidance. However, the first sentence 'Free, and how you read meaning into a phase' is unclear and adds noise. The rest is reasonably compact, but the opener prevents a higher structure score.
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?
For a read-only, zero-parameter tool, the description covers the essential context: what each statistic represents, the historical basis, the distinction from live data, and the recommendation to pair it with get_phase. It does not describe an exact return format, but since there is no output schema and no parameters, this is a minor gap rather than a blocking one.
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?
The tool has zero parameters, so there is no parameter burden for the description to carry. Schema coverage is 100%, and the baseline for a zero-parameter tool is 4. The description appropriately focuses on behavior and output meaning instead.
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 lists concrete outputs: what usually happens next, trend continuation frequency, reward vs. drawdown, and sample sizes, which makes the tool's purpose specific and more than a tautology. It also positions it as a phase behavior model rather than live per-coin data. However, the opening phrase 'Free, and how you read meaning into a phase' is awkward and does not crisply differentiate it from siblings like list_phase_meta or compose_phases.
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 gives clear usage context: it is a historical behavior model, not live per-coin data, and should be paired with get_phase. This tells the agent when to rely on it and what complementary tool to use. It does not explicitly list exclusions or compare against all sibling tools, so it stops short of a 5.
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.
Each tool has a distinct role: account/billing tools (balance, usage, notifications, deposit poll) are clearly separated from market-data tools (single phase, batch phases, phase metadata, phase stats). Even get_phase and compose_phases are differentiated by single-coin/single-timeframe vs multi-coin/multi-timeframe, and the descriptions make that boundary explicit.
Most tools follow a get_ or verb_noun pattern (get_balance, get_phase, get_usage, compose_phases, deposit_poll), but 'phase_resolution_stats' breaks the pattern by lacking a verb, and 'compose_phases' vs 'get_phase' uses different verbs for closely related operations. The naming is still readable and predictable overall.
Eight tools is well-scoped for this server: four handle the paid signal-reading workflow and four handle account/billing support around it. There are no redundant or throwaway tools, and each one earns its place.
The server covers the full workflow: discover what phases exist and pricing (list_phase_meta), get current readings (get_phase/compose_phases), interpret them (phase_resolution_stats), and manage the prepaid account (get_balance, get_usage, get_notifications, deposit_poll). No obvious dead ends or missing operations for the stated purpose.