Loading ToolBench
FastMCP server for pediatric cancer research that exposes tools, resources, and prompts for Claude Desktop integration. Provides semantic search over St. Jude research papers and clinical trials using FAISS vector index and Bedrock LLM.
This server exposes 4 pediatric research tools via FastMCP with STDIO transport. Tool definitions are present but exhibit significant quality gaps: descriptions are present but generic/incomplete, parameter schemas lack type information in several cases, and error handling is minimal. The tools follow basic naming conventions (verb_noun) but lack the depth needed for production reliability. Per-tool analysis: search_pediatric_research has a reasonable description (110 chars) and basic schema but 'top_k' lacks range constraints; ask_pediatric_research_question lacks input schema detail and offers no recovery guidance when context is empty; get_clinical_trials declares a status parameter as 'not yet implemented' which signals incomplete design; get_research_document has a decent description but no output schema visible. Overall, this is a typical community MCP server with functional but underdeveloped tool definitions.
Ask a question about pediatric cancer research and get a cited answer. The answer is generated using Claude and cites sources from St. Jude research papers and clinical trials.
List St. Jude clinical trials in the database.
Get details for a specific research document.
Search the St. Jude pediatric cancer research database. Use this to find relevant research papers and clinical trials related to pediatric cancer topics.
Parameter schemas lack proper type constraints. 'top_k' in search_pediatric_research declares integer type but provides no minimum/maximum bounds. No constraint documentation prevents LLMs from passing absurd values (0, -1, 999999) that break retrieval logic.
ask_pediatric_research_question provides no error recovery guidance. When no context chunks are found, it returns a generic no-context response (build_no_context_response) without telling the LLM why it failed or what to try next. Pattern:recovery-guide requires 'What to do next' in error responses.
get_clinical_trials declares a 'status' parameter with description 'Optional filter by status (not yet implemented)'. This signals incomplete tool design and will confuse LLMs, they will pass status values that have no effect, leading to silent failures and wasted context.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 47 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 8 | - | v1 |
Output schemas are not documented in tool definitions. Callers cannot predict return field names/types (e.g., does search return 'document_id' or 'doc_id'? Is 'score' a float 0-1 or a percentage?). Without documented schemas, LLMs waste tokens reverse-engineering outputs or fail to chain tools.
Parameter descriptions are generic or absent context. 'Search query (e.g., "acute lymphoblastic leukemia treatment")' includes an example value that LLMs may reuse literally. Pattern:tool-description requires replacements: use enums or format constraints instead of example values.
Pagination is not implemented. search_pediatric_research and ask_pediatric_research_question both hardcode top_k=5 as default. Large result sets are not paginated, if a query matches 100 documents, all 100 chunks could be returned, blowing context window. Pattern:paginated-result requires offset/limit and result totals.
No input validation or sanitization visible in tool implementations. Tools accept raw LLM-provided strings (query, question, document_id) without checking length, special characters, or SQL injection risk. Pattern:tool-gateway requires treating all agent input as untrusted.
Tool composition is incomplete. There are no discovery tools (e.g., list_available_topics, list_document_types) to help agents understand the database structure before querying. Agents must guess valid query topics, increasing failure rates.