Skip to main content
Glama
Sign In

Sigwren

by com.sigwren
OverviewDiscussionsAdmin

A page to upload a test recording to

get_test_upload_link
Destructive

A link to a Sigwren page where the runner uploads the recording of their fitness test (the FIT, GPX or TCX file from their watch, of the whole session). Sigwren reads the recording, finds the efforts in it, and works out the result — thresholds, zones and, for Metabolic Lite, VO₂max, VLamax and fat burning. The file is read in memory and never kept; only the result is held until the link expires. Pass test (metabolic_lite, threshold_20 or threshold_30). The link takes one successful upload, and a few tries if the first file cannot be used. Metabolic Lite also asks, on the page, for body mass, height, age and sex, because its model needs them. Afterwards, get_test_result with this link returns the result for the assistant to explain. Each call makes a new link. It needs no account. With the person's "Check with me first" setting on (the default), a call without a confirmation makes no change: it returns a description of the change and a confirmation value, and the change is held for the person to approve. The same call with that confirmation value makes it. With the setting off, the change is made straight away.

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>"
    },
    "name": "get_test_upload_link"
  }
}

Input Schema

NameRequiredDescriptionDefault
testYesWhich test the runner is doing: metabolic_lite, threshold_20 or threshold_30 (see get_fitness_test).
confirmationNoThe confirmation value from an earlier call of this tool with the same arguments, once the person has approved the change it described. Without it, Sigwren describes the change and makes none.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.6/5.0
Behavior5/5

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

Beyond the annotations it discloses that the file is read in memory and never retained, that only the result is held until the link expires, that the link accepts one successful upload with a few retries, that Metabolic Lite collects body mass/height/age/sex on the page, and that each call yields a fresh link. The confirmation-gated approval flow adds concrete context about what a call without confirmation does versus with it, which is far richer than the destructive/non-idempotent hints alone.

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 core purpose is front-loaded in the first clause and each subsequent sentence adds operational detail. It is on the long side and repeats some of the confirmation mechanics already present in the schema's parameter description, which costs a point.

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 correctly explains what comes back (a link) and how to consume it (get_test_result). For a two-parameter mutation tool it covers prerequisites, expiry, upload limits, and the approval workflow, leaving no material gap for a caller.

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 coverage is 100%, so both parameters are already documented with descriptions and the enum-like test values. The description only restates the three test names and explains the confirmation flow in prose, adding little semantics about the parameters that the schema does not already carry; baseline 3 applies.

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 states exactly what the tool produces (a link to an upload page where the runner submits a FIT/GPX/TCX recording) and what the backend then does with it (find efforts, derive thresholds/zones/VO₂max). It is clearly distinguishable from get_test_result and get_fitness_test, both of which it names as adjacent steps.

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 says to pass one of metabolic_lite, threshold_20 or threshold_30, that each call creates a new link, that no account is needed, and that get_test_result should be called afterwards with this link. The approval/confirmation path is also spelled out as an explicit when-to-use condition.

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