Skip to main content
Glama

get-workout-events

Sync workout updates efficiently by retrieving a paged list of events since a specified date. Enables clients to update local workout caches without fetching full datasets.

Instructions

Retrieve a paged list of workout events (updates or deletes) since a given date. Events are ordered from newest to oldest. The intention is to allow clients to keep their local cache of workouts up to date without having to fetch the entire list of workouts.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pageNo
pageSizeNo
sinceNo1970-01-01T00:00:00Z

Implementation Reference

  • Handler function that executes the 'get-workout-events' tool logic: validates inputs, calls hevyClient.getWorkoutEvents(page, pageSize, since), processes events, and returns JSON or empty response.
    withErrorHandling(async ({ page, pageSize, since }) => {
    	if (!hevyClient) {
    		throw new Error(
    			"API client not initialized. Please provide HEVY_API_KEY.",
    		);
    	}
    	const data = await hevyClient.getWorkoutEvents({
    		page,
    		pageSize,
    		since,
    	});
    
    	const events = data?.events || [];
    
    	if (events.length === 0) {
    		return createEmptyResponse(
    			`No workout events found for the specified parameters since ${since}`,
    		);
    	}
    
    	return createJsonResponse(events);
    }, "get-workout-events"),
  • Zod input schema for the tool defining parameters: page (int >=1 default 1), pageSize (int 1-10 default 5), since (string default '1970-01-01T00:00:00Z').
    {
    	page: z.coerce.number().int().gte(1).default(1),
    	pageSize: z.coerce.number().int().gte(1).lte(10).default(5),
    	since: z.string().default("1970-01-01T00:00:00Z"),
    },
  • MCP server.tool registration for 'get-workout-events' including name, description, input schema, and wrapped handler.
    server.tool(
    	"get-workout-events",
    	"Retrieve a paged list of workout events (updates or deletes) since a given date. Events are ordered from newest to oldest. The intention is to allow clients to keep their local cache of workouts up to date without having to fetch the entire list of workouts.",
    	{
    		page: z.coerce.number().int().gte(1).default(1),
    		pageSize: z.coerce.number().int().gte(1).lte(10).default(5),
    		since: z.string().default("1970-01-01T00:00:00Z"),
    	},
    	withErrorHandling(async ({ page, pageSize, since }) => {
    		if (!hevyClient) {
    			throw new Error(
    				"API client not initialized. Please provide HEVY_API_KEY.",
    			);
    		}
    		const data = await hevyClient.getWorkoutEvents({
    			page,
    			pageSize,
    			since,
    		});
    
    		const events = data?.events || [];
    
    		if (events.length === 0) {
    			return createEmptyResponse(
    				`No workout events found for the specified parameters since ${since}`,
    			);
    		}
    
    		return createJsonResponse(events);
    	}, "get-workout-events"),
    );
  • src/index.ts:40-40 (registration)
    Top-level call to registerWorkoutTools(server, hevyClient) which registers the 'get-workout-events' tool among others.
    registerWorkoutTools(server, hevyClient);
Behavior4/5

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

With no annotations provided, the description carries full burden and adds valuable behavioral context: it discloses pagination ('paged list'), ordering ('newest to oldest'), and the tool's intended use case for cache synchronization. It doesn't mention rate limits or authentication needs, but covers core operational behavior well.

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?

The description is efficiently structured in two sentences: the first explains what the tool does and its parameters, the second states the use case. Every sentence adds value with zero redundant information, making it easy to parse.

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

Completeness4/5

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

For a read-only tool with no output schema and 0% schema coverage, the description provides strong context about purpose, usage, and behavior. It could mention response format or error handling, but covers the essential aspects well given the tool's complexity and annotation 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 compensates by explaining the 'since' parameter's purpose ('since a given date') and implying pagination through 'paged list.' It doesn't detail 'page' and 'pageSize' explicitly, but provides enough context to understand the tool's filtering and pagination behavior.

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 clearly states the tool's purpose with specific verbs ('retrieve a paged list of workout events') and resources ('workout events (updates or deletes) since a given date'). It distinguishes itself from siblings like 'get-workouts' by focusing on events for cache synchronization rather than fetching complete workout data.

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?

The description explicitly states when to use this tool: 'to allow clients to keep their local cache of workouts up to date without having to fetch the entire list of workouts.' This provides clear context and distinguishes it from alternatives like 'get-workouts' for bulk retrieval.

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

Related 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/chrisdoc/hevy-mcp'

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