Public API does not support `input_modifier` field — rep ranges created via MCP appear blank in app

[iliassk]

Hi 👋

I'm using the MCP tools (create-routine, update-routine) to programmatically build routines with rep ranges. After creating them, I noticed that rep ranges don't display in the Hevy app — I see blank REPS columns instead of
the REP RANGE column, even though rep_range values are correctly set on each set.

Root Cause

After investigating, I found that the public API rejects the input_modifier field:

PUT /v1/routines/{id}
Body: { "routine": { "exercises": [{ "input_modifier": "rep-range", ... }] } }

Response:

{"error": "\"routine.exercises[0].input_modifier\" is not allowed"}

I intercepted the Hevy web app's requests via DevTools and discovered that the internal API (PUT /routine/{id}) uses an input_modifier: "rep-range" field on each exercise to toggle between REPS and REP RANGE display modes. Without
it, the app defaults to REPS mode and my rep range values are invisible.

Impact

Any routine created through the MCP tools that uses rep ranges will appear to have blank rep fields in the app. The data is stored correctly server-side, but the UI won't render it because input_modifier was never set. I had to go
back and patch all 20 of my routines via the internal API to fix this.

Expected Behavior

Ideally one of:

1. The public API accepts input_modifier: "rep-range" on exercises
2. The API automatically infers input_modifier: "rep-range" when rep_range is set on any set
3. The MCP tool handles this transparently

Workaround

I'm currently working around this by using the internal Hevy web API directly via curl after creating routines through MCP:

Some other differences I noticed between the internal and public API formats:

• Internal uses indicator instead of type for set types (warmup/normal/failure/dropset)
• Internal requires index on each set
• Internal auth uses Bearer session token + x-api-key: shelobs_hevy_web

Steps to Reproduce

1. Create a routine via the MCP create-routine tool with sets that have rep_range values
2. Open the routine in the Hevy app
3. Observe that the REPS column is shown (not REP RANGE) and values appear blank
4. Edit the same routine from the Hevy web UI, add input_modifier: "rep-range" via the internal API
5. Observe that rep ranges now display correctly

[coderabbitai]

⚠️ Possible Duplicate Issue(s)

• Support rep range in "create" and "update" workouts #108

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[chrisdoc]

@CharlieHelps check this out

[charliecreates]

Expand this to see my work.

• Re-read issue #261 and the new @CharlieHelps comment to confirm there are still no concrete code changes, errors, or open questions tied to specific files like server.ts or mcp.json that I can address yet.
• Scanned openapi-spec.json and src/utils/formatters.ts for rep_range/repRange usage to understand how routine set rep ranges are modeled and transformed for the client.
• Reviewed src/tools/routines.ts to see how the create-routine and update-routine tools map repRange in the tool schema through buildRepRange into the Hevy API’s rep_range field on PostRoutinesRequestSet and PutRoutinesRequestSet.
• Verified that the Zod schemas (zOptionalRepRange, zNullableInt) in src/tools/routines.ts already allow nullable/optional repRange fields on sets, and that reps are nulled when a rep_range is present, matching the OpenAPI contract.
• Confirmed via openapi-spec.json that PostRoutinesRequestExercise does not expose any input_modifier field, and inspected src/utils/response-formatter.ts (createJsonResponse, createTextResponse, createEmptyResponse) to decide how to surface a clear warning in MCP tool output when a user asks for features like input_modifier that the API doesn’t expose.
• Updated src/tools/routines.ts to add repRangeDisplayWarningText and thread a usesRepRanges flag through both create-routine and update-routine so that createJsonResponse returns an extra text item warning that rep_range is stored but may not display in Hevy apps due to the missing input_modifier, with a link back to issue #261.
• Added and strengthened tests in src/tools/routines.test.ts so create-routine and update-routine both assert that when repRange is provided the JSON payload matches formatRoutine(routine) and the second response.content entry contains both "rep ranges" and "issues/261".
• Refactored usesRepRanges tracking in create-routine and update-routine in src/tools/routines.ts to compute the flag from mapped PostRoutinesRequestSet/PutRoutinesRequestSet arrays (via sets.some((set) => set.rep_range !== null)) instead of mutating inside the map callback, improving clarity and matching review feedback on the ai-261-public-api-does-not-support-input-modifier- branch.
• Ran pnpm run check, pnpm vitest run --exclude 'tests/integration/**', and pnpm run check:types to confirm Biome formatting, unit tests (aside from the expected HEVY_API_KEY-not-initialized error tests), and TypeScript types all pass after the refactor and new update-routine warning test.
• Pushed the ai-261-public-api-does-not-support-input-modifier- branch (git push origin ai-261-public-api-does-not-support-input-modifier-) and verified via git status --porcelain that the working tree is clean, ready to reference these src/tools/routines.ts and src/tools/routines.test.ts changes in a reply to the new comment on issue #261.

[charliecreates]

#261 (comment)

Put up a small mitigation PR: #266. Since the public API won’t accept the internal input_modifier field, we can’t make the official apps render rep ranges reliably — but we can surface that limitation at the moment you call create-routine / update-routine with repRange so it’s not a silent “blank reps” surprise.

Changes

• When repRange is provided to create-routine or update-routine, the tool response now appends a warning as a second content item (keeping the JSON payload first).
• Added unit tests covering the warning behavior for both create + update.

Verification

pnpm run build
pnpm run check
pnpm run check:types
pnpm vitest run --exclude 'tests/integration/**'

• Vitest: 140 tests passed (15 files).
• Integration tests under tests/integration/** are excluded here (they require a real HEVY_API_KEY).