Skip to main content
Glama
PDBe MCP Servers

PDBe MCP Servers

Official
by PDBeurope

ebi-pdbe-search

Read-onlyIdempotent

Run raw Solr queries against the PDBe search index to filter, facet, group, sort, and paginate protein structure results using fielded criteria.

Instructions

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.
        

Input Schema

NameRequiredDescriptionDefault
flNo
fqNo
rowsNo
sortNo
facetNo
groupNo
queryYes
startNo
paramsNo
filtersNo
facet_sortNo
group_mainNo
group_sortNo
facet_limitNo
group_fieldNo
group_limitNo
group_queryNo
facet_fieldsNo
group_formatNo
group_offsetNo
facet_queriesNo
group_ngroupsNo
facet_mincountNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv2.0.1

TDQS

A3.5/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds useful behavioral context beyond that: raw q handling, the text copy field, fq object conversion, pagination controls, and expected output structure. It still omits important operational details such as default row limits or maximum result caps.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with purpose and important Solr-specific notes, and the example input is helpful. However, the parameter list is lengthy and the output-format paragraph contains vague filler rather than precise return-value guidance.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex 23-parameter search tool with no output schema, the description provides a workable example and describes the output shape. It remains incomplete because it omits several grouping parameters and does not point agents to field discovery via ebi-pdbe-search_schema or document default pagination limits.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 23 parameters and 0% schema description coverage, the description must carry parameter meaning. It documents most parameters, including aliases and fq object conversion, but omits group_main, group_query, group_format, and group_ngroups, and several explanations are shallow or tautological.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: it executes a search query against the PDBe Solr search service and exposes Solr query parameters. The purpose is clear, but it does not distinguish this generic search tool from the many specific PDBe sibling tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains how to write Solr queries but gives no guidance on when to use this tool versus the numerous specific PDBe endpoint tools or the sibling ebi-pdbe-search_schema tool. There are no exclusions, alternatives, or routing hints.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools