Skip to main content
Glama
Sign In
Crawlora MCP

Crawlora MCP

Official
by Crawlora-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

metaculus_question_forecast_history

Retrieve public forecast history points for a Metaculus question using recency-weighted, unweighted, or single aggregation methods.

Instructions

Metaculus question forecast history. Returns public aggregation forecast history points for one Metaculus question. The method enum accepts recency_weighted, unweighted, and single_aggregation.

Input Schema

NameRequiredDescriptionDefault
idYesMetaculus question or post id
methodNoAggregation method
max_pointsNoMaximum history points to return, default 500, max 2000

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.17.5
    • addedInput schema / properties / method / enum
      Added value: +[
+  "recency_weighted",
+  "unweighted",
+  "single_aggregation"
+]
  2. Addedv1.1.0

TDQS

C2.9/5.0
Behavior2/5

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

No annotations are provided, so the description carries full behavioral burden. It conveys only that the data is 'public aggregation' forecast history; there is nothing about pagination, ordering, whether history is bounded by time, or the return shape. For a read tool with no annotations and no output schema, this is a significant gap.

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?

Three short sentences, front-loaded with the core purpose. Efficient overall, though the trailing sentence enumerating enum values is redundant against the schema and does not earn its place fully.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a three-parameter read tool, the description identifies what is returned and notes the aggregation-method options. With no annotations and no output schema, it stops short of describing return ordering, time coverage, or how it relates to the sibling forecast tool, leaving the agent to infer these.

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 the schema already documents id, method, and max_points. The description only repeats the method enum values, which the schema already lists, adding no new meaning or default/latency implications. Baseline 3 applies where the schema does the heavy lifting.

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?

States a concrete verb and resource: 'Returns public aggregation forecast history points for one Metaculus question.' This clearly identifies the operation and scope, but does not differentiate itself from the sibling metaculus_question_forecasts, which an agent might reasonably confuse with a history endpoint.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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

There is no explicit when-to-use, when-not-to-use, or alternative routing. The only guidance is indirect, via the scope of data returned. An agent must infer that this is the time-series variant versus other forecast tools with no stated rule.

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

Deploy Server

Other Tools