interpro-mcp-server

Map structure domains

interpro_get_structure_domains

Read-onlyIdempotent

Retrieve InterPro and member-signature matches on one PDB entry's protein chains. Each chain record keeps match locations in chain numbering (1-based start/end beside author auth_start/auth_end, which can be null), in UniProt numbering, and the chain-to-UniProt residue map, with discontinuous fragments preserved; the UniProt protein is null for unmapped chains. InterPro nests at most 20 chain records per match; set chain to read one chain completely. Budgeted segments hold whole matches; the first carries structure metadata listing the protein chains. Continue coverage.nextCursor until hasMore is false.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "pdbId": "<pdbId>"
    },
    "name": "interpro_get_structure_domains"
  }
}

Input Schema

Name	Required	Description
`chain`	No	Protein chain to map, case-sensitive and one of structure.chains, such as A; omit for every chain.
`pdbId`	Yes	Four-character PDB ID such as 1tsr; case-insensitive. Extended pdb_0000… IDs are not supported.
`cursor`	No	Opaque coverage.nextCursor with unchanged pdbId and chain.

Output Schema

Name	Required	Description
`cap`	No	Most matches one call reads; a segment can stop sooner at the response byte budget.
`url`	No	Canonical structure website URL.
`chain`	No	Chain the map is restricted to, when one was set.
`error`	No	Present when the call failed. Absent on success.
`pdbId`	No	Lowercase PDB ID.
`shown`	No	Whole matches in this segment.
`notice`	No	Interpretation, continuation, or recovery guidance.
`matches`	No	Whole matches in this segment, in upstream order; never split across segments.
`coverage`	No	Where this segment sits in the structure map.
`structure`	No	Complete upstream structure metadata on the first segment, the call without cursor; continuation segments omit it.
`truncated`	No	More segments remain.
`sourceUrls`	No	Official API URLs this call read.
`structures`	No	Every chain record of this segment’s matches, grouped by match in matches order.
`totalCount`	No	Upstream total matching records.
`effectiveQuery`	No	Applied pdbId and chain as JSON.

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 28, 2026

TDQS

A3.7/5.0

Behavior4/5

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

Adds substantial context beyond the read-only/idempotent annotations: 1-based chain numbering with possibly-null auth_start/auth_end, discontinuous fragments preserved, null UniProt for unmapped chains, and a 20-chain-record nesting cap per match. Pagination semantics and the first-segment metadata are also disclosed; only permissions/error behavior is absent, which matters little for a read-only tool.

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?

Front-loaded with the purpose, then dense but purposeful detail; every clause carries information about response shape. Phrasing like 'Budgeted segments hold whole matches' is jargon-heavy and slows parsing, but nothing is wasted.

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?

An output schema exists, so much of the return-shape prose is somewhat redundant, but the truncation/nesting rule and cursor continuation are behavioral facts an output schema alone may not convey. Nothing an agent needs to call this correctly is missing.

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?

Schema coverage is 100%, so the schema already defines pdbId, chain, and cursor including formats and patterns. The description adds only the reason to set chain (to avoid the 20-record nesting truncation), which is a modest supplement to a fully documented schema.

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?

States a specific verb and resource: retrieve InterPro and member-signature matches on a PDB entry's protein chains. That scope is clearly distinct from the UniProt-centric sibling interpro_get_protein_domains, though the description never names the distinction explicitly.

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

Usage Guidelines3/5

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

Gives procedural guidance ('set chain to read one chain completely', 'Continue coverage.nextCursor until hasMore is false') but never says when to choose this over interpro_get_protein_domains or interpro_get_scan_result. Usage is implied by the PDB-entry framing rather than stated.

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

All interpro-mcp-server tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.