Skip to main content
Glama
rcsb

io.github.rcsb/rcsb-mcp

Official
by rcsb

rcsb_search_fulltext

Read-onlyIdempotent

Search Protein Data Bank structures using free-text keywords, and refine results with structured attribute filters for targeted discovery.

Instructions

Search the PDB by free-text keywords (e.g. "CRISPR Cas9", "hemoglobin"), optionally refined with structured attribute filters.

Best for broad or exploratory keyword lookups. Pass attributes to AND/OR the keyword with structured conditions (organism, resolution, method, dates, ...) in one query. When a request has NO keyword (only attributes), use rcsb_search_by_attribute; when it resolves to a clear attribute/value, prefer structured search (call rcsb_list_pdb_search_attributes for the exact path — more precise, avoids spurious keyword matches). For a sequence, structure, chemical or motif match, use the matching rcsb_search_by_* tool (each also takes attributes).

BEFORE keyword-searching a biological CONCEPT (disease/function/domain/enzyme/organism), resolve it to an ontology id and filter on the annotation instead — see the resolver and assembly/multimer guidance in the server instructions. Matching spans ALL text annotations, so judge each hit yourself; a high score is text-relevance, NOT biological importance — never tell the user one hit is better than another because its score is higher.

Args: query: Free-text terms matched (case-insensitively) against all text annotations. Quote a phrase to require adjacency (e.g. '"DNA polymerase"'); separate words narrow the results; trailing '' is a prefix wildcard. AND/OR/NOT are NOT boolean operators here. attributes: Optional structured conditions combined with the keyword — AttributeFilter {attribute, operator, value, negation?, case_sensitive?} (see rcsb_search_by_attribute / rcsb_list_pdb_search_attributes for paths and operators). logical_operator: Combine the keyword with the attribute conditions (default "and"). return_type: What to return (default "entry"); see the "Return types and fetching details" note in the server instructions. limit: Max number of hits to return (1-100). offset: Number of hits to skip, for paging; pass the response's next_offset back with the same query to fetch the next page. all_hits: Return the COMPLETE result set in one call, for an explicit "ALL ..." request. Ignores limit and omits paging; can't be combined with offset (the Search API rejects pagination here); refused above 10000 hits — narrow, aggregate with facets, or page. include_computed_models: Also search computed structure models (AlphaFold etc.). chemical: Set True when attributes target chemical-component attributes (the text_chem service; usually pair with return_type="mol_definition"). facets: Optional aggregation specs to return a breakdown / distribution instead of hits (see the faceting note in the server instructions for the spec). sort_by: Attribute path to order the hits by; omit to sort by relevance score. Only SORTABLE attributes work: those listing exact_match (strings) or equals (numbers/ dates) in rcsb_list_pdb_search_attributes; full-text-only attributes (e.g. struct.title) and return_type="mol_definition" are rejected. sort_direction: "asc" (default) or "desc"; applies only when sort_by is set. group_by, group_by_ranking: Collapse redundant polymer_entity hits into clusters, one representative each (needs return_type="polymer_entity") — see the grouping note in the server instructions. Returns: {total_count, returned, offset, has_more, next_offset, hits:[{id, score}], editor}; hits are ids only — batch them into rcsb_get_entries (or the rcsb_get_ tool matching return_type). all_hits/facets response variants: see the server instructions.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNo
queryYes
facetsNo
offsetNo
sort_byNo
all_hitsNo
chemicalNo
group_byNo
attributesNo
return_typeNoentry
sort_directionNoasc
group_by_rankingNo
logical_operatorNoand
include_computed_modelsNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Behavior5/5

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

Annotations declare readOnly, idempotent, openWorld hints, and description adds far more: score is text-relevance not biological importance, matching spans ALL text annotations, all_hits limitations (ignores limit, can't combine with offset, refused above 10000), sort_by restrictions (only SORTABLE attributes). This adds significant behavioral context beyond annotations.

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

Conciseness5/5

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

Although long, the description is dense and front-loaded: purpose first, then usage guidance, then per-parameter args. It avoids repetition by referencing server instructions for faceting, grouping, and return types. Every sentence contributes actionable information, making it appropriately sized for a 14-parameter tool.

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

Completeness5/5

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

With 14 parameters, rich annotations, and an output schema, the description covers query syntax, paging, return types, limits, sorting, grouping, and return format ('hits are ids only — batch them into rcsb_get_entries'). It also explains the meaning of score and warns against misinterpreting relevance. The tool is fully specified for correct invocation.

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

Parameters5/5

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

Schema coverage is 0% and description compensates fully. Every parameter is explained with operational detail: query syntax (quoting, prefix wildcard, AND/OR/NOT not boolean), attributes type, logical_operator, limit range, offset paging, all_hits behavior, chemical switch, facets, sort_by constraints, group_by semantics. This goes well beyond the schema's bare titles.

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

Purpose5/5

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

The description opens with a specific verb+resource: 'Search the PDB by free-text keywords' with concrete examples ('CRISPR Cas9', 'hemoglobin'). It explicitly distinguishes itself from sibling tools: 'Best for broad or exploratory keyword lookups' and contrasts with rcsb_search_by_attribute, rcsb_search_by_sequence, etc.

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

Usage Guidelines5/5

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

Provides explicit when-to-use and when-not-to-use guidance: 'When a request has NO keyword (only attributes), use rcsb_search_by_attribute'; 'prefer structured search'; 'For a sequence, structure, chemical or motif match, use the matching rcsb_search_by_* tool'. Also advises resolving biological concepts to ontology IDs. This is exemplary alternative selection guidance.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/rcsb/rcsb-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server