Skip to main content
Glama
JCF0

CG Alpha MCP

by JCF0

ta_rsi

Read-only

Calculate the Relative Strength Index (RSI) for crypto market analysis using Wilder's method to identify overbought or oversold conditions in token price data.

Instructions

Compute RSI (Wilder). Inputs: values:number[] (oldest→newest), period?:number(14). Returns latest RSI.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
valuesYes
periodNo

Implementation Reference

  • MCP tool handler for ta_rsi: validates input array of values and period, calls taRSI helper, returns RSI value or error.
    "ta_rsi": async (args) => {
      const values = Array.isArray(args?.values) ? args.values : null;
      const period = Number.isFinite(Number(args?.period)) ? Number(args.period) : 14;
      if (!values || values.length === 0) {
        return { content: textContent({ error:true, message:"'values' must be a non-empty array of numbers (oldest → newest)" }), isError:true };
      }
      const out = taRSI(values, period);
      return { content: textContent({ ok:true, rsi: out, period }) };
    },
  • mcp-server.js:328-335 (registration)
    Registration of ta_rsi tool in the tools list, including description, input schema, and annotations for MCP protocol.
    { name:"ta_rsi",
      description:"Compute RSI (Wilder). Inputs: values:number[] (oldest→newest), period?:number(14). Returns latest RSI.",
      inputSchema:{ type:"object", properties:{
        values:{ type:"array", items:{ type:"number" } },
        period:{ type:"number" }
      }, required:["values"] },
      annotations:{ title:"TA: RSI", readOnlyHint:true, openWorldHint:false }
    },
  • Input schema definition for ta_rsi tool parameters.
    inputSchema:{ type:"object", properties:{
      values:{ type:"array", items:{ type:"number" } },
      period:{ type:"number" }
    }, required:["values"] },
  • Core implementation of RSI (Wilder's method) computation function, exported and used as taRSI by the handler.
    export function rsi(values, period = 14) {
      const arr = normalize(values);
      if (arr.length < period + 1) return null;
    
      // Seed averages over the first `period` deltas
      let gains = 0, losses = 0;
      for (let i = 1; i <= period; i++) {
        const d = arr[i] - arr[i - 1];
        if (d >= 0) gains += d; else losses -= d;
      }
      let avgGain = gains / period;
      let avgLoss = losses / period;
    
      // Wilder smoothing for the remaining deltas
      for (let i = period + 1; i < arr.length; i++) {
        const d = arr[i] - arr[i - 1];
        const gain = d > 0 ? d : 0;
        const loss = d < 0 ? -d : 0;
        avgGain = (avgGain * (period - 1) + gain) / period;
        avgLoss = (avgLoss * (period - 1) + loss) / period;
      }
    
      if (!isFiniteNum(avgGain) || !isFiniteNum(avgLoss)) return null;
    
      // Handle flat / division-by-zero cases explicitly
      if (avgLoss === 0) {
        if (avgGain === 0) return 50;   // perfectly flat
        return 100;                     // only gains
      }
    
      const rs = avgGain / avgLoss;
      if (!isFiniteNum(rs)) return null;
    
      const rsi = 100 - (100 / (1 + rs));
      return isFiniteNum(rsi) ? clamp(rsi, 0, 100) : null;
    }
Behavior3/5

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

Annotations already provide readOnlyHint=true and openWorldHint=false, indicating this is a safe, deterministic calculation. The description adds useful context about the Wilder method and return format ('Returns latest RSI'), which goes beyond annotations. However, it doesn't mention computational complexity, error conditions, or data requirements beyond what's in parameters.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Extremely efficient single sentence that packs purpose, parameters with semantics, and return value. Every word earns its place with zero redundancy. The structure is front-loaded with the core purpose followed by implementation details.

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 calculation tool with good annotations (readOnlyHint, openWorldHint) but no output schema, the description provides complete context about what it computes, how to format inputs, and what it returns. The main gap is lack of error handling information, but otherwise covers the essential aspects well.

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?

With 0% schema description coverage, the description fully compensates by explaining both parameters: 'values:number[] (oldest→newest)' clarifies the array ordering requirement, and 'period?:number(14)' specifies the default value and optional nature. This adds significant meaning beyond the bare 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 clearly states the specific action ('Compute RSI (Wilder)'), resource (RSI indicator), and distinguishes from siblings by specifying the Wilder method. It explicitly identifies the mathematical calculation being performed rather than just restating the name.

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

Usage Guidelines3/5

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

The description implies usage context through the parameter explanation (values array ordering, period default), but doesn't explicitly state when to use this tool versus alternatives like ta_bollinger or ta_summary. No guidance is provided about when this tool is appropriate versus other technical analysis tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/JCF0/cg-alpha-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server