Loading ToolBench
MCP Servers for using the RDF Portal - provides tools for searching and querying biological databases including UniProt, PubChem, PDB, NCBI, KEGG, and more through the RDF Portal
TogoMCP provides 11 read-only search and query tools with consistent naming patterns and basic parameter documentation. All tools follow verb_noun naming (search_*, run_*), which is excellent. However, descriptions are generic (10 - 20 chars typical), parameter annotations lack depth, output schemas are not explicitly documented, and error handling recovery guidance is absent. The server targets a specialized domain (biomedical data discovery) where tool reusability and composition are secondary concerns, but the definitions could be more LLM-friendly for agent planning and error recovery.
Execute a SPARQL query against the RDF Portal SPARQL endpoints
Search for genetic variants and clinical interpretations in ClinVar database
Search for genes by name, symbol, or other identifiers in NCBI Gene database
Search for medical genetics concepts and conditions in MedGen database
Search for Medical Subject Headings (MeSH) terms and descriptors in MeSH database
Search for biological screening data in PubChem BioAssay database
Search for unique chemical structures in PubChem Compound database
Search for depositor-provided chemical records in PubChem Substance database
Tool descriptions are extremely generic and under 50 characters. e.g., 'Search for UniProt entities (proteins, genes) by keyword query' (59 chars). These lack WHEN/WHY context (e.g., when would an agent call this vs another NCBI tool?), making tool selection harder for LLMs.
Output schemas not documented in source. The code shows parameter input schemas (query, limit, search, etc.) but no explicit documentation of what fields are returned from NCBI/UniProt/EBI APIs. Without output schema docs, LLMs cannot plan follow-up tool calls or extract required fields (e.g., does search_ncbi_gene return gene_id? symbol? chromosome?).
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 58 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Search biomedical literature in PubMed database
Search for organisms and taxonomic information in NCBI Taxonomy database
Search for UniProt entities (proteins, genes) by keyword query
Error handling lacks recovery guidance. The code shows retry logic and HTTP error collapsing (e.g., '_strip_html()' for error pages) but no tool-level error documentation. If a search fails, the tool returns an error envelope but does not guide the LLM on next steps (e.g., 'Try a simpler query', 'Fall back to SPARQL', 'Check the database documentation'). Pattern: recovery-guide.
Parameter alias naming confuses intent. All 10 search_ncbi_* and search_uniprot_entity tools accept 7 aliases for the same 'query' parameter (query, search, term, keyword, keywords, search_term, name). The description for each alias says 'Alias for `query`, pass ONE of ...' This is verbose and does not clearly communicate WHY there are so many aliases. Per the rubric, LLMs conflate similar names and need clarity. Consider reducing to 2 - 3 most common aliases (e.g., query + search) or one canonical parameter.
Parameter 'database' for run_sparql lacks enum or pattern constraint. The description says 'Target RDF Portal database/endpoint' but does not list valid values (e.g., what databases are available?). LLMs cannot infer valid choices and will hallucinate database names. Per the rubric, free-form strings invite hallucinated values; enums are self-documenting.
Pagination not explicitly documented. Parameter 'limit' is present (default 20) but no mention of offset, page, or cursor for retrieving additional results. The API likely supports pagination (typical for NCBI/EBI), but the tool definitions do not expose it. Per the rubric, tools returning lists should accept page/offset and return a total count or next_cursor.