Using Endufueler tools

1. Gather facts before calculating

Ask for missing athlete and event facts, expected duration, conditions, fueling experience, logistics, and caffeine intent. Do not invent an athlete profile, consent, or confirmed course support. Request only the information needed for the calculation; do not ask for medical records or account secrets.

A client’s dataConsent input is an assertion required by the calculation contract. It is not evidence that a person gave legal consent or reviewed a plan. Explain the data flow and obtain the required user input before calculating with Endufueler.

2. Search, select, then preview

Search products with Endufueler for current catalog information. Review the returned serving sizes, units, nutrition, and identifiers with the user. Pass the returned catalogVersion as expectedCatalogVersion with selected product IDs when calculating. Unknown nutrition values remain unknown; do not substitute zero.

If the catalog or selection becomes stale, search again and review the replacement selection. Recalculate when duration, products, conditions, logistics, or other scenario facts change. Do not silently reuse an old result as a new calculation.

3. Explain the complete result

Describe actions in plain product language: ‘calculate with Endufueler,’ ‘search products,’ ‘read your saved plans,’ or ‘save your approved plan.’ Keep technical action names for developer questions and diagnostics, rather than normal conversation.

Before a successful Endufueler calculation, label any assistant-generated estimate clearly: ‘This is a preliminary estimate. I haven’t calculated it with Endufueler yet.’ Only attribute a result to Endufueler after a successful response. If a calculation or account action fails, explain what could not be completed and the next step; do not present a guessed result as a successful Endufueler result.

Keep fueling targets, planned intake, and estimated losses separate. A target is not proof of consumption or a measured loss. Preserve warnings, assumptions, shortages, units, and the distinction between known and estimated values.

Unknown course water or fuel supply is unconfirmed. Do not turn an aid-station possibility into available inventory. An unknown caffeine total does not establish remaining caffeine headroom; known caffeine amounts are only the known portion.

Preserve each product’s waterRequirement and recommendedWithWaterMl guidance, including required, recommended, and unknown values. Unknown does not mean no water is needed; do not invent a millilitre amount. Confirm the water source, container capacity, and mixing or refill logistics before claiming the plan can be carried out. A product needing no extra water does not remove the athlete’s baseline hydration needs.

For triathlon, preserve the swim, transitions, bike, and run phases and their constraints. Keep bike and run inventory and support separate. Do not move a product or refill between disciplines unless the supplied logistics explicitly permit it. Present the result as an estimate to review and practice in training.

4. Connect only for personal tools

Product search and calculations work without an Endufueler account when MCP is enabled. Reading your saved plans requires OAuth with plans:read and returns only the connected owner’s plans. Preparing and saving a reviewed plan require plans:write. Say that you read a saved plan only after its account request succeeds.

Use the client’s OAuth flow. Never ask the user to paste passwords, API keys, access tokens, or tunnel runtime keys into chat. A browser login cookie does not authorize personal MCP calls. Account consent grants scopes; it does not approve a particular draft.

5. Prepare → browser review → commit

Prepare a draft with the complete input. Return its reviewUrl to the user and explain that it created a private expiring draft, not a saved plan. The owner must open Endufueler, inspect the complete result, and explicitly approve that exact draft. Never follow the approval flow or assert approval on the user’s behalf.

After the owner approves, save the approved plan using the returned previewToken. Share only the provided reviewUrl; do not expose previewToken separately or construct additional URLs. Only saved:true confirms a successful save; then say ‘Your plan was saved in Endufueler.’ A prepared draft or browser approval alone does not confirm saving. An unapproved, expired, stale, or conflicting draft must not be presented as saved. Reviews expire after 15 minutes.

For an update, first read the saved plan. Pass its exact revision as expectedRevision and the plan ID as targetPlanId when preparing; include the same targetPlanId when saving. If another edit intervenes, read the latest plan and prepare a fresh draft for browser review.

6. Handle retries and limits honestly

Explain errors by the action the user requested, such as ‘Endufueler could not calculate this plan’ or ‘I couldn’t read your saved plans.’ Preserve returned validation issues, uncertainty, and retry hints; keep error codes and field paths available for diagnostics. Ask for missing facts rather than omitting safety information or claiming that a partial result is complete. Do not offer account administration, plan deletion, or library management through these tools.

If a save response is missing or ambiguous, say ‘I couldn’t confirm that your plan was saved.’ Do not assert that it succeeded or definitely did not save. Use the original save’s supported retry/receipt flow rather than creating another plan to guess what happened.

Retrying an already successful commit with the same token returns its original receipt during the 30-day retry window. That receipt is historical confirmation of the commit, not proof the plan still exists or has not changed. After the window ends, read the saved plan rather than recreating a save automatically.