a207-nutrition-calc-mcp

Server Quality Checklist

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

Latest release: v0.1.1
Disambiguation5/5
Each tool serves a distinct purpose: target calculation, food lookup, substitution, measure conversion, intake summation, phosphorus ratio, dialysis glucose absorption, and drug interaction checking. There is no overlap or ambiguity between tool functions.
Naming Consistency5/5
All tool names follow a consistent snake_case verb_noun pattern (e.g., calc_nutrition_target, lookup_food_nutrients, substitute_food). The verbs are descriptive and uniform, making the toolset predictable and easy to navigate.
Tool Count5/5
With 8 tools, the server is well-scoped for its domain of pediatric CKD nutrition. Each tool adds meaningful functionality without redundancy, covering the essential calculators and data lookups needed for clinical and dietary management.
Completeness5/5
The toolset covers the full workflow: setting nutrition targets, looking up and substituting foods, converting measurements, summing intake against targets, and addressing special considerations like PD glucose absorption and drug interactions. No obvious gaps exist for the stated purpose.
Average 3.5/5 across 8 of 8 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 3 commits in the last 12 weeks
- Last stable release on August 10, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does note the key behavior that the result is to be subtracted from the dietary energy goal, but it fails to disclose how inputs like transport_type or exchanges_per_day affect the calculation, any assumptions, or what the output represents beyond the deduction.
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, front-loaded sentence with no redundant wording, making it highly concise. However, its brevity comes at the cost of clarity for a tool with multiple parameters and defaults, so it is not ideal but still avoids fluff.
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 the tool has five parameters, two required, and no annotations, a one-line description is insufficient. It provides a clue about its role (deducting from dietary energy) but does not explain the workflow, parameter dependencies, or how it integrates with sibling tools, leaving significant gaps for an agent attempting to 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?
The schema has 0% description coverage for parameters, yet the description does not mention any parameter names or explain how they influence the result. It only references the overall concept of glucose absorption, leaving all five parameters completely unexplained.
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 estimates peritoneal dialysis glucose absorption and the associated extra energy, explicitly noting it should be deducted from the dietary energy target. This specific verb-resource pairing distinguishes it from sibling tools like calc_nutrition_target, which focuses on overall nutrition goals.
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 its use when calculating dietary energy targets for patients on peritoneal dialysis, since the estimated energy must be deducted. However, it does not explicitly state when to use this tool over alternatives or provide exclusions, leaving the usage guidance 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It explains the output calculation but does not disclose how inputs are handled—e.g., what happens if 'food' vs. 'protein_g'/'phosphorus_mg' is given, whether it looks up nutrients, or how missing values are treated. This is a significant transparency gap for a tool with multiple optional parameters.
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, front-loaded sentence that immediately states the calculation and its purpose. Every word earns its place; there is no redundancy or filler.
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 the tool has 4 parameters, no annotations, and no schema descriptions, the description is insufficiently complete. It does not explain how the parameters interact, what 'food' expects, or the behavior when only some parameters are provided. Although an output schema exists, the input ambiguity remains unresolved, making this a minimally viable but gap-filled description.
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 explaining parameters. While the formula implies protein_g and phosphorus_mg are numerator/denominator, it does not explain the roles of 'food' and 'grams', units, or defaults. The description adds minimal value over the bare schema, leaving the agent guessing about how to invoke the tool correctly.
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 calculates a phosphorus-protein ratio with the formula 'mg 磷 / g 蛋白' and specifies a use case ('用于限磷时挑选蛋白来源'). This is a specific verb+resource+scope, and the tool's purpose is distinct from siblings like lookup_food_nutrients or calc_nutrition_target. However, it does not explicitly differentiate itself from alternatives, so it stops 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 description provides clear context for when to use the tool ('when restricting phosphorus to choose protein sources'). It does not mention alternative tools or when not to use it, so it lacks the 'when-not' guidance required for a 5.
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 the query purpose and examples, but does not disclose output format, error handling, input constraints, or whether it is a read-only operation. The 'query' verb implies read-only, but this is not confirmed.
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, front-loaded sentence that efficiently communicates the core purpose with no redundancy. Every word contributes to meaning.
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 description gives a clear basic purpose and examples, but lacks usage guidance and parameter semantics. The presence of an output schema may cover return values, but the description is minimal for a tool with no annotations and no parameter descriptions, leaving gaps for correct invocation.
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. It references 'drug' and 'nutrient' but does not clarify that 'drug' is required, 'nutrient' is optional (with default null), or acceptable value formats. The examples of drug categories provide some context but are insufficient for full parameter understanding.
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 action ('查询' / query) and resource ('药物与营养素的交互提示' / drug-nutrient interaction alerts), with specific examples of drug categories (phosphate binders, potassium binders, activated vitamin D, hormones). This distinguishes it from sibling nutrition/food tools.
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 alternatives. Although sibling tools are all nutrition/food-related, the description does not state exclusions, prerequisites, or scenarios 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.
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 mentions the conversion and nutrient attachment, but does not disclose whether the conversion is approximate, requires a known food database, or imposes input constraints. This is a minimal behavioral disclosure.
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 fluff, front-loading the conversion purpose before mentioning the nutrient attachment. It is appropriately sized for the tool's simplicity.
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 description is minimal; the output schema likely covers return format, but the description lacks input prerequisites, usage context, and any caveats about approximations. For a simple 2-param tool, this is incomplete.
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. It mentions grams ('克重') and the resulting portion, but does not define what 'food' should be or any constraints on the grams value. Parameter meanings are only partially conveyed.
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 converts gram weights to household measures (half bowl, palm, spoon) and attaches nutrient information for that portion. This specific verb-resource pairing distinguishes it from sibling tools like lookup_food_nutrients or sum_diet_intake.
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 use when conversion to household measures is needed, but it does not explicitly state when to use this over alternatives or mention any exclusions. No sibling tools are referenced, so guidance is only implied.
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 burden. It discloses the warning behavior (high potassium/phosphate alerts) and the dual portion scope, but does not mention error handling, validation, or explicitly confirm read-only nature. Some behavioral context is provided, but it is not comprehensive.
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, front-loaded sentence that efficiently conveys the tool's purpose and unique warning feature. Every word serves a purpose, with no redundant or filler content.
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 return value details are covered. However, the description lacks clarification for the 'cooking' parameter and provides no usage guidance relative to siblings. For a tool with moderate complexity and no annotations, the description is adequate but has clear gaps.
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. It clarifies the 'portion' parameter by mentioning '指定份量' (specified portion), but the 'cooking' parameter is entirely unexplained, and no value formats or examples are given. This partial coverage is insufficient for full parameter understanding.
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 a specific lookup action ('查询') targeting food nutrients (energy, protein, potassium, phosphorus, sodium) per 100g and specified portion, with an additional warning output. This distinguishes it from sibling tools that focus on calculations, substitutions, conversions, or interactions.
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 its use for retrieving nutrient information with high K/P warnings, but it does not explicitly state when to prefer this tool over alternatives. No exclusions or comparative guidance is provided, leaving the agent to infer based on the tool's name and sibling names.
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 disclosure burden. It does add useful context about dialysis add-on and edema weight correction, which indicates how parameters affect the calculation. However, it does not state whether the tool is read-only, deterministic, or how it handles invalid inputs, leaving some behavioral traits unspecified.
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, front-loaded sentence that efficiently captures the target population, standard, and key adjustments. No redundant words; every phrase adds value.
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 the output schema covering return values, the tool has 9 parameters with zero documentation in the schema. A one-sentence description cannot adequately guide an agent on how to correctly set parameters like growth_status or pd_glucose_kcal_per_day. It is underspecified for the tool's complexity.
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% for 9 parameters. The description only implies that dialysis and edema-related parameters are relevant, but gives no guidance on units, allowed values, or the role of growth_status and pd_glucose_kcal_per_day. This is insufficient compensation for completely undocumented parameters.
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 it calculates daily energy and protein targets for children with CKD per PRNT 2020, and explicitly mentions dialysis add-on and edema body weight corrections. This is a specific verb+resource combination that distinguishes it from sibling tools like calc_pnpr or calc_pd_glucose_absorption.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: use for pediatric CKD patients requiring PRNT 2020-based nutrition targets. However, it does not explicitly state when not to use it or mention alternative tools, so it stops short of full exclusionary 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?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the core behavior (recommend replacements) but does not explicitly mention read-only nature, output format, ranking logic, or any limitations. It adds some context beyond the name but remains basic.
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, well-structured sentence in Chinese that packs the essential elements: constraint types, comparison scope, and action. No fluff or repetition, every part earns its place.
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?
The description is concise yet sufficient for a simple 3-parameter tool. An output schema exists, so return values are covered elsewhere. It provides enough context for the main purpose and the constraint parameter, though it omits details about top_n and edge cases. Given the tool's simplicity, completeness is above minimum.
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 coverage is 0%, so the description must compensate. It explains the 'constraint' parameter by listing example constraints (low potassium, low phosphorus, etc.) and clarifies 'food' is a similar-category item. However, 'top_n' is not explained, leaving its meaning (number of recommendations) implicit from its name and default. Partial compensation only.
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 recommends replacement options (替换方案) among similar foods (同类食物) under specific dietary constraints (低钾/低磷/低钠/低蛋白/等能量). This is a specific verb+resource+scope. It distinguishes from sibling tools that calculate targets or look up nutrients, as it focuses on substitutions.
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 use when a user needs a food substitute under a health constraint, but it does not explicitly state when to prefer this tool over alternatives or provide exclusions. It lacks direct comparison with sibling tools like lookup_food_nutrients or calc_nutrition_target, so guidance is only 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 burden of behavioral disclosure. It clearly states what the tool computes (aggregates nutrients, compares to targets, provides achievement rates and suggestions) but does not mention whether it is read-only, how missing data is handled, or any limitations. This is adequate but leaves gaps.
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 conveys the essential purpose and outputs without redundancy. Every phrase contributes valuable information.
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 and the presence of an output schema, the description sufficiently covers the main behavior: summarizing multiple days, comparing to target, and giving actionable results. However, it lacks explicit input format details and usage context, so it is not fully complete for an agent needing to construct a correct request.
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, and the description only implicitly maps 'diary' to the multi-day diet diary and 'target' to the target object. It adds meaning by listing the nutrients involved, but does not explain the structure of diary items or target fields, which are needed for actual invocation.
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 function: aggregating energy/protein/potassium/phosphorus/sodium from a multi-day diet diary and comparing against targets to produce achievement rates and action suggestions. It uses a specific verb ('汇总' / summarize) and resource ('多日饮食日记' / multi-day diet diary), and is clearly distinguished from sibling tools like lookup_food_nutrients or calc_nutrition_target.
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 implies when to use the tool: when you have a multi-day diet diary and need a summary of key nutrients with target comparison. It does not explicitly mention alternatives or exclusions, but the context is clear enough for an agent to select it over lookup or substitution 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:

[![a207-nutrition-calc-mcp MCP server](https://glama.ai/mcp/servers/ayeyouok/a207-nutrition-calc-mcp/badges/card.svg)](https://glama.ai/mcp/servers/ayeyouok/a207-nutrition-calc-mcp)

Score Badge

Copy to your README.md:

[![a207-nutrition-calc-mcp MCP server](https://glama.ai/mcp/servers/ayeyouok/a207-nutrition-calc-mcp/badges/score.svg)](https://glama.ai/mcp/servers/ayeyouok/a207-nutrition-calc-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/ayeyouok/a207-nutrition-calc-mcp'

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