Skip to main content
Glama

TradingCalc MCP: Options, Forex, Risk Stats, Prediction Markets, On-Chain & Crypto Futures

Fibonacci Levels

workflow.run_fibonacci_levels
Read-only

Fibonacci retracement and extension price levels from a swing high and low, for any asset (forex, stocks, crypto): retracement 0, 23.6, 38.2, 50, 61.8, 78.6 and 100 percent and extension 127.2, 161.8, 200 and 261.8 percent, as prices. direction "up" measures a rise from the low to the high, "down" a fall from the high to the low; 0 percent is the end of the swing and 100 percent its start. A level at or below zero (an extension of a steep fall) comes back as price null. The ratios are a charting convention, not a forecast. Pure price arithmetic, no pair or market data. Edge cases: high and low above zero and finite, high above low (equal or reversed is an error); direction is up or down. Not covered: choosing the swing points, confluence with other levels, and any statement about where price will turn; the levels are arithmetic.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "high": "<high>",
      "low": "<low>",
      "direction": "<direction>"
    },
    "name": "workflow.run_fibonacci_levels"
  }
}

Input Schema

NameRequiredDescriptionDefault
lowYesSwing low price (positive, below the high)
highYesSwing high price (positive, above the low, at most 1e300)
directionYes"up": the swing rose from the low to the high; "down": it fell from the high to the low

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.6/5.0
Behavior5/5

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

Beyond the readOnly/openWorld/destructive annotations, it discloses output behavior (a level at or below zero returns price null), input error conditions (high must exceed low, both positive and finite), and an important interpretive caveat (ratios are a charting convention, not a forecast). That is substantive behavioral context an agent cannot infer from the structured fields.

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 concrete output (the level list) before the semantics and caveats, and every clause carries information. It is somewhat dense in a single paragraph, and the 'Edge cases' clause partly restates constraints already encoded in the schema (positive, high above low, enum direction), which is minor redundancy.

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?

There is no output schema, and the description compensates fully by enumerating the returned level percentages, describing the price form of results, and specifying the null case. Combined with the stated error conditions, an agent has everything needed to call this correctly and interpret the response.

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%, so the baseline is 3, but the description adds real meaning: it defines the direction semantics in terms of the swing ('up' measures a rise from low to high) and anchors the percentage scale ('0 percent is the end of the swing and 100 percent its start'). That anchoring is not present in the schema and changes how the returned levels should be interpreted.

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+resource (compute Fibonacci retracement and extension price levels from a swing high and low) and enumerates the exact levels returned. It also distinguishes itself from data-dependent siblings by noting 'Pure price arithmetic, no pair or market data,' so an agent can tell it apart from the live/quote-based workflow tools without opening the schema.

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

Usage Guidelines4/5

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

Clear about applicability ('for any asset: forex, stocks, crypto') and explicitly scopes out related tasks it does not do ('Not covered: choosing the swing points, confluence with other levels...'), which tells the agent when not to expect this tool to solve the broader problem. It does not name a specific alternative sibling to route to, so it stops short of full routing guidance.

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.