Skip to main content
Glama
Running Companion MCP Server

Running Companion MCP Server

This server has been deprecated

Personal project, not offered for public use.

Weekly report

get_weekly_report
Read-only

Pulls a Monday-to-Sunday report covering training, recovery, sleep, stress, body trends, and personal bests, defaulting to the last complete week, to support weekly review.

Instructions

The computed report for one Monday-to-Sunday week: a headline, training (volume against the previous four weeks, intensity balance, form), key sessions with planned vs actual, recovery (HRV, resting heart rate, status days, sleep against need, sleep score, bedtime regularity), life (stress, Body Battery), body (weight trend), new personal bests and the signals raised during the week. Lines carry a tone (good, neutral, concern). Start every weekly review from this. Defaults to the last complete week.

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": "get_weekly_report"
  }
}

Input Schema

NameRequiredDescriptionDefault
week_startNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.3.3

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already cover safety (readOnlyHint=true, openWorldHint=false), and the description adds useful behavior beyond them: the report is computed/derived, it defaults to the last complete week when no date is given, and returned lines carry a tone (good, neutral, concern). It does not say whether generation is expensive or cached, but the defaulting and tone semantics are genuine added value.

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?

Purpose is front-loaded in the first clause, and the long parenthetical enumeration of sections is dense but earns its place since there is no output schema. It reads as one overlong sentence-with-list rather than clearly separated purpose/usage sentences, which costs a little scannability.

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, the description does the work of describing return contents in detail, and it covers the default-argument case. Remaining gaps are the Monday-alignment rule for week_start and the meaning of 'signals', but for a single-optional-parameter read tool this is largely complete.

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% – week_start only has a YYYY-MM-DD pattern. The description compensates partially by stating the default (last complete week), which implies the parameter is optional. It never says whether week_start must land on a Monday or how a partial week is handled, which is the key semantic an agent needs here.

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?

States a specific resource with scope: 'the computed report for one Monday-to-Sunday week', then enumerates its sections (training, key sessions, recovery, life, body, personal bests, signals). An agent knows exactly what it gets. However, it never distinguishes itself from the close sibling get_weekly_summary, leaving ambiguity about which weekly artifact to pick.

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?

'Start every weekly review from this' gives an explicit entry-point instruction, and 'Defaults to the last complete week' tells the agent it can call it with no arguments. It stops short of naming when NOT to use it or which sibling to use for a lighter summary, so no real exclusions are provided.

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