corpusAI Cloud Pricing

Monthly spot history

spot_monthly

Read-onlyIdempotent

Paid (0.05 USDC per call). Full monthly history for one instance type, back to 2014 for legacy AWS types. Calendar months from the earliest data to now. months is the curated series: uscisi-adjusted months (2017 to 2022-04, AWS types with a stable correction factor, average only), then months rolled up from the daily series (pauley, titans, direct: avg = median of daily averages, open/close from the first/last day, high/low the extremes, days = days covered, source = the source covering most days). archive (AWS, default on) is the USC/ISI monthly dataset 2014-02 to 2023-12 as published, with open/high/low/close, for 51 legacy types: third-party, mixes OS products, provenance partly unverified; returned separately so it never silently blends into the curated series.

Input Schema

TableJSON Schema

Name	Required	Description
`to`	No	Last month (inclusive), YYYY-MM-DD. Default: latest.
`from`	No	First month (inclusive), YYYY-MM-DD (use the 1st). Default: earliest.
`region`	Yes	Region slug as listed by /catalog (for example `us-east-1` for AWS, `us-central1` for GCP, `us-east` for Azure). Azure slugs map to `eastus`, `westus2`, `westeurope`. Example: us-east-1
`instance`	Yes	Instance / machine / SKU type name exactly as listed by /instances (for example `c5.large`, `n2-standard-4`, `D2s_v5`). Example: c5.large
`provider`	Yes	Cloud provider. One of `aws`, `gcp`, `azure`.
`include_archive`	No	Include the raw USC/ISI archive rows in `archive`. Default true.

Output Schema

TableJSON Schema

Name	Required	Description
`count`	No
`months`	No
`region`	No
`archive`	No	Raw USC/ISI archive months (AWS legacy types only), unadjusted.
`instance`	No
`provider`	No
`archive_note`	No	Standing of the archive rows.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 28, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": true,
+  "properties": {
+    "archive": {
+      "description": "Raw USC/ISI archive months (AWS legacy types only), unadjusted.",
+      "items": {
+        "additionalProperties": true,
+        "properties": {
+          "avg": {
+            "type": "number"
+          },
+          "close": {
+            "type": "number"
+          },
+          "date": {
+            "type": "string"
+          },
+          "high": {
+            "type": "number"
+          },
+          "low": {
+            "type": "number"
+          },
+          "open": {
+            "type": "number"
+          }
+        },
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "archive_note": {
+      "description": "Standing of the archive rows.",
+      "type": "string"
+    },
+    "count": {
+      "type": "number"
+    },
+    "instance": {
+      "type": "string"
+    },
+    "months": {
+      "items": {
+        "additionalProperties": true,
+        "properties": {
+          "avg": {
+            "description": "Median of the month's daily averages (or the adjusted archive value), USD per hour.",
+            "type": "number"
+          },
+          "close": {
+            "type": [
+              "number",
+              "null"
+            ]
+          },
+          "date": {
+            "description": "First day of the month.",
+            "type": "string"
+          },
+          "days": {
+            "description": "Days of daily data behind the month; null for uscisi-adjusted months.",
+            "type": [
+              "number",
+              "null"
+            ]
+          },
+          "high": {
+            "type": [
+              "number",
+              "null"
+            ]
+          },
+          "low": {
+            "type": [
+              "number",
+              "null"
+            ]
+          },
+          "open": {
+            "type": [
+              "number",
+              "null"
+            ]
+          },
+          "source": {
+            "description": "Where a row comes from; see `sources` in /catalog for the legend and standing of each.",
+            "type": "string"
+          }
+        },
+        "required": [
+          "date",
+          "avg",
+          "source"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "provider": {
+      "type": "string"
+    },
+    "region": {
+      "type": "string"
+    }
+  },
+  "type": "object"
+}

First observedSep 26, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Annotations already establish readOnly/idempotent/non-destructive, and the description goes well beyond them: it discloses a per-call charge (0.05 USDC), that `archive` is default-on, that archive rows are returned separately 'so it never silently blends into the curated series', and that archive provenance is 'third-party, mixes OS products, partly unverified'. These are exactly the caveats an agent needs before relying on or billing for the result.

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?

Every clause carries information — no filler — and the core purpose is stated early. However, the single dense paragraph with heavily nested parentheses (rollup rules, source attributions, date ranges) is hard to scan and buries the archive caveat mid-sentence rather than structuring it as separate points.

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 paid, read-only history tool with an output schema, the description is complete: it covers cost, the two data series and their provenance, rollup semantics, defaults, and the archive/curated separation. Since an output schema exists it did not need to explain return shape, and it still usefully characterizes what the returned series mean.

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 derived fields (`avg` = median of daily averages, open/close from first/last day, `days`, `source`) and explains that `archive` maps to `include_archive` defaulting on with a specific date span (2014-02 to 2023-12) and type count (51). That is value beyond the schema's terse boolean description.

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 with scope: 'Full monthly history for one instance type, back to 2014 for legacy AWS types.' The monthly granularity plus the explicit statement of what `months` and `archive` contain makes it distinguishable from siblings like spot_daily, spot_hourly, and spot_latest without opening any schema.

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?

Usage is only implied by the granularity ('monthly history'), which lets an agent infer this is the monthly-resolution sibling, but no alternative is ever named (spot_daily, spot_hourly, spot_latest are never referenced) and no when-not-to-use condition is given. The cost note ('Paid, 0.05 USDC per call') is useful context for choosing whether to call, but it is not routing guidance.

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

All corpusAI Cloud Pricing 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.