Loading ToolBench
A FastAPI-based backend service for managing blood bank inventory, donors, donation camps, and analytics with admin controls and blood search functionality
This MCP server exposes a FastAPI-based blood bank management system with 22 tools. While the backend is well-structured, the tool definitions visible in source lack essential MCP-specific documentation. Most tools have minimal or generic descriptions (typically 1-3 sentences), parameter descriptions are sparse or missing entirely, and output schemas are not explicitly documented. Many tools lack proper input parameter type definitions in the schema. The server was not built with agentic composition in mind, tool names are action-verbs but descriptions do not explain WHEN to use each tool vs similar alternatives (e.g., list_blood_banks vs list_blood_banks_admin appear to have identical purpose). No evidence of error handling patterns that guide LLM recovery. Security concerns: login endpoint accepts username/password as query parameters (visible in FastAPI code), which is a credential leak risk if logged. Overall, this is a functional REST API transplanted into MCP without agentic refinement.
Adds blood inventory records to a blood bank
Welcome admin endpoint that returns a greeting message for the authenticated admin
Creates a new blood bank record with provided details
Creates a new blood bank with specified name, city, and coordinates
Creates a new donation camp record
Deletes a blood bank record from the system
Retrieves all inventory logs ordered by creation date in descending order
Duplicate tools with unclear distinction: list_blood_banks, list_blood_banks_admin, and create_blood_bank, create_blood_bank_admin appear to provide overlapping functionality with confusing name variants. LLMs cannot determine which variant to call without clearer naming or merged descriptions.
Minimal or generic descriptions across all tools. Most descriptions are 1-3 sentences and do not explain WHEN to use the tool, what distinguishes it from similar tools, or what the LLM should expect to receive. Baseline: A-grade tools have 50-200 char descriptions that are LLM-optimized.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 48 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 54 | - | v1 |
Returns donors of a specific blood group ranked by priority score based on location proximity
Health check endpoint that returns service status
Predicts inventory risk based on recent depletion trends
Returns a summary of inventory with total units per blood group
Retrieves all blood banks from the database
Retrieves all blood banks (admin endpoint)
Retrieves all donation camps
Retrieves all blood inventory records
Retrieves all inventory logs ordered by creation date in descending order
Retrieves upcoming active donation camps (from current time onwards)
Admin login endpoint that authenticates with username and password and returns an access token
Returns blood groups with inventory below the specified threshold
Registers a new donor, preventing duplicate phone numbers
Searches for blood banks with available blood of a specific group within a radius, sorted by distance
Updates an existing blood bank record with new details
Input schemas incomplete for many tools. Tools like create_blood_bank, update_blood_bank, create_camp, and register_donor accept 'data' parameter of type 'object' with no nested schema or field definitions. LLMs cannot infer valid fields without a detailed schema.
No output schema documentation visible. None of the tools document what fields are returned or the structure of the response. LLMs need explicit output schemas to plan downstream tool calls and extract data correctly.
Credentials exposed in parameters. The login endpoint accepts username and password as direct parameters. In FastAPI, these are typically logged as query parameters. Per MCP security pattern, credentials must use server-side injection via environment variables or vault.
No permission-checking or role documentation in tool definitions. Tools like delete_blood_bank and update_blood_bank are destructive/sensitive but do not declare required permissions or scope. Agents need to understand what authority a tool requires.
No error recovery guidance in descriptions. Descriptions do not explain what can go wrong, what error codes are possible, or what the LLM should do if a call fails. Agents have no recovery strategy when operations fail.
Missing parameter descriptions. Many tools accept parameters without accompanying descriptions explaining their constraints, format, or allowed values. For example, 'blood_group' appears in multiple tools but is never described as an enum (O+, O-, A+, A-, B+, B-, AB+, AB-).
Numeric parameters lack bounds documentation. Parameters like 'threshold', 'days', 'radius_km', 'units' have min/max constraints (Query gt=0) in FastAPI code, but these are not visible in the tool descriptions provided. LLMs cannot infer valid ranges without explicit documentation.
No pagination or result limits documented. Tools that return lists (list_blood_banks, list_inventory_logs, list_camps, list_inventory_admin) do not specify maximum result sizes, pagination parameters, or total count. Large result sets could exhaust LLM context windows.
Destructive operations lack confirmation pattern. delete_blood_bank is a destructive operation with no dry-run, confirmation, or undo capability documented. Agents need confirmation prompts before irreversible changes.