Loading ToolBench
MCP server for NutriSastho AI — a health and nutrition platform built for Bangladesh. Provides tools for BMI calculation, calorie estimation, meal planning, diabetes risk assessment, food search, hospital search, health profile fetching, budget planning, medical report analysis, and food price scraping.
NutriSastho-AI-MCP exhibits significant definition quality gaps. While all 12 tools have names and descriptions, most descriptions are terse (10-50 chars), falling below the 50-200 char LLM-optimized baseline. Input schemas are present but lack depth: parameter descriptions are minimal or absent, enums are not used for constrained inputs (e.g., 'activity_level' accepts free-form strings instead of enum), and output schemas are entirely undocumented. No tool declares what it returns, forcing LLMs to guess. Error handling is absent, no recovery guidance, no categorization of retryable vs fatal errors. Security concerns: tools accept user_id as string parameters without validation. Composition is weak: tools like 'analyze_health_risk' and 'get_diabetes_risk' overlap in purpose but lack clear differentiation. No tool demonstrates idempotency guarantees or pagination for list-like results.
Perform advanced health risk analysis (rules-based) based on the full user profile.
Analyze a medical lab report based on the user's health profile.
Calculate Body Mass Index (BMI) and return the health category.
Calculate Basal Metabolic Rate (BMR) and Total Daily Energy Expenditure.
Generate a full 7-day budget-aware diet plan.
Assess basic risk for type-2 diabetes based on clinical inputs.
Generate a daily Bengali meal plan based on a calorie target.
Output schemas completely undocumented. No tool declares what fields it returns, forcing LLMs to infer structure and risking downstream tool-chaining failures.
Constrained inputs not declared as enums. 'activity_level' accepts free-form strings (sedentary, light, moderate, active, very_active) but is not an enum, LLMs may hallucinate invalid values like 'extreme' or 'none'.
Descriptions too terse (10-50 chars). Most fall below the 50-200 char LLM-optimized baseline. E.g., 'Fetch a user's nutrition budget from the backend API' (52 chars) lacks context on when to call it vs similar tools.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 46 | <=2025-11-25 | v2 |
Fetch a user's nutrition budget from the backend API.
Fetch a user's latest health metrics from the backend API.
Scrape the live market price of a food ingredient from Bangladeshi e-commerce sites.
Retrieve nutritional values for common Bangladeshi foods from the FastAPI backend.
Search for hospitals and clinics from the Next.js API based on city name.
No error handling or recovery guidance. Tools provide no indication of what to do on failure (retry? ask user? fatal?). No actionable error messages documented.
Overlapping tool purposes without clear differentiation. 'get_diabetes_risk' and 'analyze_health_risk' both assess health risk but lack documented distinctions. LLMs will struggle to choose between them.