nLight.fit sandbox

POST https://nlight.fit/api/sandbox

No account. No token. The same MCP protocol and the same eighteen tool schemas as the production server, answered from a member record that was generated rather than lived.

Why it exists

Signup is open, so an agent evaluating this integration could register. It should not have to, and mostly it should not want to.

An empty account is a bad place to develop against: nearly every interesting tool here answers from months of history, so a brand new record makes the whole surface look like it returns nothing. The alternative — pointing a half-built integration at somebody's real bloodwork — is worse. The sandbox gives you a populated record with no signup, no credential to manage, and no real person's data in the loop while you are still getting the request shapes right.

Everything a client needs in order to decide — the tool catalog, the argument schemas, the response shapes, the error behaviour, the rate-limit conventions — is reachable immediately, at the cost of the data being invented.

Try it

curl -sS https://nlight.fit/api/sandbox \
  -H 'Content-Type: application/json' \
  -H 'Accept: application/json, text/event-stream' \
  -H 'MCP-Protocol-Version: 2026-07-28' \
  -H 'Mcp-Method: tools/list' \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'

Calling a tool:

curl -sS https://nlight.fit/api/sandbox \
  -H 'Content-Type: application/json' \
  -H 'Accept: application/json, text/event-stream' \
  -d '{"jsonrpc":"2.0","id":2,"method":"tools/call",
       "params":{"name":"get_recovery_context","arguments":{"days_back":14}}}'

To connect an MCP client, use https://nlight.fit/api/sandbox as the server URL and leave authentication empty. Client setup covers the per-client configuration; the only difference is that no OAuth step happens.

What is the same as production

• The tool catalog. tools/list returns the same eighteen tools with the same names, descriptions and input schemas. They are read from the production catalog, not copied, so the two cannot drift apart.
• Argument validation. Arguments are checked against the same schemas, so a call the production server would reject is rejected here with the same message.
• The transport. Streamable HTTP, stateless JSON-RPC 2.0 over POST, the same MCP-Protocol-Version negotiation, the same 405 on GET.
• The rate-limit policy. The same quota, reported in the same RateLimit and RateLimit-Policy headers, keyed by source address instead of by member.
• The response envelope. content[].text carrying JSON, isError set the same way.

What is different

• The data is synthetic. Roughly 180 days of a generated ledger across ten metrics and four habits, plus a fixed lab panel, methylation profile, supplement regimen and Mission Statement. It is deterministic — the same request returns the same numbers — and anchored to today, so the most recent day is always yesterday or today.
• Every response says so. Each tool result carries "sandbox": true and a notice field stating in words that the values are generated and belong to no real person. The server instructions delivered at initialize say the same thing, so a model connected to the sandbox is told before it reads a single number.
• The analysis is simpler. Correlations are raw pairwise Pearson over the generated series. The production engine applies partial correlation with covariate controls and Benjamini-Hochberg correction before it will call anything a finding, and assigns a tier accordingly. The sandbox computes its correlations honestly over its own data but claims no tier, and says so in the payload.
• There is no account. get_profile returns a fixed synthetic Mission Statement and constraint list. Nothing is writable and nothing persists. The endpoint never opens a database handle and never resolves a credential, so there is no call by which a sandbox request could reach a real member record.

The synthetic member

Ten continuous metrics — weight, sleep, HRV, resting heart rate, WHOOP recovery and strain, steps, protein, water and mood — and four binary habits: workout, reading, vitamins and no alcohol.

The series are shaped rather than random. There is a weekend dip in the behaviour metrics, a slow downward weight trend, and a recovery score derived from that night's sleep, so the correlation the tools report between sleep and recovery is genuinely present in the data rather than asserted over noise. A client that cross-checks a reported correlation against the raw series it also fetched will find the two agree.

When to stop using it

Switch the URL to https://nlight.fit/api/mcp and add a Bearer token once a member has connected their account. Nothing else in your client changes — that is the property the sandbox exists to give you.

See MCP server for the production endpoint and authentication for how tokens are obtained.