Chakudya Mcp Server

io.github.edisontaimu9-ui由 GitHub 账号 edisontaimu9-ui 发布v1.0.0更新于 Oct 24, 2026

MCP tools for Malawian food search, clinical nutrition calculators, and RAG-backed guidance.

已验证Streamable HTTP可网页运行位置与生活知识与记忆数据与分析

概览

AI 生成的概览

一个远程 MCP 服务器,用于检索马拉维食物数据、运行临床营养计算,并查询基于 RAG 的营养知识库。

可以做什么
搜索和查询食物、包装食品与条形码,读取每 100 克营养成分的食物详情,并支持按份量换算和多条目餐食分析。运行糖尿病与肾病交换份、肠内营养配方查询,以及 BMI、BMR、TDEE 计算。使用儿科液体、能量、蛋白质、生长速度和肠内喂养计算器,以及 IOM/DRI EER、MET 活动、酒精千卡、呼吸商和 Atwater 能量工具。计算 0 至 19 岁儿童的 WHO 生长 z 分数和百分位。查询 RAG 知识库以获取指南、证据、疾病概览和药物信息。
适用场景
适合处理马拉维食物或儿科与临床营养估算的营养师、营养专业学生和临床人员,也适合希望助手直接查询食物成分或运行标准营养公式而无需手工计算的人。
运行要求
远程 Streamable HTTP 端点;清单声明无需认证,但 README 说明生产环境需要 bearer 令牌(MCP_AUTH_TOKEN),通过 Authorization 请求头发送。需要能访问该端点及其调用的上游 Chakudya API。
安装前请注意
包括疾病和药物信息在内的 RAG 回答是由知识库支撑的 LLM 生成文本,并非经过核实的医学参考,只能作为起点。所有计算器均为估算,不能替代个体化临床评估或实测间接测热法。README 指出在免费托管层服务可能休眠,导致进行中的会话中断。

安装

在 SourceWeft 中

  1. 打开 控制台中的 Chakudya Mcp Server,将其添加到工作区。
  2. 为需要使用其工具的对话启用该服务。

Web executable,通过 Streamable HTTP。 远程服务在工作区中配置后即可从网页运行时运行。

交给智能体安装

把这段提示词粘贴到 Claude Code、Codex、Cursor 等智能体,或 SourceWeft 对话中。智能体会读取该服务器的安装指南,先向你展示发布者、端点和登录方式,经你同意后再把它添加到你的客户端。密钥不会写进任何命令。

阅读 https://sourceweft.com/mcp/io.github.edisontaimu9-ui%2Fchakudya-mcp-server/install.md,并按其中说明把这个 MCP 服务器接入我的客户端。修改任何配置之前,先告诉我它的发布者、端点和登录方式,等我确认。不要把 API 密钥写进命令或我会提交的文件;问我密钥应从哪里获取。

查看智能体所依据的安装指南

其他 MCP 客户端

把它添加到你客户端的 mcpServers 配置中。

{
  "mcpServers": {
    "chakudya": {
      "type": "http",
      "url": "https://chakudya-mcp-server.onrender.com/mcp"
    }
  }
}

README

Chakudya MCP Server

An MCP (Model Context Protocol) server that exposes the Chakudya Nutrition Registry (CNR) API as a set of MCP tools, so any MCP-compatible client (Claude, Claude Code, other LLM agents) can search Malawian food data, run clinical nutrition lookups, and query the RAG knowledge base directly.

This is a new, separate layer. It does not replace or modify the Chakudya Worker. It's a small Node/TypeScript HTTP service that sits in front of your existing API and translates MCP tool calls into plain HTTP requests against the routes your Worker already serves.

MCP Client (Claude, etc.)        │  Streamable HTTP (JSON-RPC over HTTP + SSE)        ▼Chakudya MCP Server  (this project)        │  plain HTTPS fetch()        ▼Chakudya Worker API  (unchanged) → Supabase / Cohere / Groq / USDA / OFF / FatSecret

Why a separate server, not a Worker

The official MCP TypeScript SDK's StreamableHTTPServerTransport is built for Node's http.IncomingMessage/ServerResponse. Cloudflare Workers use the Fetch API instead, and the SDK's web-standard variant (WebStandardStreamableHTTPServerTransport) is newer and less battle-tested for production session management. Running this as a plain Node service (Docker, Render, Fly.io, a VPS, etc.) is the more standard, better-documented path today, and it keeps this concern fully decoupled from your Worker's deploy cycle. Nothing stops you from porting it to the web-standard transport on Workers later if you want a single-platform deploy — the tool logic in src/tools/* doesn't care which transport wraps it.

Tools

All 31 tools either call your existing Chakudya Worker over HTTPS, or are pure in-process calculation/table lookups — none of them touch Supabase, Cohere, or Groq directly, and none of them need ADMIN_API_KEY (every route they use is public).

ToolChakudya route(s) used
search_foodGET /foods → falls back to GET /foods/lookup
get_food_detailsGET /foods/:id
calculate_nutrientsGET /foods or /foods/:id, then scales per-100g values in-process
analyze_mealsame as above, looped and summed across multiple items
barcode_lookupGET /packaged?barcode= → falls back to GET /foods/lookup?barcode=
packaged_food_searchGET /packaged and/or GET /products
diabetes_exchange_lookupGET /exchange
renal_exchange_lookupGET /renal
enteral_formula_lookupGET /formulas
nutrition_calculatornone — pure BMI/BMR (Mifflin-St Jeor)/TDEE math
rag_retrievePOST /rag/retrieve
search_guidelinesPOST /rag/ask (context: "clinical")
retrieve_evidencePOST /rag/ask (context: "both", higher top_k)
disease_informationPOST /rag/ask, query framed for educational disease overview
medicine_informationPOST /rag/ask, query explicitly instructed to exclude dosing/prescribing
pediatric_fluid_requirementsnone — pure Holliday-Segar math
pediatric_energy_requirementsnone — pure Schofield/WHO BMR + DRI/FAO 2004 + DRI/IOM 2006 math
pediatric_protein_requirementsnone — pure IOM 2005 / ASPEN sick-child / preterm table lookup
pediatric_growth_velocitynone — pure ASPEN handbook growth-velocity table lookup
pediatric_enteral_feed_advancementnone — pure enteral feed protocol table lookup
iom_dri_eer_calculatornone — pure IOM/DRI (2002/2005) EER prediction-equation math, all life stages
met_activity_energy_calculatornone — pure MET x weight x duration math
alcohol_kcal_calculatornone — pure volume x proof math
respiratory_quotient_interpreternone — pure RQ reference-value interpretation
preterm_fluid_energy_requirementsnone — pure preterm fluid/energy table lookup
macronutrient_distribution_checknone — pure DRI macronutrient % range table lookup
tee_activity_band_estimatornone — pure REE x activity-band multiplier math
fever_stress_ree_adjustmentnone — pure fever REE adjustment math
atwater_food_energy_calculatornone — pure Atwater factor (4/9/4/7) math
dri_eer_reference_lookupnone — pure DRI Table 2.2 reference table lookup
who_growth_zscorenone — pure WHO growth reference LMS z-score/percentile calculation (weight-for-age, height-for-age, BMI-for-age 0-5y, BMI-for-age 5-19y, head-circumference-for-age, weight-for-length, weight-for-height)

disease_information and medicine_information always return an educational disclaimer alongside the answer and are prompted to avoid diagnosis/prescribing language — but they're still LLM-generated text grounded on whatever's in your RAG knowledge base, not a verified medical reference. Treat them as a starting point for a learner, same as the rest of the RAG-backed tools.

pediatric_* tools (source: BND 415 Clinical Nutrition — Paediatric Medicine Resources) and iom_dri_eer_calculator/met_activity_energy_calculator/alcohol_kcal_calculator/ respiratory_quotient_interpreter (source: Nelms/Ireton-Jones, Nutrition Therapy and Pathophysiology, Ch. 2) are pure calculation/lookup tools — no network call, no CNR data dependency. Same estimate-only caveat applies: not a substitute for individualized clinical assessment or measured indirect calorimetry.

Project layout

src/├── index.ts                 Express app, Streamable HTTP session wiring, graceful shutdown├── config/env.ts            Zod-validated environment config, loaded once at startup├── clients/chakudyaClient.ts  Fetch wrapper for the Chakudya Worker (GET/POST, error normalization)├── server/│   ├── createServer.ts      Builds one McpServer instance and registers all tool modules│   └── security.ts          Bearer auth + per-IP rate limiting for this server's /mcp endpoint├── tools/│   ├── foodTools.ts│   ├── clinicalTools.ts│   ├── ragTools.ts│   ├── educationTools.ts│   ├── pediatricTools.ts        Pediatric fluid/energy/protein/growth/enteral-feed calculators│   └── energyExpenditureTools.ts  IOM/DRI EER, MET activity, alcohol kcal, RQ interpreter│   └── whoGrowthTools.ts        WHO Child Growth Standards z-score/percentile calculator (LMS)├── data/│   └── who/                     WHO Child Growth Standards LMS tables (JSON, per standard+sex)└── utils/    ├── logger.ts             Structured JSON logging    └── toolResult.ts         Consistent success/error shaping for every tool handler

Environment variables

Copy .env.example to .env and fill in:

VariableRequiredNotes
CHAKUDYA_API_BASE_URLno (defaults to the maintainer's own Worker)If you're forking this repo to front your own CNR instance, set this to your own Worker's URL instead of relying on the default
CHAKUDYA_ADMIN_API_KEYnoNot used by any current tool; only needed if you add an admin-gated tool later
PORTno (default 8787)
MCP_AUTH_TOKENyes in productionBearer token MCP clients must send. Server refuses to start in production without it
MCP_ALLOWED_ORIGINSnoComma-separated CORS origins; leave blank to disable browser access
MCP_RATE_LIMIT_PER_MINno (default 60)Per-IP cap on this server's own /mcp endpoint
NODE_ENVno (default development)Set to production for deploys

Security considerations

  • Auth is mandatory in production. env.ts exits the process at startup if NODE_ENV=production and MCP_AUTH_TOKEN is unset — this is a deliberate fail-closed check, not just a warning.
  • This server sits in front of your rate-limited RAG routes. /rag/ask on your Worker is capped at 15 req/min per IP — but that's per client IP as seen by the Worker, which would be this server's IP once deployed, shared across everyone using it. The MCP-level rate limiter (MCP_RATE_LIMIT_PER_MIN) exists so one misbehaving MCP client can't silently exhaust that budget for everyone else. Tune it down if you expect multiple concurrent MCP clients.
  • No admin key is embedded or required. Every tool calls a public CNR route. If you add an admin-gated tool later, keep CHAKUDYA_ADMIN_API_KEY server-side only — never expose it to the MCP client.
  • Session state is in-memory, per-process. Fine for a single instance. If you ever scale to multiple instances behind a load balancer, either enable sticky sessions (route by Mcp-Session-Id) or swap the transports map in src/index.ts for a shared store.
  • CORS is off by default. Only enable MCP_ALLOWED_ORIGINS if you have a specific browser-based MCP client; server-to-server MCP clients (Claude Desktop, Claude Code, etc.) don't need it.

Running locally

bash
cd ~git clone https://github.com/edisontaimu9-ui/chakudya-mcp-server.gitcd chakudya-mcp-servercp .env.example .env# edit .env: set MCP_AUTH_TOKEN to a long random stringnpm installnpm run buildnpm start

Or for iterative dev with auto-reload:

bash
npm run dev

Health check: curl http://localhost:8787/health

Connecting an MCP client

Point any Streamable-HTTP-capable MCP client at:

POST/GET/DELETE  https://<your-deployed-host>/mcpHeader: Authorization: Bearer <MCP_AUTH_TOKEN>

For Claude Desktop / Claude Code, add it as a remote MCP server pointing at that URL with the same bearer token. Consult Anthropic's current docs for the exact config file syntax, since that's changed over time — check https://docs.claude.com for the latest mcpServers remote-server format.

Deployment: Render (recommended — free, no credit card)

This repo includes render.yaml, so Render's Blueprint feature deploys it without any manual dashboard configuration.

  1. Push this repo to GitHub (commands below).
  2. In the Render dashboard: New → Blueprint, connect your GitHub account, pick the chakudya-mcp-server repo. Render reads render.yaml automatically.
  3. Render provisions the service on the Free plan and auto-generates a random MCP_AUTH_TOKEN (via generateValue: true). After the first deploy, go to the service's Environment tab to copy that generated token — you'll need it in your MCP client config.
  4. Deploy. Your MCP endpoint will be https://<your-service-name>.onrender.com/mcp (check the Render dashboard for your actual generated URL — it may include a random suffix if your chosen name is taken).

The free-tier sleep problem, and the fix

Render's free web services spin down after 15 minutes with no traffic, then take 30-60 seconds to wake on the next request. That's fine for a health check, but it can drop an in-progress MCP session (session state lives in memory — see src/index.ts) if the client goes quiet mid-conversation for too long.

Fix: keep it warm with a free uptime monitor pinging /health every 5-10 minutes.

  1. Sign up at uptimerobot.com (free plan, no card).
  2. Add a new HTTP(s) monitor:
    • URL: https://<your-service>.onrender.com/health
    • Interval: 5 minutes
  3. Save. /health is unauthenticated by design, specifically so this monitor doesn't need your MCP_AUTH_TOKEN.

This keeps the service warm 24/7 within the free plan's 750 hrs/month (well under the cap for one service pinged this way).

Updating after a code change

Render auto-redeploys on every push to your connected branch — no extra step needed:

bash
git add .git commit -m "Update MCP server"git push

Watch the deploy in the Render dashboard's Events tab; it typically finishes in 1-2 minutes for a project this size.

Other deployment options

Docker anywhere

bash
docker build -t chakudya-mcp-server .docker run -d -p 8787:8787 \  -e NODE_ENV=production \  -e MCP_AUTH_TOKEN=<long-random-string> \  -e CHAKUDYA_API_BASE_URL=<your-chakudya-worker-url> \  --name chakudya-mcp chakudya-mcp-server

Plain VPS with a process manager

bash
npm install --omit=devnpm run buildnpx pm2 start dist/index.js --name chakudya-mcp

Put it behind Nginx/Caddy for TLS termination if you're not already fronting it with something that handles HTTPS.

Updating via the command line

bash
cd ~# first time only:git clone https://github.com/edisontaimu9-ui/chakudya-mcp-server.gitcd chakudya-mcp-server
# after any file update:cp <path-to-updated-file>.ts src/<path>/<updated-file>.tsgit add .git commit -m "Update MCP server"git push

Then redeploy on whichever platform you chose (Render/Railway/Fly auto-redeploy on push if you connected the GitHub repo; otherwise trigger a manual redeploy or re-run the Docker/pm2 commands above on your host).

来源:README.md,提交 fe44680

工具

0
SourceWeft 尚未读取此服务器的工具。

版本历史

1
  1. v1.0.0最新Sep 16, 2026

评分

已满足适用检查项的 85%

该评分衡量此收录条目的完整程度,依据注册中心条目、端点与公开来源计算得出。它不是对服务器本身的评价,也不表示服务器安全或当前可用:可连通性是带日期的检查结果,评分也不包含安装量或用户评价。

  • 近 30 天内可连通必需25 分
  • 已声明认证方式必需10 分
  • 已列出工具必需15 分

    请让服务器在无凭据时响应 tools/list,或发布可在沙箱中无凭据启动的软件包。

  • 描述必需15 分
  • 图标10 分
  • 文档15 分
  • 许可证10 分