Indexes MCP Use Cases

This page shows practical ways to combine the Indexes MCP tools into repeatable workflows.

1. Discover the active members of an index family

Use this workflow when you know the family or definition, but not which members currently have values.

Step 1: inspect the catalog

{
  "tool": "indexes_list",
  "arguments": {}
}

Step 2: request the current family snapshot

{
  "tool": "indexes_get_current_snapshot",
  "arguments": {
    "index_definition_id": "IDX_REFRATE_FX"
  }
}

Why this works well

• indexes_list gives you the raw identifier universe.
• indexes_get_current_snapshot shows which members are currently returning values.
• This is a practical way to avoid guessing individual index_id values for single-index calls.

2. Read the latest value for one tracked index

Use this when your application already stores a specific index_id and only needs the latest value.

{
  "tool": "indexes_get_current",
  "arguments": {
    "index_id": "IDX_REFRATE_FX_USD"
  }
}

This is useful for:

• lightweight monitoring dashboards
• periodic health checks
• agents that need a compact latest-value response

3. Build a point-in-time historical snapshot

Use this workflow when you want all members of a definition at one historical timestamp.

Step 1: pick the definition

{
  "tool": "indexes_get_history_snapshot",
  "arguments": {
    "index_definition_id": "IDX_REFRATE_FX",
    "time": "2025-01-01T00:00:00Z"
  }
}

When this is useful

• you need a historical cross-section of one family
• you want to compare multiple members at the same moment
• you are rebuilding a report for a past valuation date

4. Inspect historical composition for one index

Use this workflow when you need more than just the historical value and want to understand the composition fields returned by the API.

{
  "tool": "indexes_get_history",
  "arguments": {
    "index_id": "IDX_REFRATE_FX_USD",
    "time_start": "2026-04-01T00:00:00Z",
    "time_end": "2026-04-07T00:00:00Z",
    "limit": 100
  }
}

Why this works well

• indexes_get_history returns composition alongside timestamp and value.
• This helps when you need explainability or component-level inspection.
• It is better than OHLC data when the exact point history matters more than candles.

5. Build an OHLC charting workflow

Use this workflow when the goal is charting, indicators, or interval-based analytics.

Step 1: list supported periods

{
  "tool": "periods_list",
  "arguments": {}
}

Step 2: request candles

{
  "tool": "indexes_get_timeseries",
  "arguments": {
    "index_id": "IDX_REFRATE_FX_USD",
    "period_id": "1DAY",
    "limit": 30
  }
}

Why this works well

• periods_list gives you valid period_id values up front.
• indexes_get_timeseries returns OHLC fields like value_open, value_high, value_low, and value_close.
• This pattern fits chart components, trend analysis, and scheduled reporting.

6. Audit multi-asset weights

Use this when you want to inspect how multi-asset indexes are configured.

Step 1: list all configured weights

{
  "tool": "multiasset_list_weights",
  "arguments": {}
}

Step 2: inspect one index in detail

{
  "tool": "multiasset_get_weights",
  "arguments": {
    "index_id": "IDX_MULTIASSET_TEST"
  }
}

Why this works well

• multiasset_list_weights gives you the overall inventory.
• multiasset_get_weights narrows that inventory to one target index.
• This is useful before any write operation or administrative review.

7. Manage multi-asset weights in an admin workflow

Use this only in authorized back-office workflows.

Update weights

{
  "tool": "multiasset_update_weights",
  "arguments": {
    "index_id": "IDX_MULTIASSET_TEST",
    "weights": [
      {
        "indexId": "IDX_MULTIASSET_TEST",
        "assetId": "BTC",
        "weight": 2
      },
      {
        "indexId": "IDX_MULTIASSET_TEST",
        "assetId": "ETH",
        "weight": 1
      }
    ]
  }
}

Delete weights

{
  "tool": "multiasset_delete_weights",
  "arguments": {
    "index_id": "IDX_MULTIASSET_TEST"
  }
}

Important note

• multiasset_update_weights and multiasset_delete_weights are write operations.
• They should only be exposed to trusted users and controlled automation.
• For read-only analysis, prefer multiasset_list_weights and multiasset_get_weights.

Notes

• Keep index_id, index_definition_id, and period_id exactly as exposed by the MCP schema.
• A family snapshot is often the easiest way to identify live members before making single-index requests.
• Use indexes_get_history when you need composition data and indexes_get_timeseries when you need OHLC candles.