Map an Rfam accession to PDB entries and RNA chains, returning matched regions so you can link RNA families to available structural data.
This call returns all PDB entries and RNA chains that map to the specified Rfam accession, including the matched regions.
| Name | Required | Description | Default |
|---|---|---|---|
| accession | Yes | Rfam accession or PDB ID type: string title: Accession description: Rfam accession or PDB ID |
Changes observed during successful MCP inspections.
v2.0.1Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered; the description adds value by naming the return content (PDB entries, RNA chains, matched regions). However, it says nothing about result size, pagination, or the odd idempotentHint=false on what appears to be a pure lookup, and does not explain what happens when the accession matches nothing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One front-loaded sentence with no filler, and the return content is stated before any nuance. It earns its place but is minimal; the string is essentially identical to the tool title, so the description contributes no framing beyond the annotation title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read-only tool with no output schema, the description adequately says what comes back, which is the main thing an agent needs. It is still thin on the accession-type ambiguity (Rfam accession vs PDB ID) and on response shape or limits, so it is only just sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the single parameter is fully documented in the schema and the baseline is 3. The description only restates that the accession identifies an Rfam family; it notably does not echo the schema's claim that a PDB ID is also accepted, leaving a small inconsistency between schema and description for the agent to resolve.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a concrete verb and resource: it returns PDB entries and RNA chains mapped to an Rfam accession, plus the matched regions. That distinguishes it from most siblings, but it gives no signal for telling it apart from the closely named sibling ebi-pdbe-maps_maps_acc, whose name suggests an overlapping mapping capability.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to choose this tool over ebi-pdbe-maps_maps_acc or the many ebi-pdbe entity-specific tools. The agent must infer from the word 'Rfam' that this is the RNA-family mapping path, and nothing states prerequisites, exclusions or typical workflows.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.