Apple Health MCP Server

by the-momentum

Overview Schema Source Related Servers Score Discussions Admin

Python

Hybrid

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
The tools are mostly distinct, with clear separation between Elasticsearch-based analytics (get_health_summary_es, get_statistics_by_type_es, get_trend_data_es, search_health_records_es) and XML file operations (get_xml_by_type, get_xml_structure, search_xml_content). However, there is some potential overlap between get_statistics_by_type_es and get_trend_data_es, as both analyze specific record types over time, which could cause confusion in tool selection.
Naming Consistency4/5
Naming follows a consistent snake_case pattern throughout, with most tools using a clear verb_noun structure (e.g., get_health_summary_es, search_health_records_es). The only minor deviation is get_xml_structure, which uses 'get' instead of a more descriptive verb like 'analyze', but overall the naming is highly predictable and readable.
Tool Count5/5
With 7 tools, the count is well-scoped for an Apple Health data analysis server. This number provides comprehensive coverage for both Elasticsearch analytics and XML file operations without being overwhelming, and each tool appears to serve a distinct purpose that justifies its inclusion.
Completeness4/5
The toolset covers key operations for health data analysis, including summary retrieval, statistical analysis, trend visualization, and search capabilities across both Elasticsearch and XML sources. A minor gap exists in the lack of explicit update or delete tools, but given the server's focus on read-only data analysis from Apple Health exports, this is reasonable and agents can work effectively with the provided tools.
Average 4.1/5 across 7 of 7 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- 1 of 2 community issues answered or closed in the last 6 months
- No commit activity data available
- Last stable release on October 22, 2025
- 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.
This repository includes a glama.json configuration file.
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

Behavior3/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 adds some context by specifying the return data types and an optional aggregation feature, but it doesn't cover important aspects like rate limits, authentication needs, or error handling. The LLM notes provide operational guidance but not behavioral traits.
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 well-structured and appropriately sized, with a clear purpose statement followed by specific return details and operational notes. Every sentence adds value, though the LLM notes could be more integrated into the main description rather than as a separate section.
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 the tool has 0 parameters, an output schema exists, and no annotations, the description provides sufficient context for its purpose and usage. It explains what data is returned and includes operational guidance, though it could benefit from more behavioral details like performance characteristics or limitations.
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 0 parameters with 100% schema description coverage, so no parameter information is needed. The description appropriately doesn't discuss parameters, focusing instead on what the tool does and its output. This meets the baseline for tools with no parameters.
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's purpose: 'Get a summary of Apple Health data from Elasticsearch' with specific details about what it returns (total record count, record type breakdown, and optional date range aggregation). It distinguishes from siblings by focusing on summary data rather than detailed statistics, trends, or search operations, though it doesn't explicitly name alternatives.
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 includes implicit usage guidance through the 'Notes for LLM' section, suggesting to use this data first when asked for medical advice. However, it lacks explicit when-to-use vs. when-not-to-use instructions or named alternatives to sibling tools like get_statistics_by_type_es or search_health_records_es.
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 provided, the description carries the full burden of behavioral disclosure. It adds some context: it describes the return structure in detail, mentions a 'date_range key for query is commented' with a note about hardcoded dates, and includes an 'IMPORTANT' warning not to guess missing data. However, it doesn't cover critical aspects like whether this is a read-only operation, potential performance or rate limits, error conditions, or authentication needs, leaving gaps for a tool that queries Elasticsearch.
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 overly verbose and poorly structured. It includes redundant sections (e.g., repeating details about 'value_statistics' and 'sources' in both the 'Returns' list and 'Notes for LLMs'), extraneous advice (e.g., 'When asked for medical advice...'), and unclear notes (e.g., the confusing comment about 'date_range key'). The core information is buried among less critical details, making it inefficient for quick understanding.
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 the tool's complexity (querying Elasticsearch for health statistics), no annotations, and an output schema present, the description is reasonably complete. It thoroughly explains the return values, parameter usage, and provides examples, which compensates for the lack of annotations. However, it misses some behavioral aspects like error handling or performance considerations, and the output schema existence means it doesn't need to detail return types, but the description does so anyway, adding redundancy.
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?
The schema description coverage is 0%, so the description must fully compensate. It provides detailed semantics for the single parameter 'record_type': explaining it as 'The type of health record to analyze,' offering usage advice ('Use RecordType for most frequent types. Use str if that type is beyond RecordType scope'), and giving examples like 'HKQuantityTypeIdentifierStepCount.' This adds significant value beyond the bare schema, fully documenting the parameter's purpose and usage.
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's purpose: 'Get comprehensive statistics for a specific health record type from Elasticsearch.' It specifies the verb ('Get'), resource ('statistics for a specific health record type'), and source ('from Elasticsearch'). However, it doesn't explicitly differentiate from sibling tools like 'get_health_summary_es' or 'get_trend_data_es', which likely provide different types of health data analysis.
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 provides some implied usage guidance: it mentions the tool is 'useful for health analysis, identifying outliers, and understanding data quality,' and suggests using it 'When asked for medical advice, try to use my data from ElasticSearch first.' However, it lacks explicit guidance on when to use this tool versus alternatives like 'get_health_summary_es' or 'get_trend_data_es,' nor does it specify prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well by specifying return format (list of dicts), error handling behavior (returns list with error dict), and important behavioral constraints ('Do not guess, auto-fill, or assume any missing data'). It also provides example values for parameters, though it doesn't mention 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is somewhat front-loaded with the core purpose, but contains multiple paragraphs with mixed guidance levels. Some sentences like 'Each document in the list should represent a single health record as stored in Elasticsearch' could be more concise. The structure could be improved by grouping related guidance more clearly.
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 the complexity (health data search with multiple filters), no annotations, and an output schema (which handles return values), the description provides good coverage. It explains the tool's purpose, parameter structure with examples, return format, error handling, and specific usage guidance. The main gap is lack of explicit sibling tool differentiation.
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 0% schema description coverage and 1 parameter (a nested object with 7 fields), the description provides excellent compensation. It explains the parameter structure ('HealthRecordSearchParams object containing all search/filter parameters') and gives concrete examples for source_name, date_from/date_to, and value_min/value_max parameters, adding significant meaning beyond the bare schema.
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 searches health records in Elasticsearch with flexible query building. It specifies the resource (health records) and action (search), but doesn't explicitly differentiate from sibling tools like 'search_xml_content' or 'get_health_summary_es' beyond mentioning Elasticsearch context.
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 provides some implied usage guidance ('Use this to retrieve structured health data for further analysis, filtering, or display') and a specific directive for medical advice scenarios. However, it doesn't explicitly state when to use this versus alternatives like 'get_health_summary_es' or 'get_statistics_by_type_es', nor does it provide clear exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and adds valuable behavioral context: 'streams the file for memory efficiency', 'does not load the entire file into memory', 'If filename is not provided, the file set by set_xml_file will be used', and 'Do not guess, auto-fill, or assume any missing data'. It also mentions medical advice preference for ElasticSearch data. The description doesn't cover error handling or performance characteristics.
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 appropriately sized but not optimally structured. Key information is front-loaded, but the 'Notes for LLMs' section contains mixed guidance (some behavioral, some general). The medical advice note seems out of place for this specific tool. Some sentences could be more tightly integrated.
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 2 parameters with 0% schema coverage and no annotations, the description does well explaining parameters, behavior, and returns. The output schema exists, so return values needn't be detailed. However, it doesn't mention prerequisites (like needing set_xml_file called first) or error conditions, leaving some gaps.
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 0% schema description coverage, the description fully compensates by explaining both parameters: record_type ('use RecordType for most frequent types, or any string for custom/rare types') and limit ('Maximum number of records to return (default: 20)'). It adds meaning beyond the bare schema, clarifying usage patterns and defaults.
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 clearly states the verb 'Get' and resource 'all records of a specific health record type from the Apple Health XML file'. It distinguishes from sibling tools like get_xml_structure (structure vs content) and search_xml_content (search vs get by type). The purpose is specific and differentiated.
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 provides clear context: 'Use this to extract all records of a given type for further analysis or conversion'. It distinguishes from ElasticSearch-based siblings by specifying XML file source. However, it lacks explicit when-not-to-use guidance or named alternatives for similar operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/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 effectively describes key behaviors: it streams the file for memory efficiency, does not load the entire file, uses a default file if not specified, and returns up to max_results matches or a message if none are found. It also includes LLM-specific notes like not guessing missing data and prioritizing ElasticSearch for medical advice, adding valuable operational context.
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 appropriately sized and front-loaded, starting with the core purpose. It uses bullet points for parameters, returns, and notes, which enhances readability. However, the 'Notes for LLMs' section includes some extraneous advice (e.g., 'When asked for medical advice...') that is not directly related to tool invocation, slightly reducing efficiency.
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 the tool's moderate complexity (2 parameters, no annotations, but with an output schema), the description is largely complete. It covers purpose, parameters, returns, and behavioral traits. The output schema likely details the return structure, so the description's high-level explanation of returns is sufficient. Minor gaps include lack of error handling details or explicit sibling tool comparisons.
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 schema description coverage is 0%, so the description must compensate. It adds meaningful semantics beyond the schema: it explains that 'query' searches in any attribute value and 'max_results' limits the number of matching records returned, with a default of 50. This clarifies the purpose and usage of parameters that are otherwise only defined by type in the schema.
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 clearly states the tool searches for content in an Apple Health XML file and returns matching records as XML text. It specifies the verb 'search' and resource 'Apple Health XML file', distinguishing it from sibling tools like get_xml_by_type or get_xml_structure which retrieve different data formats or structures.
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 provides clear context for when to use this tool: 'Useful for finding all records containing a specific value, device, or type' and mentions it searches both Record and Workout elements. However, it does not explicitly state when not to use it or name specific alternatives among siblings, such as search_health_records_es, which might serve a similar purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well by specifying what information is returned (file size, root elements, record types, etc.) and behavioral constraints ('Do not guess, auto-fill, or assume any missing data'). It also mentions medical advice guidance, though this is somewhat tangential to the tool's core function.
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 well-structured with clear sections (Returns, Notes for LLMs) and front-loaded with the core purpose. Some sentences in the Notes section could be more concise, but overall it's efficient and focused.
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?
Given the tool's complexity (structural analysis of XML files), no annotations, but with an output schema present, the description provides complete context. It explains what the tool returns, usage guidance, and behavioral constraints, making it fully adequate for the agent to understand and use the tool correctly.
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?
With 0 parameters and 100% schema coverage, the baseline is 4. The description appropriately explains that this tool analyzes an XML file without requiring input parameters, which adds value beyond the empty schema.
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 clearly states the specific action ('Analyze the structure and metadata') and resource ('Apple Health XML export file') with explicit scope ('without loading the entire content'). It distinguishes from siblings by focusing on structural analysis rather than content retrieval or search operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool ('to quickly understand the contents and structure of a health XML file') and includes specific 'Notes for LLMs' with usage instructions. It implicitly distinguishes from siblings by focusing on metadata analysis rather than data extraction or search.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/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 does well by explaining: 'The function automatically handles date filtering if date_from/date_to are provided' (automation behavior), 'IMPORTANT - interval must be one of: "day", "week", "month", or "year". Do not use other values.' (validation constraints), and 'Do not guess, auto-fill, or assume any missing data.' (error handling). It doesn't mention rate limits or authentication needs, but covers key operational behaviors.
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 well-structured with clear sections (Parameters, Returns, Notes for LLMs) and front-loaded purpose. Most sentences earn their place, though the 'When asked for medical advice' note feels slightly tangential. Overall efficient with minimal waste.
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?
Given the tool's complexity (4 parameters, trend analysis), no annotations, and the presence of an output schema, the description is remarkably complete. It covers purpose, usage, parameters, return format (though output schema exists), behavioral constraints, and LLM-specific guidance. Nothing essential is missing for effective tool invocation.
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 0% schema description coverage, the description fully compensates by providing detailed parameter semantics. It explains: 'record_type: The type of health record to analyze (e.g., "HKQuantityTypeIdentifierStepCount")' with an example, 'interval: Time interval for aggregation' with allowed values, and 'date_from, date_to: Optional ISO8601 date strings for filtering date range' with format and optionality. This adds substantial meaning beyond the bare schema.
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 clearly states the tool's purpose: 'Get trend data for a specific health record type over time using Elasticsearch date histogram aggregation.' It specifies both the verb ('Get trend data') and resource ('health record type'), and distinguishes it from siblings by mentioning Elasticsearch aggregation and trend analysis, unlike summary or search tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: 'Use this to analyze trends, patterns, and seasonal variations in health data' and 'When asked for medical advice, try to use my data from ElasticSearch first.' It clearly indicates when to use this tool (for trend analysis) versus alternatives like summary or search 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

Apple Health MCP Server MCP server – quality and maintenance score on Glama

Copy to your README.md:

[![Apple Health MCP Server MCP server – quality and maintenance score on Glama](https://glama.ai/mcp/servers/the-momentum/apple-health-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/the-momentum/apple-health-mcp-server)

Score Badge

Copy to your README.md:

[![Apple Health MCP Server MCP server – quality and maintenance score on Glama](https://glama.ai/mcp/servers/the-momentum/apple-health-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/the-momentum/apple-health-mcp-server)

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/the-momentum/apple-health-mcp-server'

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