whatevr

update_goals

Destructive

Change the user's goal and daily targets — the same settings as the app's Goals screen. Send ONLY the fields to change. Each target takes a number (a custom target) or "auto" (computed from their body, activity and goal). The server keeps calories and macros consistent (protein×4 + carbs×4 + fat×9 ≈ calories), so the targets it returns can differ slightly from what you sent — report the returned ones. Current weight is not here: log a weigh-in with log_weight. Needs the user's "Change goals & settings" switch for this connection (whatevr app → Settings → Connections); if it's off you'll get a message saying so — relay it. The user is notified of every change.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "update_goals"
  }
}

Input Schema

Name	Required	Description
`goal`	No
`fat_target_g`	No	10–250, or "auto".
`activity_level`	No
`calorie_target`	No	1000–5000, or "auto".
`carbs_target_g`	No	20–600, or "auto".
`goal_weight_lb`	No
`fiber_minimum_g`	No
`sugar_maximum_g`	No
`protein_target_g`	No	20–400, or "auto".
`rate_lb_per_week`	No	Pace for lose/gain (ignored for maintain).
`sodium_maximum_mg`	No
`water_goal_glasses`	No

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 26, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations declare a non-readOnly, destructive mutation, and the description adds substantial context beyond them: the server reconciles calories and macros so returned targets can differ from what was sent, the user is notified of every change, and a connection-level permission gate can block the call. Those are exactly the behavioral facts an agent must know before mutating goals.

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-loads the core action and the partial-update rule, then layers in computation behavior, the weight exclusion, and the permission gate in descending priority. Dense but every clause carries operational information; the parenthetical math and the UI breadcrumb are slightly verbose but justified.

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

Completeness5/5

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

There is no output schema, so the description's warning to 'report the returned ones' rather than the sent values fills the return-value gap. Combined with the permission gate and notification behavior, an agent has everything needed to call this correctly for a 12-parameter destructive mutation.

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?

Schema coverage is only 42%, and the description compensates by explaining the two-mode semantics of every target ('a number … or "auto" (computed from their body, activity and goal)') and the macro consistency rule, which is not derivable from the schema. It does not explain goal_weight_lb, fiber/sugar/sodium/water bounds, or rate_lb_per_week beyond what the schema states, so it is not fully compensating.

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 and resource ('Change the user's goal and daily targets') and anchors it to a concrete reference point ('the same settings as the app's Goals screen'), which makes the scope unambiguous. It also carves out what is NOT here (current weight) and names the right sibling for that.

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?

Explicitly instructs 'Send ONLY the fields to change' (partial-update semantics that are easy to get wrong), routes weight changes to log_weight, and documents the prerequisite permission switch plus the exact fallback behavior (relay the error message). This is when/when-not/alternative coverage in three sentences.

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

All whatevr 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?