CurrencyCore

Mean-reversion analysis

analyze_mean_reversion

Read-onlyIdempotent

Rank currencies by how strongly they revert to their historical mean, using a composite 0–100 score (crossing frequency + reversion half-life), plus current deviation and half-life in days. Use for questions like "does EUR snap back to its average". Provide currencies to score specific codes, or omit to rank the liquid set. Use analyze_history for raw change and analyze_volatility for dispersion. Defaults: roughly a 2-year window, base USD, limit 10. Returns { base, from, to, results[] }; score and halfLifeDays are null when there is not enough reverting data. Requires a signed-in connection and the Growth plan or higher; each successful call bills 1 API request.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "analyze_mean_reversion"
  }
}

Input Schema

Name	Required	Description
`to`	No	Window end YYYY-MM-DD (UTC). Defaults to today.
`base`	No	Base currency to measure against (3-letter ISO 4217). Defaults to USD.
`from`	No	Window start YYYY-MM-DD (UTC). Defaults to ~2 years before `to`.
`limit`	No	How many to return (default 10, max 50).
`currencies`	No	Comma-separated currencies to score, e.g. EUR,GBP. OMIT to rank the liquid set.

Output Schema

Name	Required	Description	Default
`to`	Yes
`base`	Yes
`from`	Yes
`results`	Yes
`universe`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 11, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "base": {
+      "type": "string"
+    },
+    "from": {
+      "type": "string"
+    },
+    "results": {
+      "items": {
+        "additionalProperties": false,
+        "properties": {
+          "currency": {
+            "type": "string"
+          },
+          "deviationPct": {
+            "anyOf": [
+              {
+                "type": "number"
+              },
+              {
+                "type": "null"
+              }
+            ]
+          },
+          "halfLifeDays": {
+            "anyOf": [
+              {
+                "type": "number"
+              },
+              {
+                "type": "null"
+              }
+            ]
+          },
+          "note": {
+            "type": "string"
+          },
+          "reversionFrequency": {
+            "anyOf": [
+              {
+                "type": "number"
+              },
+              {
+                "type": "null"
+              }
+            ]
+          },
+          "score": {
+            "anyOf": [
+              {
+                "type": "number"
+              },
+              {
+                "type": "null"
+              }
+            ]
+          }
+        },
+        "required": [
+          "currency",
+          "score",
+          "deviationPct",
+          "reversionFrequency",
+          "halfLifeDays"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "to": {
+      "type": "string"
+    },
+    "universe": {
+      "enum": [
+        "liquid",
+        "majors"
+      ],
+      "type": "string"
+    }
+  },
+  "required": [
+    "base",
+    "from",
+    "to",
+    "results"
+  ],
+  "type": "object"
+}

First observedNov 11, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already cover the read-only/idempotent/non-destructive profile, and the description adds substantive context beyond them: auth requirement, Growth-plan gating, 1 API request per successful call, and the important edge case that score and halfLifeDays are null when data is insufficient. It stops short of describing ordering granularity or error behavior, so not a 5.

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 meaning of the score, then usage routing, then defaults and return contract. Dense but nearly every sentence adds information; the defaults sentence partially duplicates the schema, which keeps it from a 5.

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?

For a read-only analytics tool with an output schema, full parameter documentation, and annotations, the description covers purpose, alternatives, defaults, plan/billing constraints, and null semantics. An agent could select and call this correctly without further information.

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 coverage is 100%, so all five parameters are already documented including defaults and the 50 max on limit. The description largely restates those defaults and the omit-currencies behavior rather than adding new semantics such as date format validation or how limit interacts with ranking ties. Baseline 3 applies when the schema carries the parameter burden.

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 and resource ('Rank currencies by how strongly they revert to their historical mean') and explains the scoring construct (composite 0–100 from crossing frequency + reversion half-life) plus the per-row outputs. It also spells out the exact question shape it answers, so an agent can match intent 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 Guidelines5/5

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

Gives when-to-use ('does EUR snap back to its average'), names two alternatives with their distinct roles (analyze_history for raw change, analyze_volatility for dispersion), and explains the currencies-supplied vs omitted branch. Nothing is left to inference.

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

All CurrencyCore tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?