Skip to main content
Glama

log_body_metrics

Record body weight and skinfold measurements to track fitness progress. Input date, weight in kg, and skinfold data from sites like abdomen or chest.

Instructions

Log body weight and skinfold measurements.

Args: date: Date in YYYY-MM-DD format body_weight_kg: Body weight in kilograms (optional) skinfolds: Dictionary of skinfold measurements in mm (optional). Can be a single site like {"abdomen": 10} or multiple sites like {"chest": 12, "abdomen": 18, "thigh": 15}. Common sites: abdomen, chest, thigh, tricep, subscapular, suprailiac, midaxillary notes: Optional notes about the measurement

Example: Single belly skinfold: {"abdomen": 10} Multiple sites: {"chest": 12, "abdomen": 18, "thigh": 15}

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dateYes
body_weight_kgNo
skinfoldsNo
notesNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Implementation Reference

  • The 'log_body_metrics' tool handler processes date, weight, skinfold measurements, and notes, saves them to the database, and returns the generated metrics ID.
    def log_body_metrics(
        date: str,
        body_weight_kg: Optional[float] = None,
        skinfolds: Optional[dict[str, float]] = None,
        notes: Optional[str] = None,
    ) -> dict[str, int]:
        """Log body weight and skinfold measurements.
        
        Args:
            date: Date in YYYY-MM-DD format
            body_weight_kg: Body weight in kilograms (optional)
            skinfolds: Dictionary of skinfold measurements in mm (optional).
                       Can be a single site like {"abdomen": 10} or multiple sites
                       like {"chest": 12, "abdomen": 18, "thigh": 15}.
                       Common sites: abdomen, chest, thigh, tricep, subscapular, 
                       suprailiac, midaxillary
            notes: Optional notes about the measurement
        
        Example:
            Single belly skinfold: {"abdomen": 10}
            Multiple sites: {"chest": 12, "abdomen": 18, "thigh": 15}
        """
        date = _ensure_date(date)
        conn = get_connection()
        cursor = conn.cursor()
    
        cursor.execute(
            "INSERT INTO body_metrics (date, body_weight_kg, notes) VALUES (?, ?, ?)",
            (date, body_weight_kg, notes),
        )
        metrics_id = cursor.lastrowid
    
        if skinfolds:
            for site, mm in skinfolds.items():
                cursor.execute(
                    "INSERT INTO skinfolds (body_metrics_id, site_name, mm) VALUES (?, ?, ?)",
                    (metrics_id, site, mm),
                )
    
        conn.commit()
        conn.close()
        return {"body_metrics_id": metrics_id}
Behavior2/5

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

No annotations are provided, so the description carries the full burden. It states the tool logs data, implying a write operation, but doesn't disclose behavioral traits like whether it creates new records, updates existing ones, requires specific permissions, or handles errors. The example clarifies input format but not system behavior.

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?

The description is appropriately sized and front-loaded with the purpose, followed by structured parameter explanations and examples. Every sentence adds value, but it could be slightly more concise by integrating the example more tightly with the parameter descriptions.

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?

Given the tool's moderate complexity (4 parameters, 1 required) and the presence of an output schema (which reduces the need to explain return values), the description is fairly complete. It covers input semantics well but lacks behavioral context and usage guidelines, which are minor gaps given the output schema support.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It effectively adds meaning beyond the schema by detailing each parameter: date format, optional body weight in kg, skinfolds as a dictionary with examples and common sites, and optional notes. This provides clear semantics for all parameters.

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 description clearly states the tool's purpose: 'Log body weight and skinfold measurements.' It specifies the verb ('log') and resources ('body weight and skinfold measurements'), making the action clear. However, it doesn't explicitly differentiate from sibling tools like 'get_body_metrics', which is a read operation, though the distinction is implied by the verb 'log' versus 'get'.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'get_body_metrics' for retrieving data or specify prerequisites such as authentication. Usage is implied by the tool's name and purpose, but explicit context is lacking.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/JohnZolton/MCP-logger'

If you have feedback or need assistance with the MCP directory API, please join our Discord server