Loading ToolBench
A Model Context Protocol (MCP) server for accessing PDBe (Protein Data Bank in Europe) structural biology data and services
The server provides 8 tools with schemas and descriptions. Most tools have reasonable naming conventions (get_pdbe_*, pdbe_run_*, pdbe_graph_*) but descriptions vary significantly in depth and quality. Tool schemas are present but parameter descriptions are inconsistent. The most complex tool (run_pdbe_search_query) has a very thorough description and comprehensive schema with multiple parameter types, while simpler schema-discovery tools have minimal descriptions. Error handling and output format guidance are present in some tools but not universally applied. No evidence of tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite most tools being read-only.
Retrieves the search schema for the PDBe Solr search service
Retrieves the search schema for the PDBe Solr search service, including available fields for searching
Retrieves metadata about all relationship types (edges) defined in the PDBe (PDBe-KB) graph database schema. This tool can be used to understand the different types of relationships represented in the PDBe graph database, along with their start and end nodes, properties and descriptions and then can be used to explore the graph more effectively by writing Cypher queries. This tool returns detailed information about each relationship (edge) in the graph. For every relationship type, it includes: - The relationship label (e.g., 'HAS_OUTLIER', 'CONNECTS_TO') - A human-readable description of the relationship - The 'from' node label and 'to' node label, defining the direction and connectivity - A list of properties associated with the relationship - For each property: the name and a brief description Expected Output Format (text): Label: HAS_OUTLIER Description: Indicates a structure has validation outliers From: Structure To: ValAngleOutlier Properties: - since: The date when the outlier was detected - severity: The severity level of the outlier (Additional relationship types follow the same format...)
Provides example Cypher queries that can be used to explore the PDBe graph database
Duplicate tool definition: 'get_pdbe_search_schema' is registered twice (lines 6 and 8 in tools list). This creates ambiguity for LLM tool selection and registration.
Minimal description for 'pdbe_graph_example_queries': only 62 characters ('Provides example Cypher queries that can be used to explore the PDBe graph database'). Does not explain WHEN to use it, WHAT structure it returns, or HOW the examples should be interpreted. LLMs cannot reliably choose this tool over others.
Missing parameter descriptions for tools with empty input objects: 'pdbe_graph_nodes', 'pdbe_graph_edges', 'pdbe_graph_example_queries', 'get_pdbe_search_schema'. While these tools accept no parameters, the description should clarify that and hint at the returned structure or ordering.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 62 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 25 | - | v1 |
Verifies one or more PDBe graph node labels and returns the relationships connected to each label. Use this tool after inspecting the node and edge schema, when you have selected node labels for a Cypher query and want to confirm that the labels and relationship directions exist in the PDBe graph schema. For each requested node label, this tool returns: - Whether the node label exists in the schema - Outgoing relationship patterns from that node label - Incoming relationship patterns to that node label - Self-loop relationship patterns where both ends use the same node label - A bidirectional note when the schema has the same relationship label in both directions between two node labels Parameters: node_labels (required): A list of exact, case-sensitive node labels to verify. Example: ["Entry", "Entity", "UniProt"] Expected Output Format (text): Node: Entry Status: Found Outgoing edges: - (Entry)-[:HAS_ENTITY]->(Entity) Incoming edges: - None Self-loop edges: - None Node: FakeNode Status: Not found in schema
Retrieves metadata about all node types (also known as "labels") defined in the PDBe (PDBe-KB) graph database schema. This tool can be used to understand the different types of entities represented in the PDBe graph database, along with their properties and descriptions and then can be used to explore the graph more effectively by writing Cypher queries. This tool returns detailed information about each node label in the graph database. For every node label, it includes: - The label name (e.g., 'ValAngleOutlier', 'Antibody', 'Atom') - A human-readable description of the node type - A list of properties/parameters associated with this node type - For each property: the name and a brief description Expected Output Format (text): Label: ValAngleOutlier Description: Bond angle outliers based on wwPDB validation data. Properties: - ATOM0/1/2/3: Names of atoms involved in the angle which is an outlier. - MEAN: The ideal value of the bond angle. - OBS: The observed value of the bond angle. (Additional node labels follow the same format...)
Executes read-only Cypher queries against the PDBe (PDBe-KB) graph database (Neo4j) to retrieve structural biology data and relationships
Executes a search query against the PDBe Solr search service. This tool exposes common Solr query parameters directly so users can construct fielded queries, filter queries, field lists, facets, grouping, sorting, and pagination against the PDBe search index. IMPORTANT: `query` is passed to Solr as the raw `q` parameter. Use Solr query syntax such as `*:*`, `pdb_id:1cbs`, `text:*kinase*`, boolean clauses, ranges, and boosts as needed. IMPORTANT: the `text` field is a copy field that contains the full searchable text aggregated from the document. Use `text:*<term>*` when you want a broad wildcard text search. Expected Input Parameters: - query (string): Raw Solr query string passed as `q`. - fl (string or list of strings, optional): Solr field list. The legacy `filters` parameter is also accepted as an alias. - filters (list of strings, optional): Backwards-compatible alias for `fl`. - fq (string, object, list of strings, or list of objects, optional): Solr filter query or queries to narrow down the search results. Objects are converted to fielded filters, e.g. {"experimental_method": "X-ray diffraction"} becomes experimental_method:"X-ray diffraction". - sort (string, optional): The sorting criteria for the search results. - start (integer, optional): The starting index for pagination of results. - rows (integer, optional): The number of results to return. - facet (boolean, optional): Enable Solr faceting. - facet_fields (string or list of strings, optional): Field facets, sent as `facet.field`. - facet_queries (string or list of strings, optional): Query facets, sent as `facet.query`. - facet_limit, facet_mincount, facet_sort (optional): Common facet controls. - group (boolean, optional): Enable Solr grouping. - group_field (string or list of strings, optional): Grouping field, sent as `group.field`. - group_limit, group_offset, group_sort (optional): Common grouping controls. - params (object, optional): Additional Solr parameters to pass through for advanced use. Example Input: { "query": "text:*kinase*", "fl": ["pdb_id", "title", "deposition_date"], "fq": ["experimental_method:\"X-ray diffraction\""] , "facet": true, "facet_fields": ["experimental_method"], "sort": "deposition_date desc", "start": 0, "rows": 10 } Expected Output Format: A text representation of the search results, formatted in a readable manner. The output will include: - Metadata about the search results (e.g. number of documents found, start index). - A list of documents matching the search query, with each document's fields and values clearly presented. The output will be structured to facilitate easy interpretation of the search results, allowing users to quickly identify relevant information.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) declared in tool definitions. All 8 tools are READ-ONLY per the Risk field, but this information is not exposed in the tool registration. Agents cannot infer whether a tool is safe to retry or has side effects without explicit annotations.
Output schema not documented for most tools. Tools like 'pdbe_graph_nodes', 'pdbe_graph_edges', and 'get_pdbe_search_schema' describe their output format in natural language within the description (e.g., 'Expected Output Format (text)'), but do not provide a formal output schema. LLMs cannot plan downstream tool chaining without knowing the exact structure of returned fields.
Inconsistent error handling guidance. The 'pdbe_run_cypher_query' tool description includes query validation rules (MATCH, OPTIONAL MATCH, CALL only; no CREATE, MERGE, DELETE, etc.), but does not specify what error message an invalid query will produce or how the LLM should recover. Other tools have no error handling documentation.
The 'run_pdbe_search_query' tool accepts a highly flexible 'params' object (additionalProperties: { oneOf: [string, number, integer, boolean, array] }). No validation or enumeration of allowed Solr parameters is documented. LLMs may pass invalid Solr parameters and receive cryptic errors.