Skip to main content
Glama

add_exercise

Add exercises to workouts in the MCP Logger fitness tracking system. Specify workout ID, exercise name, optional category, and notes for comprehensive workout logging.

Instructions

Add an exercise to an existing workout.

Args: workout_id: ID of the workout to add exercise to name: Name of the exercise category: Optional category (e.g., 'Squat', 'Push', 'Pull') notes: Optional notes about the exercise

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
workout_idYes
nameYes
categoryNo
notesNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Implementation Reference

  • The `add_exercise` tool is implemented in `src/main.py` using a FastMCP decorator. It takes a `workout_id`, `name`, and optional `category` and `notes`, and inserts a new exercise record into the database with an auto-incrementing `order_index`.
    def add_exercise(
        workout_id: int,
        name: str,
        category: Optional[str] = None,
        notes: Optional[str] = None,
    ) -> dict[str, int]:
        """Add an exercise to an existing workout.
        
        Args:
            workout_id: ID of the workout to add exercise to
            name: Name of the exercise
            category: Optional category (e.g., 'Squat', 'Push', 'Pull')
            notes: Optional notes about the exercise
        """
        conn = get_connection()
        cursor = conn.cursor()
        
        # Get current max order_index
        cursor.execute("SELECT COALESCE(MAX(order_index), 0) FROM exercises WHERE workout_id = ?", (workout_id,))
        max_order = cursor.fetchone()[0]
        
        cursor.execute(
            "INSERT INTO exercises (workout_id, order_index, name, category, notes) VALUES (?, ?, ?, ?, ?)",
            (workout_id, max_order + 1, name, category, notes),
        )
        exercise_id = cursor.lastrowid
        conn.commit()
        conn.close()
        return {"exercise_id": exercise_id}
Behavior2/5

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

With no annotations provided, the description carries full burden for behavioral disclosure. While 'Add an exercise' implies a write/mutation operation, it doesn't address important behavioral aspects like: whether this requires specific permissions, if the operation is idempotent, what happens on duplicate exercises, or what the response format looks like. The description provides only basic functional information without behavioral context.

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 description is efficiently structured with a clear purpose statement followed by parameter explanations. The 'Args:' section organizes parameter information cleanly. While concise, the initial purpose statement could be slightly more informative about the tool's scope or constraints.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a mutation tool with no annotations, 4 parameters (2 required), and 0% schema description coverage, the description provides adequate functional information but lacks important context. The presence of an output schema reduces the need to describe return values, but behavioral aspects like error conditions, permissions, and idempotency remain undocumented. It's minimally viable but has clear gaps.

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?

With 0% schema description coverage, the description provides essential parameter semantics that aren't in the schema. It explains what each parameter represents (workout ID, exercise name, optional category with examples, optional notes) and which are required versus optional. This significantly compensates for the schema's lack of descriptions, though it doesn't provide format details like what constitutes a valid workout_id.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Add an exercise') and target resource ('to an existing workout'), making the purpose immediately understandable. However, it doesn't differentiate this tool from potential sibling tools like 'add_set' or 'log_workout' that might also involve workout modifications.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. With sibling tools like 'add_set', 'log_workout', and 'get_exercise_history' available, there's no indication of when this specific exercise-adding function is appropriate versus other workout-related operations.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/JohnZolton/MCP-logger'

If you have feedback or need assistance with the MCP directory API, please join our Discord server