Skip to main content
Glama

Trainzilla Coach MCP

by io.github.Trainzilla
OverviewDiscussionsAdmin

search_exercises

Read-only

Search the exercise catalog by free-text name (e.g. 'barbell squat'). Returns real catalog exercises with an id, sorted by matchConfidence (0-1, fraction of your query's words found on that catalog entry). Call this for each exercise before create_workout_plan. Use the top result's exact id as that exercise's exerciseId and its name as the exercise name only when its matchConfidence is high (roughly 0.7+) — the app resolves the image/video from exerciseId automatically, so a matched exerciseId is what makes the exercise show media in the app. If every result has low matchConfidence, or there are no results at all, don't guess — fall back to a plain name with no exerciseId rather than linking a wrong exercise's image.

Input Schema

NameRequiredDescriptionDefault
limitNo
queryYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • addedInput schema / properties / limit / default
      Added value: +8
    • removedInput schema / properties / limit / description
      Removed value: -"Matches per name (default 4, or 3 per name with queries)."
    • removedInput schema / properties / queries
      Removed value: -{
-  "description": "Several exercise names in one call; returns the top matches for each.",
-  "items": {
-    "minLength": 1,
-    "type": "string"
-  },
-  "maxItems": 30,
-  "type": "array"
-}
    • addedInput schema / required
      Added value: +[
+  "query"
+]
  2. First observed

TDQS

A4.9/5.0
Behavior5/5

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

Annotations only declare readOnlyHint=true, but the description adds real behavioral context: results are real catalog entries with ids, sorted by a defined matchConfidence score (0-1, fraction of query words matched), and a linked exerciseId is what triggers automatic image/video resolution in the app. This goes well beyond the annotation's safety hint.

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

Conciseness5/5

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

Front-loads the core action, then sequences workflow, interpretation of matchConfidence, and the fallback rule. Every sentence is actionable; none merely restate the name or schema.

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 and only a readOnly annotation, the description supplies the return shape (id, name, matchConfidence), how to interpret it, and the safe fallback. An agent has everything needed to call it and use the result without guessing.

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 description coverage is 0%, so the description must carry the load. It explains the required 'query' parameter richly (free-text name, example, and how the query maps to matchConfidence). However, the 'limit' parameter (default 8, max 20) is never mentioned, leaving one of two params undocumented anywhere.

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 ('Search the exercise catalog by free-text name') and gives a concrete example query. It clearly distinguishes itself from the downstream sibling create_workout_plan, which it explicitly says to call this before.

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?

Gives explicit workflow guidance: call once per exercise before create_workout_plan, link the id only when matchConfidence is ~0.7+, and fall back to a plain name with no exerciseId when all results are weak or empty. The when-to-use and when-not-to-link conditions are stated outright.

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

All Trainzilla Coach MCP 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