Skip to main content
Glama
RedFoxxo

leap

by RedFoxxo
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

write_settings

Destructive

Update specific app profile settings such as theme, language, or reminders. Only the provided values change; others remain untouched.

Instructions

Change profile settings; only the ones given change. The weight unit is not changed here: switching it converts every stored weight, which the app does. openGym merges settings and the plan one setting and one day at a time: only a device that changes the same setting or day later, before it syncs, keeps its own value.

Input Schema

NameRequiredDescriptionDefault
bodyNoBody map figure
langNoUI language
wdecNoDecimals shown on weights
soundNo
themeNo
accentNoA preset (lime green, sky blue, orange, violet purple, pink, red, teal, gold yellow) or an own colour as #rrggbb; the app nudges an own colour until text on it stays readable
effortNoPer-set effort scale
logRefNo
checkInNo
gifSizeNoSize of exercise animations
restSecNoDefault rest between sets, seconds; 0 turns the rest timer off
vibrateNo
weighInNoAsk for body weight before a workout
exFigureNoWhich figure exercise drawings show
reminderNoDaily "workout planned today" push; merged into the current reminder. Without a time zone it gets this computer's. It needs a device with push notifications on
shareMapNoPut the muscle map on a workout shared as an image
connLocalNoShow the "on this phone only" line
keepAwakeNo
restSoundNoSound at the end of a rest
speedUnitNoCardio speed display; null follows the weight unit
startFromNoPlanned sessions open at the routine's reps (plan) or the last session's (last)
weekStartNoFirst weekday: 1 Monday, 0 Sunday
autoBackupNo
connStatusNoShow the connection line at the top; turning it on also brings back the "on this phone only" line
timerFlashNo
workoutViewNocards, list, compact, or focus (one exercise at a time, nothing else on screen)
exerciseViewNoExercise library and picker layout
oneRmFormulaNoFormula for estimated 1RM; weighted blends all seven and counts reps in reserve
restPauseSecNoRest between rest-pause bursts, seconds
heatmapMetricNo
soundOnSilentNo
showWeightCardNo
vibrateOnSilentNoAndroid: buzz at the end of a rest even when the phone is on silent
timedSetOvertimeNo
collapseCompletedNoList and compact views fold a finished exercise into one line

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.1.0

TDQS

A3.5/5.0
Behavior4/5

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

Beyond the annotations (destructiveHint=true, openWorldHint=true), the description discloses non-obvious merge/conflict semantics: settings sync one field at a time and the last writer before sync wins. That is real behavioral value the annotations do not carry, though it omits auth/permission requirements and response behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The core purpose is front-loaded in the first clause, which is good. But the third sentence ('openGym merges settings and the plan one setting and one day at a time...') is tangled enough to require re-reading, so the structure is only adequate.

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

Completeness3/5

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

For a 35-property mutation with a nested reminder object and no output schema, the description covers the meta-level (partial update, merge conflict) but gives no help navigating the large parameter surface or the nested reminder semantics. Annotations cover safety, so the remaining gap is moderate.

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?

With 35 parameters at 66% schema description coverage, roughly a third of fields are undocumented in both places, and the description supplies no per-parameter detail. It does add one meaningful cross-cutting semantic — any subset of settings may be sent — which lifts it to the mid baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening clause states a specific verb and resource ('Change profile settings') and adds the important partial-update qualifier 'only the ones given change.' It is clearly distinguishable from read_settings by the mutation framing, though it never names the read sibling explicitly.

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

Usage Guidelines3/5

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

It gives implied usage context (partial updates, only supplied fields change) and one exclusion ('The weight unit is not changed here'), which steers the agent away from expecting a weight-unit parameter. However, it never names an alternative tool or states a positive when-to-use condition, so guidance stays implicit.

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

Deploy Server

Other Tools