Skip to main content
Glama

weekly_report

Generate a 7-day health report with weight and body fat trends, workouts, diet, and step counts for the week ending on a selected date.

Instructions

近 7 天周报:体重/体脂趋势、运动、饮食、步数。

Input Schema

NameRequiredDescriptionDefault
week_endNoYYYY-MM-DD 或带时区 ISO8601(转 UTC 取日期),默认今天(UTC);窗口为该日及之前共 7 个 UTC 日

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.3.2

TDQS

B3.2/5.0
Behavior3/5

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

No annotations are provided, so the description carries the full behavioral burden. It discloses the report's content categories (trends, exercise, diet, steps), which is genuine value beyond the schema, but says nothing about read-only safety, whether data freshness/sync matters, or result format. Partial coverage for an unannotated tool.

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 compact sentence that front-loads the scope ('近 7 天') before the content list. Nothing is wasted, though the extreme terseness leaves no room for routing or behavioral cues that the tool would benefit from.

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?

With no output schema and no annotations, the description should carry more of the return-value and safety load. It lists the data domains covered, which partially substitutes for an output schema, but omits output shape, freshness/sync dependencies, and any read-only framing. Minimally adequate for a single-parameter report tool.

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 100%, and the sole parameter week_end is fully documented in the schema, including the YYYY-MM-DD/ISO8601 handling and the UTC window definition. The description adds nothing about week_end, so baseline 3 is appropriate.

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 states a concrete resource and scope: a 7-day report covering weight/body-fat trends, exercise, diet, and steps. This is clearly distinct from raw-data siblings like query_samples or log_workout, though it never names or contrasts them explicitly. Purpose is clear but sibling differentiation is left to inference.

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?

There is no guidance on when to use this tool versus alternatives such as query_samples (raw samples) or log_workout/log_meal (individual entries). The '近 7 天' scope implies a summary use case, but no when/when-not conditions or prerequisites (e.g. data must be synced first) are stated.

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