oddsky

lens_fit

Fit gravitational microlensing light curves across multiple series at once, with optional annual parallax, to estimate t0, tE, u0, peak magnification, and parallax model improvement.

Instructions

Fit a gravitational microlensing event: a point source magnified by a point lens, without and (by default) with annual parallax, to one or more series at once (e.g. ["ATLAS:ATLAS_o", "ATLAS:ATLAS_c", "NEOWISE:W1"]). Each series is binned per night and turned into flux / its own baseline (median outside [start, end], or over the baseline window). Errors include that series' baseline night-to-night scatter and 1% of flux. Returns t0, tE, u0, A_max (and piE, fs), 95% ranges for t0 and tE from chi-square profiles (not covariance), how well the peak and wings are sampled, and how much the parallax model improves on the static one. A static fit much worse than the parallax fit means the light curve is asymmetric; a peak with no points means t0 and A_max rest on the wings. Microlensing is achromatic: fit the bands together and compare their residuals.

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": {
      "case": "<case>",
      "series": "<series>",
      "start": "<start>",
      "end": "<end>"
    },
    "name": "lens_fit"
  }
}

Input Schema

Name	Required	Description	Default
`end`	Yes
`case`	Yes
`blend`	No
`start`	Yes
`series`	Yes
`parallax`	No
`baseline_end`	No
`baseline_start`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.3.1Nov 12, 2026

TDQS

A3.9/5.0

Behavior4/5

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

With no annotations, the description carries the full disclosure load and does it well: it explains defaults (parallax on, blend off), the binning-per-night preprocessing, the baseline definition (median outside [start, end] or over the baseline window), the error model (night-to-night scatter plus 1% of flux), and what the returned parameters and chi-square profile ranges mean. It stops short of stating failure modes (too few points, non-convergence) or runtime cost, which keeps it from a 5.

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 text is dense but front-loaded: model and scope come first, then preprocessing and error model, then return values, then interpretation caveats. Nearly every sentence carries information, though the return-list and interpretation sentences are compressed to the point of needing a careful re-read.

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

Completeness4/5

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

For an eight-parameter scientific fitting tool with no annotations and no output schema, the description supplies the model, the data pipeline, the error treatment, and the interpretation of diagnostics (asymmetric light curve, unsampled peak). The unexplained 'case' and 'blend' parameters are the main remaining gap; the return values are already covered in prose.

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 0%, so the description must supply all parameter meaning. It covers series (with a concrete list example), start/end and the baseline window, and the parallax default, but 'case' is never mentioned and 'blend' is only hinted at via the returned fs — leaving two of eight parameters unexplained.

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 opening states a specific verb and resource ('Fit a gravitational microlensing event: a point source magnified by a point lens'), names the model variants (static vs annual parallax) and the input shape (a list of series such as ATLAS:ATLAS_o). This is clearly separable from siblings like periodogram, fold, or eclipse_period.

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

Usage Guidelines3/5

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

The description implies when the tool applies through domain guidance ('Microlensing is achromatic: fit the bands together and compare their residuals'), which steers the agent away from fitting bands individually. However, it never states explicit when-to-use/when-not conditions or names an alternative sibling for cases where a different model (e.g. binary lens, periodicity search) is appropriate.

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