Skip to main content
Glama
Sign In
garminconnect-js

garminconnect-js

by DynamicsNinja
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

quick_add_food

Log nutrition by name and macros to Garmin Connect without selecting a specific food. Requires Connect+; record calories, carbs, protein, and fat for a meal and date.

Instructions

Requires a Garmin Connect+ subscription (check with has_connect_plus). Logs an entry by name and macros ("Quick Add"). Needs Connect+. PUTs /nutrition-service/food/logs/quickAdd: an entry by name + calories/carbs/protein/fat with no food behind it (QUICK_ADD). Same meal rules as logFood.

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": {
      "input": "<input>"
    },
    "name": "quick_add_food"
  }
}

Input Schema

NameRequiredDescriptionDefault
inputYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.1/5.0
Behavior4/5

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

Annotations cover the safety profile (readOnlyHint=false, destructiveHint=false, openWorldHint=true), and the description adds genuinely useful behavior: a subscription gate, the PUT endpoint shape, the QUICK_ADD entry type, and that meal-selection rules are inherited from logFood. It does not say what happens on a duplicate entry or how the created entry is identified.

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-loaded with the blocking prerequisite, then the payload and endpoint. Every clause carries information, though 'Needs Connect+' repeats the opening subscription sentence almost verbatim and could be cut.

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?

For a nested-object mutation with no output schema, the description supplies the prerequisite, endpoint, entry type, and a pointer to logFood's meal rules. The remaining gap is that macro units/scale are never stated, which matters for a nutrition-logging call.

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 coverage is reported at 0% and five of six required fields (name, calories, carbs, protein, fat) have no schema descriptions. The description partially compensates by enumerating exactly those macro fields and stating they carry no backing food, but it gives no units for the macros or semantics for the required `input` wrapper.

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 ('Logs an entry by name and macros') and explicitly names the differentiator from its closest sibling: the entry has 'no food behind it (QUICK_ADD)', unlike log_food. An agent can distinguish this from log_food and create_custom_food without opening a schema.

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?

Names the prerequisite (Connect+ subscription, with the concrete check via has_connect_plus) and points to the contrast case by describing the no-backing-food scenario. It never explicitly says 'use log_food when the food exists', so the alternative routing is implied rather than stated.

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