Skip to main content
Glama

Create new estimate

estimate

Cost: spends quota. Anonymous callers get 3 free tier-1 estimates per UTC day (anon_simple_estimate_daily_limit). With an account it debits credit_cost_for_tier(tier) credits (tier 1/2/3 = 1/3/10), and credits_charged in the response reports the amount.

Return a calibrated probability distribution for a natural-language question.

Args:
    question: The natural-language question (e.g. "What will the price of
        Bitcoin be in 6 months?").
    unit: The unit the answer should be expressed in (e.g. "USD", "people",
        "meters").
    target_horizon: When the estimate applies (e.g. "6 months", "2030",
        "current").
    disclaimer_acknowledged: Must be true. Confirms you understand estimates
        are probabilistic decision-support only, not financial/medical/legal
        advice.
    requested_tier_id: Tier (1=fast sync, 2=grounded sync, 3=deep research
        async). Default 1.
    context: Optional extra context to condition the estimate.
    coverage_probability: Width of the confidence interval (0, 1). Default
        0.9 (90% CI).
    source_inputs: Optional list of structured inputs (files, tables) for
        the model to consider. Each item needs source_type
        ("qualitative_text", "spreadsheet", or "structured_file") and
        either content (text) or structured_data (dict/list).
    callback_url: Optional webhook URL. When set, the completed or failed
        result is POSTed here with an HMAC signature, so you don't need
        to poll for async tiers.
    api_key: Your Fermi API key from POST /api/v1/accounts. Omit to use the
        anonymous tier.
    provider: Optional LLM provider selector ("openai" or "anthropic").
        When omitted the server uses its configured default. Tier 1
        supports both providers; tiers 2-3 currently accept "openai" only.
    model: Optional model id for the selected provider. Must match the
        model configured for (tier_id, provider); omit to accept the
        default.

Returns:
    EstimateSuccessResponse as a dict: estimation_interval, distribution_family,
    distribution_parameters, point_estimate, reasoning_summary, assumptions,
    credits_charged, disclaimer, provider, model, and next_steps.

    Plus a `billing` block saying who this call was billed to and what
    is left: principal ("anonymous" or "account"), auth_source,
    charged_to ("anonymous_quota" or "credits"), credits_charged,
    credit_balance, and anonymous_estimates_remaining_today with the
    UTC instant the anonymous allowance resets. Call `whoami` to read
    the same block without making an estimate.

    next_steps.simulate carries the arguments for handing this estimate to
    neumann: root_node (distribution_type + distribution_params, ready to
    drop into run_simulation's graph.root_nodes) when the family maps
    directly, or solve_args for solve_distribution_parameters when it does
    not; note says which was emitted.

    To combine several estimates into a model with a time axis and get
    percentiles, NPV or payback out, feed them into neumann
    (https://neumann.kromatic.com) as simulation root nodes -- every
    successful estimate carries a next_steps.simulate block with the
    arguments already prepared.

Raises:
    ToolError: if the estimate service rejects the request (bad tier, out of
        credits, unknown provider, missing disclaimer acknowledgement).

Input Schema

NameRequiredDescriptionDefault
unitYes
modelNo
api_keyNo
contextNo
providerNo
questionYes
callback_urlNo
source_inputsNo
target_horizonYes
requested_tier_idNo
coverage_probabilityNo
disclaimer_acknowledgedYes

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Far beyond what the annotations cover (readOnlyHint=false, openWorldHint=true): it discloses quota spend, anonymous 3/day tier-1 limit, per-tier credit cost (1/3/10), a forced disclaimer acknowledgement, async behavior with HMAC-signed webhooks, and the exact ToolError causes (bad tier, out of credits, unknown provider, missing disclaimer). No contradiction with annotations — the call is a metered, non-idempotent write-ish operation as declared.

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?

Mostly front-loaded — the cost/quota warning comes first, which is defensible for a metered tool — but the purpose sentence is pushed to the second block rather than leading. There is mild redundancy: the neumann / next_steps.simulate hand-off is explained twice, and the Returns section largely restates the existing output schema.

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?

Complete for a 12-parameter, open-world, metered tool: billing behavior, async/webhook path, error modes, auth options (api_key omitted = anonymous) and the downstream hand-off are all covered, so an agent can invoke it correctly on the first attempt.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% and there are 12 parameters, so the description carries the full burden and does so: each argument gets meaning plus examples (unit 'USD', target_horizon '6 months'), tier semantics, the source_inputs item shape (source_type enum values plus content/structured_data), provider/tier compatibility (tiers 2-3 are openai-only), and the coverage_probability default rationale. Nothing material is left undocumented.

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 artifact: 'Return a calibrated probability distribution for a natural-language question', with a title confirming it creates an estimate. This is clearly distinguishable from get_estimate (retrieval), whoami (account read) and buy_credits (billing) in the sibling list.

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?

Gives concrete selection guidance: tier 1 is fast sync, tier 2 grounded sync, tier 3 deep research async; callback_url removes the need to poll async tiers; whoami reads the same billing block 'without making an estimate'; and neumann should be used when combining multiple estimates. It lacks an explicit 'do not call this when X' exclusion or a direct pointer to get_estimate for retrieval, which keeps it from a 5.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources