TrainRec

Set daily targets

trainrec_set_targets

Sets the daily calorie and macro targets, and optionally a target for any other nutrient (the keys in overview.foodNutrients): a ceiling for the ones to limit, such as sodiumMg, cholesterolMg, sugarG, saturatedFatG or caffeineMg, and an amount to reach for the rest, such as potassiumMg, fiberG or calciumMg. nutrients left out keeps the ones already set; {} clears them.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "kcal": "<kcal>",
      "proteinG": "<proteinG>",
      "carbsG": "<carbsG>",
      "fatG": "<fatG>"
    },
    "name": "trainrec_set_targets"
  }
}

Input Schema

Name	Required	Description	Default
`fatG`	Yes
`kcal`	Yes
`carbsG`	Yes
`proteinG`	Yes
`nutrients`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 12, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Goes well beyond the annotations by disclosing merge semantics ('nutrients left out keeps the ones already set; {} clears them') and the semantic split between ceiling-style and floor-style nutrients, which the caller must know to set values correctly. Annotations only cover the read-only/scope flags; this adds real behavioral context, though nothing is said about persistence or validation errors.

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?

A single dense sentence that front-loads the primary action and then the optional extension; every clause carries information. It is slightly run-on and the merge rules would read better as a separate sentence, but there is no filler.

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?

With no output schema and a nested 20-key object, the description supplies the two things an agent cannot infer: where nutrient keys come from and how partial objects merge or clear. Units and the meaning of the required macro fields are left implicit, which is the main remaining gap.

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?

Schema description coverage is 0% and the nested nutrients object has 20 undocumented keys, so the description usefully identifies the key source (overview.foodNutrients) and illustrates both ceiling (sodiumMg, sugarG) and target (potassiumMg, fiberG) nutrients. However, the four required macro parameters get no explanation and no unit conventions are given, so it only partially compensates for the schema gap.

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 ('Sets the daily calorie and macro targets') plus the optional extension (any other nutrient keyed by overview.foodNutrients). An agent can tell immediately this writes daily nutrition goals rather than food logs or reminders, distinguishing it from log_food and change_settings.

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?

Makes the usage condition for the optional block explicit (only for additional nutrients beyond kcal/macros) and explains partial-update behavior so the caller knows when to send a sparse object. It stops short of naming an alternative tool or a when-not-to-use case, so it stays below a 5.

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

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