Loading ToolBench
A diabetes risk prediction and dietary recommendation system that uses machine learning to assess diabetes risk and provides personalized recipe recommendations based on user health data and preferences
This MCP server exhibits severe quality gaps across naming, descriptions, schema completeness, and error handling. Of the 6 tools, most lack proper verb-based naming conventions, parameter descriptions are either absent or severely incomplete, and output schemas are not documented. The server appears to be a Gradio chatbot wrapper rather than a properly designed MCP tool collection. Tool names like 'predict', 'parse_json', and 'handle_user_input' are vague and do not follow the verb_noun pattern. Parameter types are listed but descriptions are minimal or missing entirely. No error handling guidance is evident. The codebase shows tools implemented in Python but there is no evidence of actual MCP server registration, tool schemas, or protocol compliance.
Calls DeepSeek LLM API to analyze user dietary preferences and health profile, returning category preference scores in JSON format
Formats recipe data from DataFrame into Markdown-formatted display with servings, ingredients list, and numbered cooking steps
Main workflow handler that processes user health data, calculates BMI, predicts diabetes risk, gets dietary recommendations from LLM, and generates personalized recipe suggestions
Parses JSON content from LLM response and extracts category_scores dictionary
Predicts diabetes risk based on patient health metrics (Pregnancies, Glucose, BMI, Age) using an ensemble of machine learning models with soft voting
Recommends recipes based on user's category preferences and diabetes risk. Returns top 3 diabetes-friendly recipes and top 2 non-friendly recipes if diabetes risk is high, otherwise returns top 5 recipes
No input parameter descriptions across most tools. Parameters are typed but LLMs cannot infer meaning from names alone. E.g., 'record' in predict(), 'content' in parse_json(), 'risk_score' and 'user_data' in call_deepseek_model() lack any guidance on format or constraints.
No output schemas documented for any tool. LLMs cannot plan downstream tool calls or extract required data when they do not know what fields to expect in responses. E.g., does recommend_recipes_for_user return a list, dict, DataFrame, or JSON string?
Tool naming does not follow verb_noun pattern. Generic names like 'predict', 'parse_json', and 'handle_user_input' do not clearly convey intent. LLMs rely on names to infer action before reading descriptions.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 37 | 2026-07-28+ | v2 |
Multiple tools combine unrelated responsibilities. handle_user_input does diabetes prediction, LLM inference, AND recipe recommendation, should be split into separate tools so agents can compose them independently.
Categorical input parameters lack enum constraints. E.g., 'gender' (handle_user_input), 'activity' (handle_user_input), 'scaler_name' (predict), 'model_list' (predict) should be enums; instead LLMs can hallucinate invalid values.
No error handling or recovery guidance. No tools document what happens on invalid input, API failure, or edge cases. LLMs have no guidance on whether to retry, ask the user, or give up.
No evidence of actual MCP server registration or tool definition in the codebase. Tool signatures appear to be Python functions in separate modules (core/induce.py, MCP/utils/*.py) but there is no visible MCP server initialization, ListTools handler, or CallTool implementation.
Parameter type 'numpy.ndarray' exposed in predict() schema. LLMs cannot instantiate NumPy arrays from chat input, this should be a list of floats with a description like 'Array of 4 floats: [Pregnancies, Glucose, BMI, Age]'.
All input parameters in handle_user_input() are typed as 'string' but semantically should be constrained: age is int, glucose is float, pregnancies is int, height/weight are floats. This forces LLMs to pass '25' instead of 25, and downstream code must parse strings.