Sport Health MCP

by LiPeee1

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.1.0
Disambiguation5/5
Each tool maps cleanly to a distinct resource or data type: Huawei source inspection, activity listing, activity summary, GPS track, samples, health context, weather environment, report evidence, and report contract. Even the health context and activity environment tools are clearly separated by source and intent.
Naming Consistency4/5
Most tools follow a clear get_<object> pattern, such as get_activity_summary, get_activity_track, and get_report_contract. The deviations are minor: list_activities uses list instead of get, and inspect_huawei_export uses inspect, but all are still recognizable, verb-first names.
Tool Count5/5
Nine tools is a well-scoped surface for an activity and report analysis server. Each tool represents a meaningful step in the workflow—from inspecting source files, listing and retrieving activity data, adding health/environment context, and producing report evidence and contract rules.
Completeness5/5
The tool set forms a complete read-only pipeline for activity reporting: find source files, list activities, fetch summary, track, samples, health context, environmental context, and then produce evidence and contract for the final agent report. There are no obvious dead ends or missing operations within this server's reporting-focused scope.
Average 3.5/5 across 9 of 9 tools scored. Lowest: 2.8/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must explain behavior. The word 'normalized' hints at data transformation, but it is undefined, and there is no mention of side effects, data source, permissions, or edge cases.
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 one short sentence that immediately states the purpose. There no filler, redundancy, or repetition of the tool name.
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?
Despite having an output schema, the description omits any context about how activity_id is used, what normalized metrics are, and how this tool fits among eight siblings. This is minimal for an agent deciding whether to call this tool.
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 coverage is 0%, so the description must compensate for the activity_id parameter. It only says 'for one activity,' which confirms the parameter identifies a single activity, but it does not explain the format, source, or how to obtain it.
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?
Describes a clear action (Get) on a specific resource (activity summary metrics) for a single activity. It differentiates from sibling tools like get_activity_track and get_activity_samples through the word 'summary', though it does not explicitly name those alternatives.
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 explicit guidance on when to use this tool versus its siblings. The description implies usage for obtaining summary metrics of one activity, but it does not state what to use for other needs or exclude alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral disclosure burden. It does usefully disclose that data is cached and historical, which implies it may be stale or not fetched live, but it does not describe cache-miss behavior, freshness limits, or whether any network call occurs.
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 with no wasted words, and the core purpose is front-loaded. It is compact and easy to scan.
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?
The tool is simple enough that the description is mostly adequate, but it omits any contextual bridge to the sibling tools and leaves the sole parameter unexplained. The presence of an output schema reduces the need to explain the return value, yet this still feels minimal rather than complete.
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?
The description does not mention activity_id at all, and schema description coverage is 0%. The parameter name is reasonably interpretable, but the description adds no semantic guidance beyond the schema and does not compensate for the missing schema descriptions.
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 clear verb and resource: 'Fetch cached historical weather and air-quality context from Open-Meteo.' It is specific enough to be understood as distinct from sibling tools like get_health_context, though it does not explicitly call out that distinction.
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 about when to use this tool instead of alternatives. Given siblings like get_health_context and get_activity_summary, an agent receives no signal about which one fits a given need.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It does reveal that the result is paginated and scoped to one activity, which is meaningful. However, it does not describe error behavior, auth requirements, rate limits, or what happens when an activity_id is invalid.
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?
A single front-loaded sentence conveys the core resource, pagination behavior, and relevant data fields. There is no redundant information or filler.
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?
The tool is simple and has an output schema, so the description does not need to enumerate return values. Still, it lacks usage guidance and explicit details about pagination behavior or error cases, which are left to inference.
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 schema has 0% description coverage, so the description must help interpret parameters. 'Paginated' implies limit and offset are pagination controls, and 'one activity' matches activity_id. But the description does not explain ordering, maximum limit, or the exact units or format expected.
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?
States a specific verb and resource: 'Get a paginated GPS track with timestamps and altitude for one activity.' This is unambiguous and clearly distinguishes the tool from siblings like list_activities and get_activity_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 given about when to choose this tool over alternatives such as get_activity_samples or get_activity_environment. There are no conditions, exclusions, or known alternatives mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 burden for behavioral context. The verb 'get' and the word 'summaries' indicate a read-only operation and the scope of data, but the description does not disclose behavior around missing health data, the meaning of the surrounding window, or any rate/consistency expectations.
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 compact sentence that leads with the action and resource, and adds a relevant list of health metrics without unnecessary elaboration. Every word contributes to the tool's purpose.
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?
For a simple three-parameter tool with an output schema available, the description covers the central intent and the health metrics reasonably well. It still leaves the exact day-range behavior and data-availability edge cases to inference, but these are not severe omissions given the schemas and defaults.
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% and the description does not explicitly explain activity_id, days_before, or days_after. However, 'around an activity' adds some meaning to the before/after window and the default values in the schema are reasonably self-explanatory, so it is more than a tautology but still not a full parameter explanation.
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 verb 'get' and the specific resource: 'daily health summaries around an activity', and lists the included health indicators (sleep, HRV, stress, heart rate, SpO2). This makes it distinct from several siblings like get_activity_track or get_activity_environment, though it does not explicitly name a sibling within the text.
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 phrase 'around an activity' provides a plausible context for when to use the tool, but no explicit when-to-use or when-not-to-use guidance is present. There is no mention of when to choose this over get_activity_summary or get_activity_samples, so the decision is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries more behavioral weight. It adds one useful behavior detail: the result is deterministic, meaning the generated evidence pack is reproducible. However, it does not explain important behavioral aspects such as whether this is a read-only/resource-consuming operation, whether it can fail, or what 'flags' semantically imply for the agent.
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 sentence that is concise, front-loaded with the core action, and contains no filler. The tradeoff is that brevity omits some needed behavioral details, but the text that is present earns its place.
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?
The output schema exists, so return values are not required in the description. Even so, the description lacks parameter-level guidance, clear exclusions, and deeper behavioral context. It is minimally usable but not fully complete for an agent that must decide among several related activity/report tools.
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%, so the description was expected to compensate, and it does not explain either parameter. Still, activity_id is clearly the identifier of the target activity, and include_environment is self-descriptive enough to infer its boolean intent, giving the parameter semantics a modest baseline.
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 'Build' and names a concrete deliverable ('deterministic facts, context, flags, and guidance for a post-activity Agent report'), so the tool's basic purpose is clear. It does not fully distinguish itself from report-related siblings like get_activity_summary or get_report_contract, so it falls short of a 5.
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 phrase 'for a post-activity Agent report' provides a clear, explicit use context: call this after an activity when generating an Agent report. It does not name alternative siblings, exclude related tools, or state when not to use it, but it does convey a direct context rather than leaving usage entirely implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral disclosure burden. The verb 'list' implies a read-only operation and the filter values add useful context, but the description does not explain default limit behavior, what a null sport_type returns, pagination, or response shape.
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 that front-loads the primary action and resource, then adds the key filtering detail. There is no filler or redundant repetition of the schema.
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?
For a simple list tool with no required parameters and an output schema, the description is largely sufficient: it says what is listed and how to filter. Some context is left implicit, such as default limit behavior and when a caller should switch to the detail getter tools, but the schema and sibling names cover part of that gap.
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 schema has no descriptions for its parameters, so the description adds value by enumerating the valid sport_type filter values: running, walking, cycling, fitness, or workout. However, it does not clarify the 'limit' parameter or how filtering interacts with it.
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 operation ('List') and resource ('imported activities'), and gives concrete filter categories. It is distinguishable from the sibling get_activity_* tools because it describes a list view rather than a specific activity detail, though it does not explicitly contrast with those tools.
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 for listing imported activities and optionally filtering them by sport type. It does not explicitly say when to use this tool versus get_activity_summary, get_activity_track, or other siblings, nor does it provide exclusion cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the transparency burden. It usefully states that results are paginated, which indicates offset/limit-driven behavior, and 'Get' signals read-only usage. However, it does not disclose what happens when the optional 'metric' parameter is null, nor does it mention ordering, boundaries, or rate-limit behavior.
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 concise sentence with no jargon or required words. 'Get paginated' is front-loaded, and the metric list is compact. Every word earns its place.
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?
An output schema exists, so the response shape is not a concern. Yet the description still omits important invocation context: there is no statement about what null metric means, how pagination limits/offsets work, or any model limits on limit. This is likely to be usable in many cases but leaves crucial optionality unstated.
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%, so the description must compensate. It does add semantic value for the metric parameter by listing possible sample types, but it does not explain the default null behavior, how limit/offset interact for pagination, or whether metric values are case/index-sensitive. The parameter list is therefore partially clarified but not fully covered.
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 is specific and immediate: it uses the verb 'Get' with a clear resource ('paginated ... samples') and lists the exact metric types supported. This makes the purpose unmistakable and differentiates it from sibling tools like get_activity_summary and get_activity_track.
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 when to use this tool—when you need paginated raw activity samples—but it never explicitly says when to prefer it over alternatives such as get_activity_summary or get_activity_track. The agent must infer routing from the tool name and sibling names rather than from direct guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full responsibility. It clearly says the tool 'returns' a structure and rules, which implies a non-mutating retrieval. However, it doesn't disclose any details about the return format, version, caching behavior, or permissions required, though this is less critical for a 0-parameter read-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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one sentence of 11 words, front-loaded, with no filler or repeated information. It captures the essential behavior as precisely as possible for a simple contract-retrieval tool.
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 zero parameters and the presence of an output schema, the description is complete enough for a simple contract lookup. The main gap is that it doesn't frame the relation to sibling tools such as get_report_evidence_pack, but that's a usage-guidance concern rather than a core completeness failure.
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 with an empty schema, so the description cannot need to add anything beyond what the schema already states. The baseline of 4 for 0-parameter tools is appropriate; nothing is unfilled.
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 ('Return') with a concrete resource ('stable structure and writing rules for end-user activity reports'), which strongly communicates the tool's deliverable. It distinguishes itself from all siblings (activity data, evidence packs) by focusing on the report contract itself.
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 usage context or when-to-use/when-not-to-use guidance is provided. The description doesn't mention when to use this instead of siblings like get_report_evidence_pack or get_activity_summary, so the agent must infer from the tool's name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. 'Check' and 'report' imply a read-only inspection that returns counts rather than file contents, which is helpful, but it doesn't explicitly state side effects, required configuration, or error/edge-case behavior.
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 one concise front-loaded sentence. It delivers the action, resource, and result with no filler or unclear phrasing.
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 parameters, an output schema, and a clear read-oriented purpose, the description is mostly complete. It could be slightly stronger with explicit guidance on what 'configured' means or what the counts are used for, but an agent can likely call it correctly as-is.
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 takes zero parameters and the schema confirms this, so there is no parameter-semantic burden on the description. A score of 4 aligns with the baseline for zero-parameter tools.
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 states a specific action ('Check') and a clear resource ('configured Huawei export') along with the concrete outcome ('report available source-file counts'). This distinguishes it from the sibling activity/health/report tools.
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 context is implicitly clear: an agent should call this when it needs to verify the Huawei export and know how many source files are available. However, there is no explicit guidance on when not to use it or how it compares to the sibling tools.
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:

[![sport-health-mcp MCP server](https://glama.ai/mcp/servers/LiPeee1/sport-health-mcp/badges/card.svg)](https://glama.ai/mcp/servers/LiPeee1/sport-health-mcp)

Score Badge

Copy to your README.md:

[![sport-health-mcp MCP server](https://glama.ai/mcp/servers/LiPeee1/sport-health-mcp/badges/score.svg)](https://glama.ai/mcp/servers/LiPeee1/sport-health-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/LiPeee1/sport-health-mcp'

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