
Chakudya Mcp Server
io.github.edisontaimu9-uiPublished by GitHub account edisontaimu9-uiv1.0.0Updated Oct 24, 2026
MCP tools for Malawian food search, clinical nutrition calculators, and RAG-backed guidance.
Overview
A remote MCP server for searching Malawian food data, running clinical nutrition calculations, and querying a RAG nutrition knowledge base.
- What you can do
- Search and look up foods, packaged products and barcodes, and read food details with nutrient values per 100 g, including scaled portions and multi-item meal analysis. Run clinical lookups for diabetes and renal exchanges, enteral formulas, and BMI, BMR and TDEE calculations. Use pediatric fluid, energy, protein, growth-velocity and enteral-feed calculators, plus IOM/DRI EER, MET activity, alcohol kcal, respiratory quotient and Atwater energy tools. Compute WHO growth z-scores and percentiles for children from 0 to 19 years. Query a RAG knowledge base for guidelines, evidence, disease overviews and medicine information.
- When to use it
- Useful for dietitians, nutrition students and clinicians working with Malawian foods or pediatric and clinical nutrition estimates, and for anyone who wants an assistant to look up food composition or run standard nutrition formulas without manual arithmetic.
- Requirements
- A remote Streamable HTTP endpoint; the manifest declares no authentication, but the README describes a bearer token (MCP_AUTH_TOKEN) required in production and sent as an Authorization header. Network access to the endpoint and to the upstream Chakudya API it calls.
Installation
In SourceWeft
- Open Chakudya Mcp Server in the dashboard and add it to a workspace.
- Enable the server for the chats that should use its tools.
Web executable via Streamable HTTP. Remote servers run from the web runtime once configured in a workspace.
Use with an agent
Paste this prompt into Claude Code, Codex, Cursor or another agent — or into SourceWeft chat. The agent reads this server's install guide, shows you its publisher, endpoint and sign-in, and adds it to your client once you agree. Keys never go into a command.
Read https://sourceweft.com/mcp/io.github.edisontaimu9-ui%2Fchakudya-mcp-server/install.md and connect the MCP server it describes to my client. Before changing any config, show me its publisher, endpoint and sign-in method and wait for my OK. Never put an API key in a command or in a file I would commit; ask me where it should come from.Other MCP clients
Add this to your client's mcpServers config.
{
"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.
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).
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
Environment variables
Copy .env.example to .env and fill in:
Security considerations
- Auth is mandatory in production.
env.tsexits the process at startup ifNODE_ENV=productionandMCP_AUTH_TOKENis unset — this is a deliberate fail-closed check, not just a warning. - This server sits in front of your rate-limited RAG routes.
/rag/askon 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_KEYserver-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 thetransportsmap insrc/index.tsfor a shared store. - CORS is off by default. Only enable
MCP_ALLOWED_ORIGINSif you have a specific browser-based MCP client; server-to-server MCP clients (Claude Desktop, Claude Code, etc.) don't need it.
Running locally
Or for iterative dev with auto-reload:
Health check: curl http://localhost:8787/health
Connecting an MCP client
Point any Streamable-HTTP-capable MCP client at:
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.
- Push this repo to GitHub (commands below).
- In the Render dashboard: New → Blueprint, connect your GitHub account, pick the
chakudya-mcp-serverrepo. Render readsrender.yamlautomatically. - Render provisions the service on the Free plan and auto-generates a random
MCP_AUTH_TOKEN(viagenerateValue: 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. - 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.
- Sign up at uptimerobot.com (free plan, no card).
- Add a new HTTP(s) monitor:
- URL:
https://<your-service>.onrender.com/health - Interval: 5 minutes
- URL:
- Save.
/healthis unauthenticated by design, specifically so this monitor doesn't need yourMCP_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:
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
Plain VPS with a process manager
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
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).
Source: README.md at commit fe44680
Tools
0Version history
1- v1.0.0LatestSep 16, 2026
Score
85% of the applicable checks met
How complete this listing is, computed from the registry entry, the endpoint and public sources. Not a rating of the server and not a statement that it is safe or working today: reachability is a dated check, and no installs or reviews go into the score.
- Reached in the last 30 daysRequired25 pts
- Auth declaredRequired10 pts
- Tools listedRequired15 pts
Answer tools/list without a credential, or ship a package that starts in a sandbox without one.
- DescriptionRequired15 pts
- Logo10 pts
- Documentation15 pts
- License10 pts