MCP server that provides tools to help users access biological data resources from the Swiss Institute of Bioinformatics (SIB) through the SPARQL query language, using Retrieval-Augmented Generation (RAG) and SPARQL query validation.
The server provides 5 tools with varying quality. All tools have descriptions and input schemas are present, but there are significant gaps in parameter documentation, schema completeness, and error handling guidance. Tool names follow verb-noun conventions (search_, get_, access_, execute_) which is good. However, parameter descriptions lack actionable detail, output schemas are not documented, and some tools have overlapping functionality that could be consolidated. The descriptions are adequate (101-200 chars range) but lack specificity about when to call each tool and what makes them distinct.
Assist users in writing SPARQL queries to access SIB biodata resources by retrieving relevant examples and docs. Covers topics such as genes, proteins, lipids, chemical reactions, and metabolomics data. Args: question: The question to be answered with a SPARQL query potential_classes: High level concepts and potential classes that could be found in the SPARQL endpoints steps: Split the question in standalone smaller parts if relevant (if the question is already 1 step, leave empty) Returns: Relevant documents (examples, classes schemas)
Execute a SPARQL query against a SPARQL endpoint. Args: sparql_query: A valid SPARQL query string endpoint_url: The SPARQL endpoint URL to execute the query against Returns: The query results in JSON format
Search for specific classes and their schema in the SPARQL endpoints. Args: classes: High level concepts and potential classes that could be found in the SPARQL endpoints Returns: Relevant classes schemas in ShEx format
Get information about the SPARQL endpoints indexed by this MCP server. Only call this tool when the user explicitly asks for information about the resources themselves. Args: question: The user's question about the resources Returns: Information about available SPARQL endpoints and their content
Overlapping tool functionality: search_sparql_docs and access_sib_biodata_sparql have nearly identical signatures and purposes. LLMs will waste reasoning cycles deciding between them. This violates the single-responsibility principle and increases decision overhead.
Output schemas not documented. The tools lack descriptions of what fields are returned (e.g., execute_sparql_query returns 'JSON format' but does not specify whether it's an array, object, what the structure is). LLMs cannot plan downstream operations without knowing result structure.
Parameter descriptions lack actionable constraints. For example, 'potential_classes' is described as 'High level concepts and potential classes' but does not specify format (is it a comma-separated string? free-form? constrained to SPARQL ontology classes?). The 'endpoint_url' parameter has no validation guidance (protocol required? timeout expectations?).
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 69 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 46 | - | v1 |
Retrieve relevant SPARQL query examples and classes schema to write queries to answer user questions related to biological data resources Args: question: The question to be answered with a SPARQL query potential_classes: High level concepts and potential classes that could be found in the SPARQL endpoints steps: Split the question in standalone smaller parts if relevant (if the question is already 1 step, leave empty) Returns: Relevant documents (examples, classes schemas)
No error handling guidance. Tools do not explain what errors can occur or how to recover. For example, execute_sparql_query could fail due to malformed query, unreachable endpoint, timeout, or invalid credentials, but LLMs are given no recovery hints.
Tool naming ambiguity: 'access_sib_biodata_sparql' uses 'access' which is vague, does it query, retrieve docs, or something else? Clearer alternatives: 'search_sib_biodata_docs' or 'get_sib_biodata_examples'.
Parameter 'steps' in search_sparql_docs and access_sib_biodata_sparql is poorly motivated. The description says 'Split the question in standalone smaller parts if relevant (if the question is already 1 step, leave empty)', but this is better handled inside the tool, not exposed as a parameter. Requiring the LLM to decompose the question adds unnecessary complexity.