New Runtime public records

Read the New Runtime forecast ledger

get_forecasts

Read-onlyIdempotent

Use when you need falsifiable predictions about AI engineering with a track record: New Runtime's dated forecasts (claim, probability, due date, source analysis) and the public scorecard (hit rate, Brier score); resolved ones carry the grade and evidence. Free, no auth. Example: {"status": "open", "limit": 10}.

Input Schema

Name	Required	Description	Default
`limit`	No
`status`	No		all

Output Schema

Name	Required	Description
`count`	Yes	Forecasts in the ledger.
`items`	Yes	Forecasts.
`routes`	No	HTML, JSON and Markdown routes of the ledger.
`matched`	No	Forecasts matching the filter.
`returned`	No	Forecasts returned.
`scorecard`	No	Resolved and graded counts, hit rate and Brier score (null until graded).
`generated_at`	No	When the ledger was generated.
`schema_version`	No	Response schema version.
`counts_by_status`	No	Counts for open, confirmed, refuted, unclear.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 27, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "count": {
+      "description": "Forecasts in the ledger.",
+      "type": "number"
+    },
+    "counts_by_status": {
+      "description": "Counts for open, confirmed, refuted, unclear.",
+      "properties": {},
+      "type": "object"
+    },
+    "generated_at": {
+      "description": "When the ledger was generated."
+    },
+    "items": {
+      "description": "Forecasts.",
+      "items": {
+        "properties": {
+          "claim": {
+            "description": "The dated claim."
+          },
+          "due_on": {
+            "description": "Resolution date."
+          },
+          "id": {
+            "description": "Forecast id."
+          },
+          "made_on": {
+            "description": "Date made."
+          },
+          "origin_url": {
+            "description": "Record the forecast came from."
+          },
+          "probability": {
+            "description": "Probability given when made."
+          },
+          "signpost": {
+            "description": "What would resolve it."
+          },
+          "status": {
+            "description": "open | confirmed | refuted | unclear."
+          }
+        },
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "matched": {
+      "description": "Forecasts matching the filter.",
+      "type": "number"
+    },
+    "returned": {
+      "description": "Forecasts returned.",
+      "type": "number"
+    },
+    "routes": {
+      "description": "HTML, JSON and Markdown routes of the ledger.",
+      "properties": {},
+      "type": "object"
+    },
+    "schema_version": {
+      "description": "Response schema version."
+    },
+    "scorecard": {
+      "description": "Resolved and graded counts, hit rate and Brier score (null until graded).",
+      "properties": {},
+      "type": "object"
+    }
+  },
+  "required": [
+    "count",
+    "items"
+  ],
+  "type": "object"
+}

AddedSep 26, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already cover read-only, idempotent, non-destructive behavior. The description adds useful context beyond them: free access with no auth, what the ledger contains, and that resolved forecasts carry grades and evidence. It does not discuss pagination or rate behavior, so a 4 is appropriate.

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?

The usage condition is front-loaded and every clause carries useful information. The first sentence is long and dense, but the example and free/no-auth note are efficient and do not waste space.

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 two-parameter read-only tool with an output schema, the description is complete enough to call correctly. It explains the forecast content, status distinction, access model, and provides an example invocation.

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 0%, so the description should compensate. It provides an example using status and limit, and mentions resolved forecasts, but it does not explain the meaning of status=all, the limit maximum, or default behavior, leaving meaningful parameter semantics to the schema constraints.

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 states a specific verb and resource: reading New Runtime's dated forecast ledger and public scorecard. It explains the forecast contents (claim, probability, due date, source analysis) and distinguishes this from all sibling tools, none of which deal with forecasts.

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 usage context: use when you need falsifiable predictions about AI engineering with a track record. The free/no-auth note is helpful, but there are no explicit exclusions or named alternatives, though no sibling is directly comparable.

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

All New Runtime public records tools Inspect

Try in Browser

Context All Your Agents Can ShareAgents share what they learn, hand off work, and hold it when you switch models. Start with 5 GB free.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?