aimharder-mcp

Overview Schema Source Related Servers Discussions Admin

prepare_booking_creation

Read-only

Prepares one exact class booking by reading the daily schedule without writing; requires a confirmed gym zone, class name, date, and start/end times.

Instructions

Read the current daily schedule and prepare one exact class booking. Requires a user-confirmed gym IANA zone and exact class name, date, start and end time. Ambiguous, missing, already booked, waitlisted or unsupported targets receive no reference. Preparation sends no write. Read writeConfirmationRequired from preparation. Account context exposes separate bookingCreation and activityPublication settings in writeConfirmationPolicy; cancellation and deletion always require confirmation. When true, show the exact preview and obtain separate account-holder confirmation before execution with confirmed: true. When false, an explicit request for this exact action is sufficient; omit confirmed and do not ask for another confirmation. A query or preview-only request never authorizes execution.

Input Schema

Name	Required	Description	Default
`date`	Yes
`gymId`	No
`endTime`	Yes
`className`	Yes
`startTime`	Yes

Output Schema

Name	Required	Description	Default
`gym`	Yes
`action`	Yes
`status`	Yes
`target`	Yes
`notices`	Yes
`expiresAt`	No
`alternatives`	Yes
`currentState`	No
`actionReference`	No
`writeConfirmationRequired`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv0.5.3Oct 30, 2026

addedOutput schema / properties / writeConfirmationRequired
```
Added value: +{
+  "type": "boolean"
+}
```

changedOutput schema / required

Previous value: -[
-  "action",
-  "status",
-  "gym",
-  "target",
-  "alternatives",
-  "notices"
-]New value: +[
+  "writeConfirmationRequired",
+  "action",
+  "status",
+  "gym",
+  "target",
+  "alternatives",
+  "notices"
+]

Changed1 schema field changedv0.5.0Oct 15, 2026

removedOutput schema / properties / credit

Removed value: -{
-  "additionalProperties": false,
-  "properties": {
-    "balance": {
-      "type": "null"
-    },
-    "entitlementPeriod": {
-      "type": "null"
-    },
-    "possibleUse": {
-      "type": "string"
-    }
-  },
-  "required": [
-    "possibleUse",
-    "balance",
-    "entitlementPeriod"
-  ],
-  "type": "object"
-}

Addedv0.2.0Sep 26, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Annotations already declare readOnlyHint and destructiveHint=false, but the description adds substantial context: preparation performs no write, failed/ambiguous targets return no reference rather than raising, and the confirmation obligation is conditioned on the bookingCreation policy. No contradiction with the annotations; the idempotentHint=false is not troubled by anything said.

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 core scoping and no-write constraint is front-loaded, and the density is mostly justified by the confirmation branching. The writeConfirmationPolicy sentences are dense with internal field names and take a second pass to parse, which costs some readability.

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?

An output schema exists, so return values need not be described, and the confirmation workflow is fully documented. The one gap is the optional gymId parameter and whether the 'user-confirmed gym IANA zone' is supplied by the caller or read from account context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description carries the whole burden. It adds real meaning for four of the five parameters (exact class name, date, start and end time must match the schedule), but leaves gymId unexplained, including whether it is derived from account context or must be supplied explicitly.

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+resource: read the daily schedule and prepare exactly one class booking, explicitly excluding writes ('Preparation sends no write'). This cleanly separates it from execute_booking_creation and from the query siblings like get_class_sessions.

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 preconditions (user-confirmed gym IANA zone, exact class name/date/start/end) and explicit no-op cases (ambiguous, missing, already booked, waitlisted, unsupported targets receive no reference). It also spells out the confirmation branch via writeConfirmationRequired in writeConfirmationPolicy and states that a query or preview-only request never authorizes execution.

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

Deploy Server