Skip to main content
Glama
Packi1992

CalisthenicsCompanion-MCP

by Packi1992

Get Plan Adherence

get_adherence
Read-only

Assess athlete plan adherence for a custom date range and tolerance, reporting planned, matched, missed, and uncertain counts plus an adherence ratio and explanation.

Instructions

Answer "how well does the athlete keep to the plan" over a window and tolerance you choose. Without from/to, the window ends today (the athlete's own calendar day) and spans back windowWeeks (default: the coach's own adherenceWindowWeeks parameter). toleranceDays and windowWeeks override the coach's persisted parameters for this one call only, without saving them. The result reports plannedCount, matchedCount, uncertainCount, missedCount, removedOccurrenceCount, adherenceRatio, the matched pairs (with their confidence and, for similarity-derived matches, the similarity value), the missed occurrences, and an explanation sentence describing what removedOccurrenceCount does and does NOT mean (verbatim: "removedOccurrenceCount counts how many planned occurrences the athlete removed from the calendar inside this window. The stored data carries no timestamp for a removal, so it cannot say whether a given occurrence was cancelled ahead of its date on purpose or cleaned up afterward because it was missed — ask the athlete rather than assuming either reading. A planned occurrence that was removed entirely (its whole recurring series, or its only single date) leaves no trace inside this window at all, and this calculation treats it exactly as if nothing had ever been planned on that day."). Set outputFile: true to write the full pair/missed lists to a local file instead of returning them inline.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
toNo
fromNo
outputFileNo
windowWeeksNo
toleranceDaysNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A4.5/5.0
Behavior5/5

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

Beyond the readOnlyHint annotation, the description discloses that overrides are not saved, that the window uses the athlete's calendar day versus the coach's parameters, that outputFile writes results to a local file instead of returning them inline, and gives an unusually detailed caveat about the limitations of removedOccurrenceCount. This goes well beyond what annotations provide.

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 long but dense, and its structure is logical: purpose first, then defaults, overrides, return fields, and the outputFile option. The verbatim caveat sentence is heavy, but it earns its place given that no output schema exists to communicate the subtle meaning of removedOccurrenceCount.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description fully equips an agent to invoke the tool correctly: all five parameters are explained, defaults are specified, side effects are stated, and the return payload is enumerated in detail, including a nuanced interpretive caveat. There is no output schema, so this rich description is necessary and sufficient.

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?

With schema description coverage at 0%, the description carries the full burden for parameter meaning. It explains the role of from/to, windowWeeks, toleranceDays, and outputFile, including defaults and override behavior. Every parameter in the schema is accounted for with meaningful, non-tautological semantics.

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 opens by explicitly framing the tool as answering 'how well does the athlete keep to the plan' over a chosen window and tolerance, which is a clear verb-plus-resource statement. It is distinct from common sibling tools like get_stats or get_progress, though it does not name any sibling or draw an explicit boundary.

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?

The description gives clear context for how the tool behaves by default: the window ends today, spans back windowWeeks, and uses the coach's persisted parameters unless overridden. It does not explicitly say when to prefer this tool over siblings, but the semantics are specific enough that an agent can infer appropriate use.

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