Mi Fitness MCP

by kubulashvili

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.2.0
Disambiguation4/5
Most tools are clearly distinct, but `get_workout_records` vs `query_workouts` could be confused (personal vs official workouts). Also `query_metric_series` is somewhat generic and may overlap with `query_heart_rate` and `query_body_measurements`.
Naming Consistency4/5
All tool names follow a verb_noun structure, but there is a mix of `get_` and `query_` prefixes (both meaning retrieval). This is a minor deviation from a perfectly uniform pattern.
Tool Count5/5
12 tools is well within the ideal 3-15 range and each tool serves a distinct purpose for a fitness data server, covering connection, sync, profile, summaries, metrics, workouts, and data coverage.
Completeness4/5
The toolset offers broad coverage for retrieving and analyzing fitness data, including raw series, summaries, workouts, and comparisons. Minor gaps could include sleep tracking or goal management, but they are not obviously required for the stated purpose.
Average 2.4/5 across 12 of 12 tools scored. Lowest: 1.3/5.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 2 community issues answered or closed in the last 6 months
- 1 commit in the last 12 weeks
- Last stable release on August 5, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of behavioral disclosure. It does not mention return format, side effects, data scope, or any other behavioral aspects, leaving the agent entirely in the dark.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but this is under-specification rather than conciseness. A single phrase that repeats the tool name provides no useful content and does not earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations, output schema, and parameter details, the description is completely inadequate. It provides no context about what data coverage entails, how it is computed, or what the result looks like.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter 'data_types' with no description, and schema description coverage is 0%. The description does not compensate by explaining the parameter or its meaning, failing to add any value beyond the raw parameter name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get data coverage' is a tautology of the tool name, offering no additional specificity about what 'data coverage' means or how it differs from sibling tools like get_profile or get_daily_summary. It has a verb and resource but lacks any clarifying detail.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description gives no context about intended use cases, prerequisites, or situations where this tool should be preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description offers no behavioral details such as read-only status, timezone handling, data granularity defaults, or response format. The tool's side effects and constraints are entirely undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
At only three words, the description is extremely brief but this is under-specification rather than concise efficiency. It lacks any structured information that would help an agent select and invoke the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given five parameters (three required) and no annotations or output schema, this description is grossly insufficient. It fails to cover essential context like metric definitions, date range handling, or available aggregations, making the tool nearly impossible to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description provides no additional meaning for the five parameters. It does not explain the metric enum, date formatting, or aggregation and granularity options, leaving them completely ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description 'Query metric series' simply restates the tool name, providing no additional scope or differentiation from sibling tools like query_heart_rate or query_workouts. It lacks specifics about what metrics are covered or how the series is queried.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not mention when to use this tool over alternatives, nor any prerequisites or recommended invocation patterns, despite a set of sibling query tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only says 'Get daily activity summary', which implies a read-only operation, but it does not disclose return format, error behavior, data scope, or any side effects. The description adds minimal behavioral context beyond the verb itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but it is under-specified rather than concise. It fails to provide necessary detail, so the brevity is not a positive attribute. The single sentence does not earn its place by adding useful information beyond the tool's name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters, no output schema, no annotations, and 11 siblings, the description is severely inadequate. It does not explain what the summary contains, how the date range works, or how this tool differs from other summary/query tools. This is insufficient for an agent to select and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description provides no explanation of the parameters (date, start_date, end_date). Their meaning is left entirely to inference. The relationships between these parameters and their expected formats are undocumented, offering no value beyond the schema's bare names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool does a 'Get' of a 'daily activity summary', which is a verb+resource. However, it is vague about what 'activity' encompasses and does not clearly differentiate from sibling tools like summarize_workouts or query_metric_series. It is not a tautology, but it lacks specificity.
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?
No guidance is provided on when to use this tool versus alternatives. The description does not mention any context, exclusions, or alternative tools. The agent is left to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavior. It merely says 'Query' implying a read operation, but it does not disclose required date parameters, the meaning of 'latest_only', or what the returned data looks like. No behavioral traits beyond the literal query are revealed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at three words, but it is under-specification rather than useful conciseness. It provides no structure or key information, making it less helpful than a longer description with relevant details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 parameters, required start/end dates, optional metrics, and no output schema), the description is drastically incomplete. It fails to convey parameter semantics, usage context, or return behavior, leaving the agent without sufficient information to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 4 parameters with no descriptions, and the tool description provides zero explanation of any parameter. Since schema description coverage is 0%, the description was expected to compensate, but it does not – parameters like 'metrics', 'latest_only', and proper date formats are left unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a verb ('Query') and a resource ('body measurements'), but it is vague and does not specify the scope, time range, or how it differs from sibling tools like query_metric_series or query_heart_rate. It is not a tautology, but it lacks enough specificity to be fully clear.
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?
No guidance is provided on when to use this tool versus other query tools. There is no mention of alternatives, prerequisites, or context. The agent is left without any direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. 'Synchronize Mi Fitness data' gives no information about what happens to existing data, whether the operation is destructive, requires authentication, or has rate limits. This is a severe lack of transparency for a mutation-like tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only a short phrase, so it is technically concise, but it is under-specified. It adds very little value beyond the tool name and lacks substantive content, making it more of an under-specification than a model of conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters, no annotations, and no output schema, the description is drastically incomplete. It provides no context about invocation effects, expected outcomes, or parameter relationships, making it inadequate for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema defines 4 parameters with 0% coverage in the description. The description does not explain any parameter semantics, and there is no compensation for this gap. Users are left with no idea what end_date, data_types, start_date, or force_full_sync mean in context.
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 uses the verb 'Synchronize' with a specific resource ('Mi Fitness data'), which distinguishes it from sibling tools that are all query/read operations. However, 'synchronize' is somewhat vague as it doesn't specify the direction or scope of the sync, so it falls short of a perfect 5.
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 explicit guidance on when to use this tool versus the sibling query tools. The name and the read-only nature of the siblings imply it's for populating/updating data, but the description never states this, provides prerequisites, or mentions alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states 'Query official Xiaomi workout sessions,' implying a read operation but offering no detail on return format, pagination, rate limits, or authentication requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise in length but under-specified. It fails to convey essential information, making it more of a stub than a useful description. Every sentence should earn its place; this one does not.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With five parameters, no annotations, no output schema, and multiple sibling tools, the description is severely incomplete. It does not address filtering, required inputs, output structure, or how it relates to other workout-related tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no parameter meaning beyond the schema. The five parameters (start_date, end_date, min_duration, activity_types, min_distance_km) are entirely unexplained, forcing the agent to guess their semantics and formats.
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 queries workout sessions, identifying the verb and resource. However, it does not distinguish this from sibling tools like get_workout_records or query_metric_series, which could overlap in functionality.
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 lacks context about intended use cases, prerequisites, or exclusions, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of behavioral disclosure. It only states the action without revealing return format, date range handling, filtering, or any side effects. It implies a read-only operation but adds no substantive transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no redundancy, making it concise. However, it is under-specified for a tool with four parameters and no other documentation, sacrificing necessary context for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, no parameter semantics, and no usage guidance, the description is incomplete. It does not explain what the query returns, how to specify filtering, or when to use it, leaving significant gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 0% description coverage, and the description does not mention any parameters. It fails to explain start_date, end_date, limit, or sample_type, leaving the agent with only raw property names and no semantic meaning.
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 uses a specific verb 'query' and a specific resource 'heart rate samples', clearly stating the tool's function. However, it does not differentiate from sibling tools like query_metric_series or query_body_measurements, which may also retrieve health metrics.
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?
No guidance is provided on when to use this tool versus alternatives. The description lacks any context about use cases, prerequisites, or exclusions, giving the agent no decision support for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosure. It does not state whether the operation is read-only, what the return format is, or any caveats about data aggregation. The verb 'compare' implies a read-only action, but no behavioral traits are explicitly disclosed.
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 a single, focused sentence with no waste. It is front-loaded and easy to parse. However, given the complexity of four parameters and no annotations, a slightly more structured form (e.g., adding a sentence about return values) would be valuable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, no annotations, and 0% schema coverage, the description is too sparse to be complete. It lacks information about the return value, date format, and what 'totals' means (e.g., count, duration, calories). It also provides no guidance on when to use this versus sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description mentions 'two date ranges', which maps to the four date parameters, but it does not explain the format, semantics of start vs end, or how 'totals' relate to the parameters. The parameter names are self-descriptive, but the description does not compensate for the complete lack of schema-level documentation.
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 uses the specific verb 'compare' with the resource 'workout totals' and scopes it to two date ranges. This clearly distinguishes it from siblings like query_workouts or summarize_workouts, though it could be more explicit about what metrics are calculated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the purpose: use this when you need to compare workout totals across two periods. However, the description does not explicitly state when to use it over alternatives like summarize_workouts or query_workouts, nor does it provide exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for behavioral disclosure. It only says 'Get', implying a read operation, but does not disclose what exactly is returned, whether activity_type filtering is supported, ordering, pagination, or any side effects. This is minimal and leaves significant uncertainty.
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 a single clear sentence with no filler or redundant phrasing. It is appropriately front-loaded with the main action and scope. It is slightly terse, but conciseness itself is strong; lack of detail is more a completeness concern.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 3 parameters, no annotations, and no output schema, yet the description offers only a one-line summary. It does not explain return values, parameter constraints, or how this tool relates to sibling tools. It is inadequate for an agent to select and invoke the tool correctly without additional inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/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 for parameter meaning, but it only vaguely references 'a date range'. It does not explain start_date/end_date format or semantics, and it completely omits the optional activity_type parameter. Some context is provided for the date parameters, but not enough.
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 gets personal workout records filtered by date range, with a specific verb ('Get') and resource ('workout records'). However, it does not distinguish this tool from the sibling `query_workouts`, which likely serves a similar purpose, so it misses the full 5 for sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used when a date-range-filtered list of personal workout records is needed, but it gives no explicit guidance on when to choose this over `query_workouts`, `summarize_workouts`, or `compare_workout_periods`. No alternatives or exclusions are mentioned, so guidance remains implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility for behavioral disclosure. It only states 'Check connection status', which implies a read-only operation but doesn't clarify whether it performs network I/O, what side effects it has, or what the output entails. No mention of error behavior or response format.
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 one short sentence, achieving high conciseness. It front-loads the core purpose without redundancy. However, it could incorporate additional behavioral context without losing conciseness, so it's not a perfect 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has zero parameters and no output schema, so the description should compensate by explaining the return value or behavior. It doesn't; it only states the generic purpose, leaving the tool's actual output format and status meanings unspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so schema coverage is 100% by default. The description adds no parameter-specific information, but there are no parameters to document. According to the rubric, a baseline of 4 applies for 0-param tools.
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 uses a clear verb 'check' and specific resource 'connection status', distinguishing it from sibling tools that focus on data queries and summaries. However, it doesn't specify what type of connection (e.g., device, network, API), leaving slight ambiguity.
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, no prerequisites, no exclusions, and no context about typical usage. It is a single declarative sentence without directional advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It only says 'Get', implying a read-only operation, but does not disclose authentication needs, rate limits, side effects, or response format—important context for a tool invoking user data.
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 a single, concise sentence with no wasted words. It is appropriately brief for the tool's simplicity, though it could be slightly more informative without padding.
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?
For a simple no-parameter tool, the description adequately identifies the resource but does not specify what 'user profile information' includes. Having no output schema, the description should provide more detail on the return data, leaving a gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, so the description adds no parameter-level detail. Per the baseline for zero parameters, this is acceptable and requires no compensation.
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 retrieves user profile information, using a specific verb ('Get') and resource ('user profile'). This distinguishes it from sibling tools like get_connection_status and query_workouts, though it lacks detail on what the profile contains.
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?
No guidance is provided on when to use this tool versus alternatives. There is no mention of context, prerequisites, or exclusions, leaving the agent to infer usage solely from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for disclosing behavior, but it only states the aggregation operation. It does not mention return format, read-only status, date handling, or side effects, leaving significant behavioral aspects undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, directly states the action, and contains no redundant words. It is appropriately sized and front-loaded with the verb.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, no annotations, and a very brief description, the tool lacks details on return values, the precise meaning of 'workout volume' (distance, duration, etc.), and date range behavior. This would hinder an agent from correctly invoking the tool without additional context.
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?
The description adds meaning by mapping 'sport' to activity_type and 'ISO week' to week, clarifying the group_by parameter. However, it does not explain start_date/end_date formats or semantics. With 0% schema coverage, this partial compensation earns a middle score.
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?
The description uses a specific verb ('Summarize') with a clear resource ('workout volume') and grouping dimensions ('by sport or ISO week'). It distinguishes itself from siblings like query_workouts (which retrieves records) and compare_workout_periods (which compares periods) by indicating it provides an aggregated summary.
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?
No guidance is provided on when to use this tool versus alternatives such as query_workouts or get_daily_summary. The description lacks explicit use cases, prerequisites, or exclusions, leaving selection to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![mi-fitness-mcp MCP server](https://glama.ai/mcp/servers/kubulashvili/mi-fitness-mcp/badges/card.svg)](https://glama.ai/mcp/servers/kubulashvili/mi-fitness-mcp)

Score Badge

Copy to your README.md:

[![mi-fitness-mcp MCP server](https://glama.ai/mcp/servers/kubulashvili/mi-fitness-mcp/badges/score.svg)](https://glama.ai/mcp/servers/kubulashvili/mi-fitness-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/kubulashvili/mi-fitness-mcp'

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