Skip to main content
Glama

sindy_run

Read-onlyIdempotent

Sparse Identification of Nonlinear Dynamics (SINDy).

Recovers governing differential equations (dx/dt = f(x)) from time
series data. Returns human-readable sparse expressions. Fast (seconds).
For algebraic y = f(x) relationships without time structure, use
pysr_run instead.

Pricing: free tier up to 100 rows and 8 variables. Beyond that,
$0.05 + $0.01 per 100 extra rows + $0.01 per extra variable squared,
via x402 (USDC on Base) or MPP/Stripe. MPP/Stripe adds a flat $0.35
per-transaction fee (Stripe processing), so the MPP challenge amount
in a `payment_required` response is $0.35 higher than the x402 amount
for the same base price; x402 gets the lower rate. Omit `payment`
for free-tier requests; paid requests without a valid credential
receive a `payment_required` result with pricing and accepted schemes.
Full pricing table as structured JSON: occam://pricing

Advisory limits: jobs over 500,000 rows or 50 variables are accepted
but may not converge within the time budget; the response carries a
top-level `warning` the agent should surface and treat as tentative.

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

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

Response (success) includes `equations[]` (each with `variable`,
`equation`, `expression`, `expression_latex`, `r2`), `library_terms`,
`nonzero_terms`, `elapsed_seconds`, `canonical_match` (dict with
`system`, `form`, `variable_map`, `parameter_map`, `confidence` if
the discovered system matches one of Lorenz / Lotka-Volterra /
Van der Pol / Duffing; `null` otherwise), optional `warning`,
optional `_meta` (MPP receipt on paid calls). Full response and
payment-required schemas: occam://tool-schemas

Example request:
  data=[[1.0, 0.0], [0.95, -0.31], [0.81, -0.59]], t=[0.0, 0.1, 0.2],
  feature_names=["x", "y"], poly_degree=2, threshold=0.1

Policy: occam://privacy-policy — Citation: occam://citation-info

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
tYesTimestamps corresponding to each row of data. Length must match row count.
dataYes2D array of time series data. Each row is a timestep, each column is a state variable. Free tier: 100 rows, 8 variables. Paid tier: up to 500,000 rows, 50 variables.
paymentNoPayment credential. Accepts either a JSON object or a JSON-encoded string (FastMCP's transport pre-parses strings whose field annotation is non-bare-`str` into objects, so the object form is canonical; the string form is accepted for legacy callers). Required when the dataset exceeds the free tier (100 rows, 8 variables). Omit for free-tier requests. For x402: {"transaction":"0x...","network":"...","priceToken":"..."}. For MPP/Stripe: {"challenge":{...},"payload":"..."}. For prepaid API key: {"scheme":"prepaid","api_key":"occ_live_...","request_id":"<optional uuid>"}.
max_iterNoMaximum STLSQ optimizer iterations. Default 20.
thresholdNoSTLSQ sparsity threshold. Higher values produce sparser equations. Default 0.1.
poly_degreeNoPolynomial library degree for SINDy candidate functions. Default 2.
feature_namesNoNames for each variable/feature column. Defaults to x0, x1, ...

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
warningNo
equationsNo
library_termsNo
nonzero_termsNo
canonical_matchNo
elapsed_secondsNo

TDQS

A4.8/5.0
Behavior5/5

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

Beyond the annotations (readOnlyHint, idempotentHint), the description discloses significant behavioral traits: convergence warnings for large jobs, feature_names validation, pricing responses, canonical_match behavior, and rate limits. This adds rich context beyond what annotations provide, with no contradictions.

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, starting with the core purpose and then providing necessary operational details. Every sentence contributes useful information, though the pricing and rate limit details could potentially be condensed or linked out, making it slightly verbose.

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 (payment, rate limits, response schemas), the description is remarkably complete. It covers purpose, differentiation, pricing, limitations, validation, examples, and points to detailed schemas and policies, leaving little ambiguous for the agent.

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?

The schema already has 100% coverage for parameters, so the baseline is 3. The description adds extra value by explaining the feature_names length validation, an example request, and free-tier row/variable limits that directly relate to parameter usage, elevating it above baseline.

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 clearly states the tool's function: 'Recovers governing differential equations (dx/dt = f(x)) from time series data.' It also distinguishes from siblings by explicitly directing users to pysr_run for algebraic relationships without time structure, which is a specific verb+resource statement.

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 provides when-to-use context: 'For algebraic y = f(x) relationships without time structure, use pysr_run instead.' Additionally, it gives clear guidance on free tier limits, payment requirements, and rate limits, which are crucial for correct usage.

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.

TDQS

A4.7/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose: feature_request handles capability requests, pysr_run does algebraic symbolic regression, sindy_run handles differential equation discovery, and pysr_uncertainty provides bootstrap confidence intervals for pysr results. The descriptions explicitly cross-reference each other to prevent confusion.

Naming Consistency4/5

The compute tools follow a consistent 'method_run' pattern (pysr_run, sindy_run), and pysr_uncertainty shares the pysr prefix. feature_request deviates from this pattern but is a distinctly different kind of tool, so the naming is largely predictable with only minor inconsistency.

Tool Count5/5

Four tools is a well-scoped set for a symbolic regression server. Each tool fills a necessary role: two core methods, one uncertainty analysis follow-up, and one feedback channel. No redundancy or bloat.

Completeness4/5

The domain covers algebraic regression, dynamical system identification, and post-hoc uncertainty quantification for pysr. A minor gap is the lack of a sindy_uncertainty tool, but the feature_request mechanism compensates for missing capabilities, and the core workflows are fully supported.

Resources