Blocks

create_event

Create an event the athlete is preparing for (race, key ride, FTP test) on their Blocks calendar. Use when the athlete describes one in chat. Requires name + date (YYYY-MM-DD). Optional: description, location, map/event-page URLs, logistics notes, prep (coach) notes, priority, target and local start time (picks the forecast hours). The GPX route is added by the athlete in the app. Event-day weather is fetched automatically when within ~16 days. Returns the new event id (pass it to set_event_notes to add detailed prep).

Input Schema

Name	Required	Description
`date`	Yes
`name`	Yes	event name, e.g. 'Gravel Fondo 120'
`notes`	No	athlete logistics (parking, number pickup…)
`sport`	No	what the event is: the plan builds toward it and the Course tab reads only a bike event in watts; unset = guessed from the name
`mapUrl`	No
`result`	No	what came of it, their words, e.g. '3rd AG, 83:40'
`target`	No	their aim, e.g. 'sub-40'
`purpose`	No	why they race it: result (a win, a finish, a time — say which in target), training (it replaces a session, no taper), fun (purely for the joy); '' clears. Ask them once if unknown
`eventUrl`	No	official race / registration page
`priority`	No	A = season goal, B/C = on the way, '' clears
`startTime`	No	local start time HH:MM
`coachNotes`	No	prep notes (fueling, pacing, taper)
`description`	No
`locationText`	No	town / venue — also used to fetch weather

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedNov 2, 2026

changedInput schema / properties / sport / description

Previous value: -"what the race is (the Course tab reads a run without watts); unset = guessed from the name"New value: +"what the event is: the plan builds toward it and the Course tab reads only a bike event in watts; unset = guessed from the name"

changedInput schema / properties / sport / enum

Previous value: -[
-  "ride",
-  "run"
-]New value: +[
+  "ride",
+  "gravel",
+  "mtb",
+  "cx",
+  "tt",
+  "run",
+  "trail",
+  "triathlon",
+  "duathlon",
+  "swim",
+  "hyrox",
+  "ski",
+  "other"
+]

Changed3 schema fields changedOct 30, 2026

changedInput schema / properties / purpose / description

Previous value: -"why they race it: place (a position), time (a time or watts — say it in target), finish (to finish and enjoy it), training (a hard session, no taper); '' clears. Ask them once if unknown"New value: +"why they race it: result (a win, a finish, a time — say which in target), training (it replaces a session, no taper), fun (purely for the joy); '' clears. Ask them once if unknown"

changedInput schema / properties / purpose / enum

Previous value: -[
-  "place",
-  "time",
-  "finish",
-  "training",
-  ""
-]New value: +[
+  "result",
+  "training",
+  "fun",
+  ""
+]

addedInput schema / properties / result

Added value: +{
+  "description": "what came of it, their words, e.g. '3rd AG, 83:40'",
+  "maxLength": 200,
+  "type": "string"
+}

Changed1 schema field changedOct 30, 2026

addedInput schema / properties / purpose

Added value: +{
+  "description": "why they race it: place (a position), time (a time or watts — say it in target), finish (to finish and enjoy it), training (a hard session, no taper); '' clears. Ask them once if unknown",
+  "enum": [
+    "place",
+    "time",
+    "finish",
+    "training",
+    ""
+  ],
+  "type": "string"
+}

Changed1 schema field changedOct 29, 2026

addedInput schema / properties / sport

Added value: +{
+  "description": "what the race is (the Course tab reads a run without watts); unset = guessed from the name",
+  "enum": [
+    "ride",
+    "run"
+  ],
+  "type": "string"
+}

Changed1 schema field changedSep 27, 2026

addedInput schema / properties / startTime

Added value: +{
+  "description": "local start time HH:MM",
+  "pattern": "^([01]\\d|2[0-3]):[0-5]\\d$",
+  "type": "string"
+}

Changed2 schema fields changedSep 26, 2026

addedInput schema / properties / priority

Added value: +{
+  "description": "A = season goal, B/C = on the way, '' clears",
+  "enum": [
+    "A",
+    "B",
+    "C",
+    ""
+  ],
+  "type": "string"
+}

addedInput schema / properties / target

Added value: +{
+  "description": "their aim, e.g. 'sub-40'",
+  "maxLength": 200,
+  "type": "string"
+}

First observedSep 24, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Goes well beyond the annotations: disclosures that event-day weather is auto-fetched within ~16 days, that GPX cannot be supplied here, and that the tool returns a new event id used by set_event_notes. Lacks any mention of permission/ownership requirements or duplicate-event behavior, so not quite a 5.

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?

Front-loaded with purpose and trigger, then required fields, then optional groups, then side effects and return value — a sensible priority order. The parenthetical enumeration is dense but each clause carries information; only the mid-sentence detail drop about which fields are optional could be tightened.

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 14-parameter create tool with no output schema, it covers the essentials: required fields, the return value, automatic weather behavior, and where the GPX step lives. It leaves the athlete-facing intent fields (sport, purpose, priority semantics) to the schema, which documents them well.

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?

At 79% schema coverage the baseline is 3, and the description earns above that by grouping the optional fields and explaining non-obvious effects ('local start time (picks the forecast hours)'). It omits sport, result, and purpose entirely, relying on the schema's own descriptions for those.

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?

Specific verb + resource + concrete scope: 'Create an event the athlete is preparing for (race, key ride, FTP test) on their Blocks calendar.' The examples and the 'athlete's calendar' framing make it immediately separable from list_events, update_event, and delete_event.

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

Usage Guidelines4/5

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

Gives a clear trigger ('Use when the athlete describes one in chat') and routes a follow-on need explicitly ('pass it to set_event_notes to add detailed prep'). It also pre-empts a foreseeable misuse by stating the GPX route is added in the app, though it never explicitly says to use update_event for existing events.

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

All Blocks 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.

Resources

Need Help?