Slim Chance

Slim Chance: is my weight really moving?

slim_chance

Read-onlyIdempotent

Use when someone shares dated scale readings, or asks whether their weight loss (or gain) is really working, has stalled, or is just water. Turns dated morning scale readings into an honest trend: where the weight really is under the daily water noise, the rate per week with its 95% range, and the chance in 10 that it is truly moving the way the person wants. It reads the last 5 weeks up to the latest reading; it describes the recent past, it is not a forecast. Needs at least 7 readings in those 5 weeks for a verdict; with fewer it says how many more mornings it needs. Only send what the person shared and asked about. Nothing you send is stored.

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": {
      "weigh_ins": "<weigh_ins>"
    },
    "name": "slim_chance"
  }
}

Input Schema

Name	Required	Description
`goal`	No	Which way the person wants the weight to go. Default lose.
`unit`	No	Unit of the weights, and of the answer. Default kg.
`weigh_ins`	Yes	Morning scale readings, any order, one per day (a later reading for the same date replaces an earlier one).
`goal_weight`	No	Optional target weight, same unit: adds "at this pace, about N weeks".

Output Schema

Name	Required	Description
`unit`	Yes
`as_of`	Yes
`state`	Yes
`trend`	No
`chance`	No
`rate_range`	No
`scale_noise`	No
`chance_in_10`	No
`rate_per_week`	No	Positive = losing.
`readings_used`	Yes
`weeks_to_goal`	No
`more_mornings_needed`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 10, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely new behavior: it looks only at the last 5 weeks up to the latest reading, it degrades gracefully below 7 readings by reporting how many more mornings are needed, and it states nothing is stored. Those are exactly the operational facts an agent needs before calling.

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 trigger condition is front-loaded in the first clause, and the remaining sentences move efficiently from output content to data window to minimum-data behavior to privacy. It is dense but not padded; the only mild redundancy is restating the 5-week window alongside the 7-reading minimum.

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 single-read statistical tool with a full schema, complete annotations and an output schema, nothing material is missing. The description covers inputs, data window, minimum-data fallback, output meaning, and the fact that no state is retained, so an agent can call it correctly without further inference.

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 100%, so the baseline is 3 and the schema already documents goal, unit, goal_weight and the date/weight shape. The description still adds meaning the schema lacks: the effective minimum of 7 readings inside a 5-week window (the schema only says minItems 1) and the fact that goal_weight produces an 'at this pace, about N weeks' projection.

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 names a specific transformation (dated morning scale readings → trend) and enumerates exactly what the output contains: the de-noised weight, rate per week with a 95% range, and a chance-in-10 that it is truly moving. That is far more specific than the title, and no agent could confuse this with a generic body-metrics tool.

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?

It opens with an explicit trigger ('Use when someone shares dated scale readings, or asks whether their weight loss... is really working, has stalled, or is just water') and states the data prerequisite of at least 7 readings within 5 weeks. It also draws a boundary ('describes the recent past, it is not a forecast') and a scope limit ('Only send what the person shared and asked about'). It does not name a when-not-to-use case or point to an alternative tool, which keeps it short of a 5.

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

All Slim Chance 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.