Skip to main content
Glama
Sign In

Isoba — Dollar & Crisis Index

by io.github.nickarstrong
OverviewDiscussionsAdmin

Isoba: monthly history

get_monthly_history
Read-onlyIdempotent

Monthly averages of one or several instruments between two months (DSI since 2006, the others since 1990), with the zone of each month: dollar index, crisis meter, market shock, market anomalies, market-top and recession risk. Use for trends and to see what the instruments showed around past events.

Input Schema

NameRequiredDescriptionDefault
toNoLast month, YYYY-MM (default: latest)
fromNoFirst month, YYYY-MM (default: 24 months ago)
instrumentNodsi — Dollar System Index; crisis — Crisis meter; market_shock — market shock; anomalies — market anomalies (% of 18 series); top_risk — market-top risk; recession_risk — US recession risk
instrumentsNoSeveral instruments at once (instead of instrument)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • changedInput schema / properties / instrument / description
      Previous value: -"dsi — Dollar System Index; crisis — Crisis meter; top_risk — market-top risk; recession_risk — US recession risk"New value: +"dsi — Dollar System Index; crisis — Crisis meter; market_shock — market shock; anomalies — market anomalies (% of 18 series); top_risk — market-top risk; recession_risk — US recession risk"
    • changedInput schema / properties / instrument / enum
      Previous value: -[
-  "dsi",
-  "crisis",
-  "top_risk",
-  "recession_risk"
-]New value: +[
+  "dsi",
+  "crisis",
+  "market_shock",
+  "anomalies",
+  "top_risk",
+  "recession_risk"
+]
    • changedInput schema / properties / instruments / items / enum
      Previous value: -[
-  "dsi",
-  "crisis",
-  "top_risk",
-  "recession_risk"
-]New value: +[
+  "dsi",
+  "crisis",
+  "market_shock",
+  "anomalies",
+  "top_risk",
+  "recession_risk"
+]
    • changedInput schema / properties / instruments / maxItems
      Previous value: -4New value: +6
  2. Changed2 schema fields changed
    • addedInput schema / properties / instruments
      Added value: +{
+  "description": "Several instruments at once (instead of instrument)",
+  "items": {
+    "enum": [
+      "dsi",
+      "crisis",
+      "top_risk",
+      "recession_risk"
+    ],
+    "type": "string"
+  },
+  "maxItems": 4,
+  "minItems": 1,
+  "type": "array"
+}
    • removedInput schema / required
      Removed value: -[
-  "instrument"
-]
  3. First observed

TDQS

A4/5.0
Behavior4/5

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

Annotations already establish read-only, idempotent, closed-world behavior. The description adds valuable context beyond that: instrument-specific history start dates (DSI since 2006, others since 1990) and the per-month zone fields returned, though it omits response format or pagination details.

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?

Two dense sentences with the purpose and usage front-loaded; the instrument list and date coverage are necessary context rather than filler.

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 read-only historical data tool with fully documented optional parameters and annotations, the description covers scope, data availability, and return contents. It could be slightly more complete by clarifying the response structure or pagination, but no output schema exists to carry that burden.

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 description coverage is 100%, so parameter meaning is largely supplied by the schema's detailed enum and date-pattern descriptions. The description adds only modest context by saying 'one or several instruments' and noting instrument-specific history start dates, which can affect valid date ranges.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific operation: monthly averages of one or several instruments over a month range, plus per-month zone indicators. It is distinguishable from current/date-specific siblings by its monthly aggregation and historical range, though it does not explicitly name an alternative.

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?

It gives a clear use case: trends and seeing what instruments showed around past events. It does not specify when not to use it or name a sibling alternative, so it falls short of full when/when-not guidance.

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

All Isoba — Dollar & Crisis Index toolsInspect
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