Skip to main content
Glama
Sign In

Sigwren

by com.sigwren
OverviewDiscussionsAdmin

Work out a fitness test from the watch numbers

work_out_my_test
Read-onlyIdempotent

A fitness test worked out from the numbers the runner read off their watch after doing it (get_fitness_test says which). For each effort: the lap average pace (or speed), for a sprint also the fastest pace, and the average heart rate where there is one. Metabolic Lite also needs body mass, height, age and sex. It returns threshold pace and heart rate where measured, LT1 pace, FatMax, VO₂max, VLamax, economy, glycogen, predicted 5 km, 10 km and half-marathon times where the test gives them, every training zone, and how sure Sigwren is and why. Sigwren never fills a missing number in: a missing effort or body measurement is refused and named. A result from typed numbers is rated no higher than medium; uploading the recording (get_test_upload_link) lets Sigwren measure the efforts itself. Nothing is stored. It needs no account.

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": {
      "test": "<test>",
      "efforts": "<efforts>"
    },
    "name": "work_out_my_test"
  }
}

Input Schema

NameRequiredDescriptionDefault
bodyNoMetabolic Lite only: body mass, height, age and sex. Required there — Sigwren will not guess them.
testYesWhich test: metabolic_lite, threshold_20 or threshold_30 (see get_fitness_test).
unitsNoWhether the paces are per kilometre (the default) or per mile. The answer is in the same units.
effortsYesOne entry per effort, with the numbers the runner read off the watch.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.1/5.0
Behavior5/5

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

Beyond the readOnly/idempotent annotations, it discloses meaningful behavior: Sigwren never fills in a missing number and will refuse and name the missing effort or body measurement, typed-input results are capped at medium confidence, nothing is stored, and no account is needed. It also describes the confidence/explanation component of the response.

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?

It is front-loaded with the core action and requirement, and nearly every sentence carries useful information about inputs, outputs, or failure behavior. It is dense and slightly long-winded in the return-value enumeration, but no sentence is pure filler.

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?

With no output schema, the description carries the full burden of describing returns, and it does so thoroughly (all derived metrics plus confidence and rationale). It also covers the refusal behavior for missing data, so an agent has everything needed to call it correctly.

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 100%, so per the baseline this is a 3. The description adds a little conditional meaning (sprint efforts also need max pace, Metabolic Lite needs body fields, HR is optional where no reading exists), but mostly mirrors what the schema already documents.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: it computes fitness-test results from watch readings, and it enumerates the outputs (threshold pace/HR, LT1, FatMax, VO₂max, VLamax, economy, glycogen, race predictions, zones). It points to get_fitness_test for which test to run, distinguishing it from that sibling, though it leaves get_test_result and predict_race_finish undifferentiated.

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 tells the agent which test selector to consult (get_fitness_test), what inputs each effort needs, and offers an explicit alternative path: typed numbers cap confidence at medium, whereas uploading via get_test_upload_link lets Sigwren measure efforts itself. It gives clear context but no explicit when-not-to-use statement.

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

All Sigwren toolsInspect
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