AIm Workout Journal

Log workout session

log_session

Destructive

Log a completed workout session (exercises → sets, cardio, wearable metrics) at once. Returns the stored session including any auto-created exercise catalog entries. The response may carry a coach_hint: a server note to gently offer coaching (intake or a program) after confirming the log — offer once, never push. If the conversation is about PLANNING training (not just logging), call get_coaching_context first. If the user ran the workout IN THE AIM APP (it records every set as they train and saves the session itself), it is already stored — do NOT log it again: read it with get_sessions / get_session and discuss or correct it with update_session / update_set. Ask how long the session took (or estimate from set count) and set duration_sec — omitting it renders as an empty duration in the app's history and session views.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`session`	Yes

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 10, 2026

addedInput schema / properties / session / properties / entries / items / properties / sets / items / properties / set_id

Added value: +{
+  "anyOf": [
+    {
+      "maxLength": 128,
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "The client's own stable id for this set, if it has one. Only the AIm app sends this: it lets a later correction be traced to the set that moved, because set_number is renumbered when a set is removed. Never invent one — omit it."
+}

First observedSep 6, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Beyond annotations (readOnly=false, destructive/idempotent hints), the description reveals return behavior including auto-created exercise catalog entries, a coach_hint server note, and the UI consequence of omitting duration_sec. It warns against duplicate logging, which is particularly relevant given destructiveHint=true and idempotentHint=false.

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?

Every sentence earns its place: overview, return behavior, coach_hint, planning alternative, AIm-app exclusion, and duration guidance. It is long because the tool is complex, but it is front-loaded and structured logically.

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?

For a complex nested-parameter creation tool, the description covers the primary use, key exclusions, side effects/returns, and a critical parameter guidance. With a rich output schema and nested parameter documentation, nothing essential for selecting and invoking the tool correctly is missing.

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?

There is only one top-level parameter and the schema has no description on it, but nested properties carry extensive detail. The description compensates by explaining duration_sec must be set and by clarifying what the response contains; it does not need to re-explain the already-detailed nested 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 states a specific action and resource: 'Log a completed workout session (exercises → sets, cardio, wearable metrics) at once.' It also differentiates from siblings by explicitly saying not to log sessions already recorded by the AIm app and to use get_sessions/get_session instead.

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 when-to-use and when-not-to-use guidance: call get_coaching_context first for planning, and do NOT re-log workouts already stored by the AIm app but read/correct via get_session/update_session. It also tells the agent to ask for duration instead of guessing.

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

All AIm Workout Journal tools Inspect

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.