Skip to main content
Glama
Sign In

Sigwren

by com.sigwren
OverviewDiscussionsAdmin

The result of an uploaded test or form check

get_test_result
Read-onlyIdempotent

The result of a fitness test the runner uploaded to a link from get_test_upload_link (or the summary of a free form check from get_form_check_link): for a fitness test, threshold pace and heart rate where measured, LT1 pace, FatMax, VO₂max, VLamax, economy, glycogen and predicted 5 km, 10 km and half-marathon times where the test gives them, every training zone, how sure Sigwren is and why, and what the result rests on. For a form check it returns what they do well, what to work on, the one focus and the cues; the full read is emailed to the runner. If nothing has been uploaded yet it says so; if the file could not be used it says why in plain words; if the link has expired it says that. Pass link (the URL, or its last part). Paces are in the units the runner chose on the upload page. 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": {
      "link": "<link>"
    },
    "name": "get_test_result"
  }
}

Input Schema

NameRequiredDescriptionDefault
linkYesThe link from get_test_upload_link or get_form_check_link (https://sigwren.com/u/…), or just its last part.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / link / description
      Previous value: -"The upload link from get_test_upload_link (https://sigwren.com/u/…), or just its last part."New value: +"The link from get_test_upload_link or get_form_check_link (https://sigwren.com/u/…), or just its last part."
  2. Added

TDQS

A4.2/5.0
Behavior4/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: no account needed, paces rendered in the runner's chosen units, plain-language failure messages for unusable files or expired links, and the fact that the full form-check read is emailed rather than returned.

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 purpose is front-loaded in the first clause and no sentence is filler — the long metric enumeration substitutes for a missing output schema. It is dense and syntactically run-on, with parentheticals and semicolon-chained clauses that make it harder to scan than necessary.

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 return values, and it does so for both branches of the tool. It also covers units, authentication expectations, and the three non-happy-path outcomes, leaving nothing an agent needs in order to call this 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% for the single parameter, and the description's guidance ('Pass link (the URL, or its last part)') restates what the schema already says almost verbatim. Baseline 3 applies; no additional syntax or format detail is offered beyond the schema.

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?

States a specific verb and resource (retrieves the result of an uploaded fitness test or form check) and anchors it to the sibling tools that produce the input, get_test_upload_link and get_form_check_link. It then enumerates the actual returned metrics, so an agent knows exactly what this produces without opening a schema.

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 where the required link comes from and lists the three runtime cases it may hit (nothing uploaded, unusable file, expired link), which is clear contextual guidance for invocation. It does not, however, distinguish this from ambiguous siblings such as get_fitness_test or work_out_my_test, so a routing question remains open.

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