Skip to main content
Glama

Nolio

List metrics

list_metrics
Read-only

The metrics available to one person (yours by default, an athlete's when athlete is passed), including Nolio metrics hidden from their personal display: definitions only, not values. Each entry carries id (mti_…), key, unit and is_wb_compatible. Its values are on metrics/values/ with item=<id> via nolio_api_read, except an entry with a non-null computation: it is aggregated from workouts and never stored, read it on metrics/computed/ with item=<id>. metrics/records/ is another world, the best efforts held over a duration or a distance (power profile, best 10 km pace). A metric of yours missing from an athlete's list is not enrolled yet: write its value for them anyway (metrics/values/ with athlete), the first value enrolls them, unless it is aggregated from workouts (a count, sum or average over sessions), which is refused. A %-metric workout target cites the key (e.g. "FTP") of an entry with is_wb_compatible true; the athlete does not need a value yet, the target resolves once they have one. Check unit fits how the sport is targeted (a W metric on a pace-based run is usually a mismatch). A catalogue runs to hundreds of entries: pass q when you look for one.

Input Schema

NameRequiredDescriptionDefault
qNoKeeps the metrics whose key contains this text (accents, spaces and case ignored): "vma" finds VMA.
athleteNoAthlete public id (usr_…). Omit for your own metrics.
is_wb_compatibleNotrue: only metrics a %-metric workout target can cite; false: only the others. Omit for all.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Beyond readOnlyHint and destructiveHint=false, the description discloses non-obvious behavior: Nolio metrics are included even when hidden from display, entries expose only definitions, computed metrics are never stored, and writing a value enrolls an athlete except for workout-aggregated metrics. These are substantive operational details rather than restatements of annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The content is dense and almost every sentence carries useful information, but it is presented as one long, run-on block with many nested clauses. It is not front-loaded into scannable guidance, making it harder to digest 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 still explains the return shape (`id`, `key`, `unit`, `is_wb_compatible`) and routes the agent to the correct endpoint for values or computed data. It also covers unit suitability and enrollment constraints, so the tool is sufficiently explained for correct use.

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 already 100%, but the description adds workflow meaning: `athlete` selects another person's catalogue and drives the enrollment behavior, `is_wb_compatible` relates to %-metric targets, and `q` is recommended because catalogues run to hundreds. It does not restate syntax details, but it adds enough practical context 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?

The description opens with a precise verb and resource: it lists the metrics available to a person, explicitly definitions only rather than values. It immediately distinguishes this tool from related value, computed, and records endpoints, so an agent can identify it without inspecting the schema.

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 gives explicit routing rules: values live on metrics/values/, computed metrics on metrics/computed/, and records on metrics/records/. It also explains when to pass `q` and how athlete enrollment affects missing metrics, leaving little to inference.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources