Occam

pysr_uncertainty

Read-only

Bootstrap confidence intervals for the numeric constants of a frozen expression, plus optional prediction bands on an x-grid.

Typical flow: call pysr_run, pick an expression from the response
(best_expression or a pareto_front entry), pass it back here with
the same dataset to get CIs on its fit constants.

Returns frequentist bootstrap confidence intervals, not Bayesian
credible intervals — posterior inference over expression structures
is an open research problem. This tool freezes the expression
chosen by the caller and bootstraps only its numeric constants;
uncertainty about *which* expression is correct is not quantified.

Bootstrap semantics:
  - If y_sigma is supplied, uses parametric bootstrap
    (y_b = y + Normal(0, y_sigma)). CI reflects user-stated
    measurement noise.
  - Otherwise uses residual bootstrap: fit once, resample residuals.
    CI reflects estimated-from-residuals noise.

Only Float constants in the expression become free parameters.
Integers stay structural (the 2 in x**2 is a function-class choice,
not a fit constant). Expressions with no Float constants
(e.g. "x + y") will be rejected with a validation error.

Expression grammar: the `expression` string is parsed by sympy.
Accepted operators are the same set pysr_run emits: unary `sin`,
`cos`, `tan`, `exp`, `log`, `log2`, `log10`, `sqrt`, `abs`, `sinh`,
`cosh`, `tanh`; binary `+`, `-`, `*`, `/`, `^` (or `**`). Whitespace
and parenthesization are free. Every free symbol in the expression
must correspond to an entry in `feature_names` — an unrecognised
symbol is silently treated as a fresh sympy Symbol and the fit will
fail downstream rather than reject early. Parse failures (syntax
errors, malformed operators) surface as tool errors.

If `feature_names` is supplied, its length must equal the number of
columns in `X`; a mismatch is rejected with a validation error.

Pricing: always free, regardless of dataset size. This tool has no
`payment` parameter and is never subject to the x402/Stripe gate.
Large bootstrap jobs still count against the shared rate limit
below, so budget `n_resamples` accordingly.

Rate limit: 10 requests/hour per IP, 200/hour global, max queue
depth 20 (shared with sindy_run and pysr_run).

Input Schema

TableJSON Schema

Name	Required	Description
`X`	Yes	2D array of input features. Each row is an observation, each column is a feature. Minimum 5 rows. Free tier: 100 rows, 8 features. Paid tier: up to 50,000 rows, 20 features.
`y`	Yes	Target values, one per row of X.
`alpha`	No	Significance level. 0.05 → 95%% CI. Default 0.05.
`x_grid`	No	Optional 2D grid of feature values at which to report a prediction band. Must have the same number of columns as X. Omit to skip prediction-band computation.
`y_sigma`	No	Optional per-point measurement standard deviations, or a single scalar applied to all points. When supplied, the helper uses parametric bootstrap (y_b = y + Normal(0, y_sigma)); otherwise it uses residual bootstrap. Supplying y_sigma also improves the initial weighted fit.
`expression`	Yes	The expression to bootstrap, as returned by pysr_run (`best_expression` or a `pareto_front[i].expression`). Only numeric Float constants are treated as free parameters — integers in the expression (e.g. the 2 in x**2) stay structural.
`n_resamples`	No	Number of bootstrap resamples. Higher = tighter CIs, more compute. Default 100.
`feature_names`	No	Names for each variable/feature column. Defaults to x0, x1, ...

Output Schema

TableJSON Schema

Name	Required	Description	Default
`note`	Yes
`alpha`	Yes
`coefficients`	Yes
`prediction_ci`	No
`bootstrap_method`	Yes
`n_requested_resamples`	Yes
`n_successful_resamples`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed6 schema fields changedSep 24, 2026

changedInput schema / properties / X / description

Previous value: -"2D array of input features. Each row is an observation, each column is a feature. Free tier: 100 rows, 8 features. Paid tier: up to 50,000 rows, 20 features."New value: +"2D array of input features. Each row is an observation, each column is a feature. Minimum 5 rows. Free tier: 100 rows, 8 features. Paid tier: up to 50,000 rows, 20 features."

addedInput schema / properties / X / examples

Added value: +[
+  [
+    [
+      0
+    ],
+    [
+      1
+    ],
+    [
+      2
+    ],
+    [
+      3
+    ],
+    [
+      4
+    ]
+  ]
+]

addedInput schema / properties / X / minItems
```
Added value: +5
```
addedInput schema / properties / expression / examples
```
Added value: +[
+  "2.0*x0 + 1.0"
+]
```

addedInput schema / properties / y / examples

Added value: +[
+  [
+    1.02,
+    2.97,
+    5.01,
+    7.03,
+    8.98
+  ]
+]

addedInput schema / properties / y / minItems
```
Added value: +5
```

Changed1 schema field changedApr 20, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$defs": {
+    "UncertaintyCoefficient": {
+      "additionalProperties": true,
+      "properties": {
+        "ci": {
+          "maxItems": 2,
+          "minItems": 2,
+          "prefixItems": [
+            {
+              "type": "number"
+            },
+            {
+              "type": "number"
+            }
+          ],
+          "title": "Ci",
+          "type": "array"
+        },
+        "estimate": {
+          "title": "Estimate",
+          "type": "number"
+        },
+        "initial": {
+          "title": "Initial",
+          "type": "number"
+        },
+        "name": {
+          "title": "Name",
+          "type": "string"
+        }
+      },
+      "required": [
+        "name",
+        "initial",
+        "estimate",
+        "ci"
+      ],
+      "title": "UncertaintyCoefficient",
+      "type": "object"
+    },
+    "UncertaintyPredictionPoint": {
+      "additionalProperties": true,
+      "properties": {
+        "ci": {
+          "maxItems": 2,
+          "minItems": 2,
+          "prefixItems": [
+            {
+              "type": "number"
+            },
+            {
+              "type": "number"
+            }
+          ],
+          "title": "Ci",
+          "type": "array"
+        },
+        "estimate": {
+          "title": "Estimate",
+          "type": "number"
+        },
+        "x": {
+          "items": {
+            "type": "number"
+          },
+          "title": "X",
+          "type": "array"
+        }
+      },
+      "required": [
+        "x",
+        "estimate",
+        "ci"
+      ],
+      "title": "UncertaintyPredictionPoint",
+      "type": "object"
+    }
+  },
+  "additionalProperties": true,
+  "description": "Always a success shape — pysr_uncertainty is never paid.",
+  "properties": {
+    "alpha": {
+      "title": "Alpha",
+      "type": "number"
+    },
+    "bootstrap_method": {
+      "title": "Bootstrap Method",
+      "type": "string"
+    },
+    "coefficients": {
+      "items": {
+        "$ref": "#/$defs/UncertaintyCoefficient"
+      },
+      "title": "Coefficients",
+      "type": "array"
+    },
+    "n_requested_resamples": {
+      "title": "N Requested Resamples",
+      "type": "integer"
+    },
+    "n_successful_resamples": {
+      "title": "N Successful Resamples",
+      "type": "integer"
+    },
+    "note": {
+      "title": "Note",
+      "type": "string"
+    },
+    "prediction_ci": {
+      "anyOf": [
+        {
+          "items": {
+            "$ref": "#/$defs/UncertaintyPredictionPoint"
+          },
+          "type": "array"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "default": null,
+      "title": "Prediction Ci"
+    }
+  },
+  "required": [
+    "coefficients",
+    "n_requested_resamples",
+    "n_successful_resamples",
+    "bootstrap_method",
+    "alpha",
+    "note"
+  ],
+  "title": "PySRUncertaintyResult",
+  "type": "object"
+}

AddedApr 15, 2026

TDQS

A4.7/5.0

Behavior5/5

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

The description goes far beyond the readOnlyHint annotation. It discloses the parametric vs. residual bootstrap semantics, the rule that only Float constants become free parameters, validation errors for expressions without Float constants, the silent treatment of unrecognized symbols as fresh sympy Symbols, pricing, rate limits, and the absence of a payment gate. This is rich behavioral context with no contradiction to the annotations.

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 description is long but well-structured with clear sections and bullet points. It front-loads the core purpose and typical flow before diving into semantics. Some content, like the full operator grammar and rate-limit figures, could arguably live elsewhere, but it is dense and useful. It earns points for organization but loses a little for overall length.

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?

Given the tool's complexity, an output schema exists, and the description covers all non-obvious aspects: bootstrap method selection, expression grammar, constant typing, validation failures, rate limits, and pricing. An agent has enough context to invoke the tool correctly and anticipate failure modes without needing to inspect the output schema.

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?

Although schema coverage is 100%, the description adds substantial meaning beyond the schema. It explains that y_sigma switches between parametric and residual bootstrap, that integers in the expression are structural while Floats are free parameters, that feature_names must match X columns, and that x_grid controls prediction bands. This materially improves an agent's ability to set parameters correctly.

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 opens with a specific verb and resource: 'Bootstrap confidence intervals for the numeric constants of a frozen expression, plus optional prediction bands on an x-grid.' It clearly distinguishes this from pysr_run by emphasizing that the expression is frozen and only its numeric constants are bootstrapped. The purpose is immediately identifiable and not confused with sibling tools.

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?

The 'Typical flow' section gives explicit guidance: call pysr_run, select an expression, pass it back with the same dataset. It also states what this tool does not do — posterior/Bayesian inference over expression structures — which helps an agent avoid misuse. However, it stops short of explicitly naming alternatives or stating exact conditions for when a sibling tool would be preferable, so it is clear but not fully exhaustive.

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

All Occam 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.

Resources

Need Help?