Skip to main content
Glama

Turn a min–max guess into distribution parameters

convert_range_to_distribution
Read-onlyIdempotent

Turns a low-to-high guess, such as "between 80 and 120, 90% sure", into the exact parameters a model input needs. A distribution is the shape of the uncertainty, for example normal (a bell curve), log_normal (skewed and never negative), triangle or uniform. The low and high values are the edges of the range you are that sure of, not hard limits. Use this when you have a rough estimate and need distribution parameters instead of guessing them. Its reverse is convert_distribution_to_range. It returns the distribution type and its parameters, ready to use as a model input's distribution_params. The distribution_type parameter explains which type fits which kind of quantity. Supported types: normal, log_normal, uniform, triangle, beta, gamma, exponential, binomial, discrete_normal, discrete_lognormal, discrete_gamma, constant and bernoulli. Not supported: poisson, categorical, dirichlet, multivariate_normal and constant_array. For beta, give low and high as fractions (2% is 0.02). Cost: free; uses no credits and no free runs.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "distribution_type": "<distribution_type>"
    },
    "name": "convert_range_to_distribution"
  }
}

Input Schema

NameRequiredDescriptionDefault
max_estimateNoThe high end of your range. Required for every type except constant and bernoulli.
min_estimateNoThe low end of your range. Required for every type except constant and bernoulli. Exponential ignores it, but a value must still be sent (any number works).
mode_estimateNoThe most likely value. Required for constant (the fixed value), bernoulli (the chance of success, from 0 to 1) and binomial. For triangle it sets the peak; it must lie strictly between low and high, and defaults to their midpoint. For beta it is used as the peak when a fit allows, but the low and high ends take priority. Ignored by other types.
percentile_rangeNoA single fraction: the share of outcomes that should fall between the low and high ends, which is how sure you are. The default 0.9 means the middle 90%: a 5% chance of being below the low end and 5% above the high end. Mapping hedged words: "very sure" or "almost certainly" is about 0.9; "probably" is about 0.8; if unsure, ask the user. "Could be higher" means pick a right-skewed type such as log_normal, not a wider range.
distribution_typeYesThe distribution to fit. Which to pick: a rate or proportion between 0 and 1 (conversion, churn) → beta, with low and high given as fractions (2% is 0.02). A positive amount that can run high (revenue, price, deal size) → log_normal. A quantity equally likely to land above or below its middle → normal. A value with hard limits you know → uniform (flat) or triangle (most likely value in between). A whole-number count (customers, units) → discrete_normal, discrete_lognormal or discrete_gamma, or binomial for successes out of a fixed number of attempts. Not supported here: poisson, categorical, dirichlet, multivariate_normal and constant_array.

Output Schema

NameRequiredDescriptionDefault
inputYesYour inputs, echoed back.
billingNoWho you are and what this call cost: principal, auth source, credits debited and balance, or the anonymous allowance left today.
parametersYesThe fitted parameters, for example {"mean": 100, "std": 12.2}.
distribution_typeYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed8 schema fields changed
    • removedInput schema / properties / api_key
      Removed value: -{
      -  "anyOf": [
      -    {
      -      "type": "string"
      -    },
      -    {
      -      "type": "null"
      -    }
      -  ],
      -  "default": null,
      -  "description": "Your Neumann API key. Optional: this tool is free either way. Pass it so the billing block in the result shows your account. Get one by creating an account (POST https://neumann.kromatic.com/api/v1/accounts, which returns the key once); setup docs: https://kromatic.com/mcp/neumann.",
      -  "title": "Api Key"
      -}
    • changedOutput schema / $defs / BillingInfo / properties / auth_source / description
      Previous value: -"How you were identified: bearer (a signed-in connection token), api_key (the api_key argument) or anonymous."New value: +"How you were identified: bearer (a credential sent in the Authorization: Bearer header) or anonymous."
    • changedOutput schema / $defs / BillingInfo / properties / auth_source / enum
      Previous value: -[
      -  "bearer",
      -  "api_key",
      -  "anonymous"
      -]New value: +[
      +  "bearer",
      +  "anonymous"
      +]
    • changedOutput schema / $defs / BillingInfo / properties / charged_to / enum
      Previous value: -[
      -  "anonymous_allowance",
      -  "credits",
      -  "none"
      -]New value: +[
      +  "anonymous_allowance",
      +  "free_daily_run",
      +  "credits",
      +  "none"
      +]
    • addedOutput schema / $defs / BillingInfo / properties / free_run_limits
      Added value: +{
      +  "anyOf": [
      +    {
      +      "$ref": "#/$defs/SignedInLimits"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "description": "The free signed-in tier's bounds. Null unless the account signed in with Kromatic."
      +}
    • addedOutput schema / $defs / BillingInfo / properties / free_runs_remaining_today
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "integer"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "description": "Free signed-in runs left in the current UTC day, counting this call. Null unless the account signed in with Kromatic.",
      +  "title": "Free Runs Remaining Today"
      +}
    • addedOutput schema / $defs / BillingInfo / properties / free_runs_reset_at
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "description": "ISO-8601 instant the free signed-in runs next refill (the next UTC midnight). Null unless the account signed in with Kromatic.",
      +  "title": "Free Runs Reset At"
      +}
    • addedOutput schema / $defs / SignedInLimits
      Added value: +{
      +  "description": "The free signed-in tier's bounds (neumann#334), rendered from ``Settings``.",
      +  "properties": {
      +    "max_nodes": {
      +      "description": "Maximum nodes in a free run's graph.",
      +      "title": "Max Nodes",
      +      "type": "integer"
      +    },
      +    "max_trials": {
      +      "description": "Maximum trials in a free run.",
      +      "title": "Max Trials",
      +      "type": "integer"
      +    },
      +    "runs_per_day": {
      +      "description": "Free runs per UTC calendar day.",
      +      "title": "Runs Per Day",
      +      "type": "integer"
      +    }
      +  },
      +  "required": [
      +    "runs_per_day",
      +    "max_trials",
      +    "max_nodes"
      +  ],
      +  "title": "SignedInLimits",
      +  "type": "object"
      +}
  2. Added

TDQS

A4.8/5.0
Behavior5/5

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

Beyond the annotations, the description discloses that the tool is free, uses no credits or free runs, returns the distribution type and parameters, and clarifies that low/high values are confidence-range edges rather than hard limits. It also lists supported and unsupported distribution types, which prevents predictable invocation errors.

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 purpose is front-loaded and the content is organized around use case, distribution choice, return value, and cost. It is somewhat long and repeats supported/unsupported type information already present in the schema, but the added selection guidance is relevant.

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 five-parameter conversion tool with an output schema, the description is complete: it covers purpose, alternatives, type selection, percentile interpretation, supported/unsupported types, return shape, and cost. An agent should be able to select and invoke it correctly without additional context.

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 already 100%, so the baseline is 3. The description still adds useful meaning by reinforcing percentile interpretation, beta fraction formatting, and distribution-type selection, though much of this overlaps with the already rich schema descriptions.

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 transformation verb and resource: turning a low-to-high guess into exact distribution parameters. It distinguishes itself from the reverse sibling by naming convert_distribution_to_range and explains the output is ready for a model input's distribution_params.

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

Usage Guidelines5/5

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

It explicitly says to use this when you have a rough estimate and need distribution parameters instead of guessing them. It also names the reverse tool and gives practical selection guidance, including which distribution types fit which kinds of quantities and how to interpret hedged probability language.

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