How do I use reactome-db-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@reactome-db-mcp list child events of R-HSA-69278" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

reactome-db-mcp

by tc2fh

Overview Schema Related Servers Score Discussions

Python

Local

reactome-db-mcp

An MCP server that gives coding agents direct SQL access to a locally hosted Reactome database — schema discovery, a guarded read-only query(), and ergonomic helpers over the full GKB relational schema, all from the chat.

Python 3.12+ MCP License: MIT

Built with the official Python MCP SDK (FastMCP) over stdio. It talks straight to MySQL with pure-Python PyMySQL (run via asyncio.to_thread), so there is no build toolchain to install.

`reactome-db-mcp` vs `reactome-mcp`

They are complementary — register both:

	`reactome-mcp` (REST)	`reactome-db-mcp` (this)
Backend	Reactome REST + Analysis web services	local `reactome_local` MySQL DB
Needs	internet; zero setup	the local DB up (MySQL + dump loaded)
Strength	curated, pre-joined objects; enrichment p-values/FDR; always current	fast, arbitrary joins + reverse navigation over the raw 242-table schema
Use it for	"what does Reactome say about X", enrichment	bespoke relational queries the REST API never exposed

Tool names are deliberately distinct (get_object vs get_entry, search_by_name vs search, …) so both can be registered without ambiguity.

Prerequisites — the local database

This server needs a running MySQL with the Reactome gk_current dump loaded as reactome_local, reachable by a read-only user. On this machine that is already set up:

MySQL 9.6 (Homebrew), database reactome_local (~990 MB, 242 MyISAM tables, Reactome release 96).
Read-only user ro_user@localhost, empty password, SELECT-only.

If mysqld isn't running (it is not registered with brew services, so it won't survive a reboot):

brew services start mysql      # reliable auto-start, or:  /opt/homebrew/opt/mysql/bin/mysqld_safe &

To rebuild the DB from scratch, see ../reactome_local_build (keeps gk_current.sql.gz).

Related MCP server: mcp-server-database

Quickstart

Requires uv (which manages Python ≥ 3.12 for you).

cd reactome-db-mcp
uv sync                     # install runtime deps (mcp, PyMySQL)
uv run reactome-db-mcp      # boots the server on stdio (Ctrl+C to exit)

Then register it with your agent (below) and ask something like:

"Using the reactome-db tools, look up R-HSA-69278, then list its child events in order."

Register with your agent

Standard stdio MCP server launched with uv run reactome-db-mcp. Run from inside the cloned directory.

Claude Code

claude mcp add reactome-db -- uv --directory "$PWD" run reactome-db-mcp

Codex

codex mcp add reactome-db -- uv --directory "$PWD" run reactome-db-mcp

Cursor / any other MCP client — point it at the same stdio command; a ready-to-edit example lives in .mcp.json:

{
  "mcpServers": {
    "reactome-db": {
      "type": "stdio",
      "command": "uv",
      "args": ["run", "--directory", "/absolute/path/to/reactome-db-mcp", "reactome-db-mcp"],
      "env": { "REACTOME_DB_NAME": "reactome_local" }
    }
  }
}

Tools

All tools are async and return JSON-shaped dicts, degrading to {"error": ...} rather than raising on bad input or a down database.

Schema discovery

Tool	Signature	Purpose
`schema_overview`	`()`	Primer on the class-table-inheritance model + key joins + data release. Read first. Also the `schema://reactome` resource.
`list_tables`	`(filter=None, limit=500)`	Tables with exact row counts + engine; `filter` is a name substring (e.g. `_2_`).
`describe_table`	`(table)`	Columns of a table: type, nullability, key, default.

Guarded raw SQL

Tool	Signature	Purpose
`query`	`(sql, max_rows=200)`	Run one read-only statement (`SELECT`/`WITH`/`SHOW`/`DESCRIBE`/`EXPLAIN`). Auto-`LIMIT`, per-query timeout, result/cell truncation.

Ergonomic helpers (sugar over the common joins)

Tool	Signature	Purpose
`get_object`	`(id)`	Assemble a full object (stable id or DB_ID) across its inheritance chain.
`search_by_name`	`(query, classes=None, limit=25, anchored=False)`	`_displayName` search; `anchored=True` is fast, wildcard is a ~1-2s scan.
`get_pathway_events`	`(id)`	Ordered child events of a pathway (via `Pathway_2_hasEvent`).
`get_participants`	`(id)`	Inputs / outputs / catalysts of a reaction-like event.
`get_referrers`	`(id, attribute=None, limit=50)`	Reverse lookup — which objects point at this one (curated/best-effort).

Design notes

Read-only by construction. The connection is a SELECT-only user (writes fail at the server), PyMySQL rejects stacked statements by default, and query() additionally checks that the statement is a single read. The string check is for clear errors, not as the security boundary — the grant is.
Stable ids vs DB_IDs. Helpers accept either R-HSA-69278 or the numeric DB_ID. The 'R-HSA-...' text lives in StableIdentifier, joined via DatabaseObject.stableIdentifier.
Size-guarded. Every result is row-capped (max_rows, hard ceiling 5000) and long text cells are truncated; truncated flags either.
Point-in-time data. This is a dump (release reported by schema_overview). For the always-current Reactome, use the sibling reactome-mcp.

Configuration (env vars)

Var	Default	Meaning
`REACTOME_DB_HOST` / `REACTOME_DB_PORT`	`127.0.0.1` / `3306`	MySQL endpoint
`REACTOME_DB_USER` / `REACTOME_DB_PASSWORD`	`ro_user` / `` (empty)	credentials
`REACTOME_DB_NAME`	`reactome_local`	database
`REACTOME_DB_POOL_SIZE`	`4`	max pooled connections
`REACTOME_DB_MAX_ROWS`	`200`	default row cap
`REACTOME_DB_STMT_TIMEOUT_MS`	`15000`	per-query timeout
`REACTOME_DB_MAX_CELL_CHARS`	`2000`	per-cell text cap

Example prompts

Lookup + drill-down — "Look up R-HSA-69278 with the reactome-db tools and list its child events in order."
Raw SQL — "Run SELECT _class, COUNT(*) FROM DatabaseObject GROUP BY _class ORDER BY 2 DESC LIMIT 10 and summarize."
Reverse navigation — "Which pathways and reactions reference the object named 'CYCB:CDK1'? Use get_referrers."
Schema spelunking — "Call schema_overview, then describe the Pathway and Pathway_2_hasEvent tables."

Development

uv sync --extra dev     # pytest, pytest-asyncio
uv run pytest           # safety-layer suite runs fully offline (no DB)

# opt-in live-DB integration tests (needs reactome_local up):
REACTOME_DB_MCP_INTEGRATION=1 uv run pytest

Smoke-test the live server:

uv run reactome-db-mcp                          # console script
uv run python -m reactome_db_mcp                # module entry point
uv run python server.py                         # source-checkout shim
uv run mcp dev src/reactome_db_mcp/server.py    # MCP Inspector dev UI

reactome-db-mcp/
├── src/reactome_db_mcp/
│   ├── server.py   # FastMCP app, lifespan pool, all tools + resource
│   ├── db.py       # PyMySQL pool + read-only safety layer (pure, tested)
│   └── schema.py   # curated schema primer + class-inheritance map
├── server.py       # source-checkout compatibility shim
├── tests/          # offline safety-layer suite + opt-in DB integration tests
├── pyproject.toml  # uv-managed project
├── .mcp.json       # example stdio MCP config
└── PLAN.md         # design & build record (verified 2026-06-22)

Acknowledgements

Powered by Reactome, a free, open-source, open-access, curated and peer-reviewed pathway database. Please cite Reactome when publishing work that uses this data — see https://reactome.org/cite.

This project is not affiliated with or endorsed by the Reactome team.

License

MIT © Tien Comlekoglu

Available Tools

9 tools

describe_tableA

Show the columns of a table: name, type, nullability, key, default, extra.

Args:
    table: Exact table name (see `list_tables`). e.g. "Pathway",
        "Pathway_2_hasEvent", "DatabaseObject".

Returns:
    Dict `{table, columns: [{name, type, nullable, key, default, extra}]}`.

ParametersJSON Schema

Name	Required	Description	Default
`table`	Yes

TDQS

A4.6/5.0

Behavior4/5

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

Describes return format comprehensively. Lacks details on error handling (e.g., table not found) but covers the core behavior well. No annotations, so description carries full burden.

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?

Two short paragraphs: purpose first, then args/returns. Every sentence is useful; no filler.

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?

Single parameter adequately explained, return format specified, and reference to sibling tool. Complete for an agent to invoke correctly.

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 has no description for the 'table' parameter, but the description provides crucial guidance: exact name from list_tables, with examples. This compensates fully for the schema gap.

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?

Clearly states it shows columns of a table with specific fields (name, type, nullability, key, default, extra). The verb 'show' and resource 'columns' are specific and distinguish it from siblings like list_tables.

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

Usage Guidelines4/5

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

Points to list_tables to get exact table name, implying the correct workflow. Does not explicitly state when not to use, but context is clear enough.

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

get_objectA

Fetch a full Reactome object, assembled across its inheritance chain.

Resolves a stable id ('R-HSA-69278') or numeric `DB_ID`, then merges the
`DatabaseObject` core fields with the subclass-table attributes that share
the same `DB_ID` (e.g. a Pathway pulls in `Event` + `Pathway` columns).

Args:
    id: An 'R-HSA-...' stable id or a numeric DB_ID.

Returns:
    Dict `{DB_ID, _class, _displayName, stable_id, attributes: {...}}` where
    `attributes` is the union of the subclass rows (leaf class wins on any
    name clash). `{"error": ...}` if the id is unknown.

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes

TDQS

A4.4/5.0

Behavior4/5

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

With no annotations, the description explains key behaviors: resolving IDs, merging subclass attributes, leaf class wins on clashes, and error response. Lacks mention of authorization or rate limits but is otherwise thorough.

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?

Well-structured with a brief overview, then Args and Returns sections. Information-dense without being verbose, though could be slightly more compact.

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?

Given simple single-parameter tool with no output schema, the description covers input format, return structure, and error handling. Sufficient 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 has only type string with no description; the description adds critical detail: id can be a stable ID like 'R-HSA-69278' or numeric DB_ID, and the return example reinforces usage.

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 clearly states 'Fetch a full Reactome object' and explains the inheritance chain assembly, distinguishing it from siblings like search_by_name or describe_table.

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

Usage Guidelines4/5

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

Provides clear context for when to use the tool (fetching by stable ID or DB_ID) and gives an example format. Does not explicitly list when not to use or mention alternatives, but context from sibling names implies their use cases.

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

get_participantsA

Get the inputs, outputs, and catalysts of a reaction-like event.

Args:
    id: A ReactionlikeEvent (Reaction/BlackBoxEvent/...) stable id or DB_ID.

Returns:
    Dict `{reaction_DB_ID, inputs, outputs, catalysts}` where `inputs`/
    `outputs` are physical-entity dicts and each `catalysts` entry also
    carries `catalyst_activity_DB_ID` and the GO `activity` DB_ID. Empty
    lists if the object isn't a reaction or has none.

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes

TDQS

A4.4/5.0

Behavior4/5

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

Without annotations, the description carries full burden. It discloses the input type (stable id or DB_ID), the return format including nested structures, and edge-case behavior (empty lists for non-reactions). This is thorough but could explicitly state read-only nature.

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?

The description is concise, using a clear structure: purpose statement, Args, Returns. Every sentence adds value without redundancy. It is front-loaded with the main action.

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?

Despite having only one parameter and no output schema, the description fully explains the return value structure, including nested dicts for inputs/outputs/catalysts and DB_ID fields. It also covers edge cases, making the tool's behavior completely clear.

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%, but the description adds crucial context: 'A ReactionlikeEvent (Reaction/BlackBoxEvent/...) stable id or DB_ID.' This clarifies what the single 'id' parameter represents, going beyond the schema's generic string type.

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 starts with 'Get the inputs, outputs, and catalysts of a reaction-like event,' clearly specifying the action and resource. It distinguishes itself from sibling tools like get_object or get_pathway_events by focusing on participants of reactions.

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?

The description implies usage for retrieving reaction participants but does not explicitly compare with sibling tools or state conditions to avoid using this tool. No when-not guidelines are provided.

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

get_pathway_eventsA

List the ordered child events (sub-pathways & reactions) of a pathway.

Args:
    id: A Pathway stable id ('R-HSA-69278') or numeric DB_ID.

Returns:
    Dict `{pathway_DB_ID, count, events: [{rank, DB_ID, _class,
    _displayName, stable_id}], truncated}`, ordered by `hasEvent_rank`.

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes

TDQS

A3.9/5.0

Behavior3/5

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

The description includes ordering by hasEvent_rank and return format, but lacks explicit safety/read-only declaration or truncation details; no annotations to supplement.

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?

Three sentences: purpose, Args, Returns. Front-loaded, no redundant text, efficient for a simple tool.

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?

Covers purpose, parameter, and return structure (including truncation hint). Missing explanation of truncation behavior and any access limitations, but adequate for single-param tool.

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?

Despite 0% schema coverage, the description adds full parameter meaning: stable ID format example and numeric DB_ID, compensating for schema omission.

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 clearly states the tool lists ordered child events (sub-pathways and reactions) of a pathway, distinguishing it from siblings like get_object.

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?

No guidance on when to use this tool vs alternatives; no mention of when not to use it or context for selection.

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

get_referrersA

Reverse lookup: which objects point AT this one (the inverse navigation REST makes awkward).

Scans a curated set of common containment relations — which pathways contain
this event, which complexes/sets contain this entity, which reactions consume
or produce it. **Best-effort, not exhaustive** (the schema has 132 link
tables; this checks the high-value ones).

Args:
    id: A stable id or numeric DB_ID of the object being referred to.
    attribute: Optionally restrict to one relationship label
        (contained_in_pathway, component_of_complex, member_of_set,
        input_to_reaction, output_of_reaction).
    limit: Max referrers per relation (1-500, default 50).

Returns:
    Dict `{object_DB_ID, referrers: [{relationship, via_table, DB_ID, _class,
    _displayName, stable_id}], scanned, note}`.

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes
`attribute`	No
`limit`	No

TDQS

A4.5/5.0

Behavior4/5

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

No annotations are provided, so the description fully carries the burden. It discloses that the tool is best-effort and not exhaustive, explaining it checks only high-value relations among 132 link tables. This sets clear expectations about the tool's behavior and limitations.

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 well-structured with an intro, then clear arg and return sections. It is informative without being excessively long. Minor redundancy (e.g., mention of 132 link tables could be condensed) but overall efficient.

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?

Given no output schema, the description provides a detailed return structure with fields. It covers purpose, parameters, return format, and limitations, making the tool fully usable without additional documentation.

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%, but the description adds thorough explanations for all three parameters: id (stable id or DB_ID), attribute (optional restriction with examples), and limit (range 1-500, default 50). This provides meaning far beyond the bare schema.

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 clearly states the tool does a reverse lookup to find objects pointing at a given one, distinguishing it from REST's awkward inverse navigation. It specifies that it checks a curated set of high-value relations, which differentiates it from sibling tools like get_object or get_participants.

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

Usage Guidelines4/5

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

The description provides context on when to use the tool—when a reverse lookup is needed—and notes its best-effort, non-exhaustive nature. However, it does not explicitly state when not to use it or mention specific alternatives among siblings, though the uniqueness of the purpose mitigates this.

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

list_tablesA

List tables in the database with their (exact) row counts and engine.

Args:
    filter: If given, only tables whose name contains this substring
        (case-insensitive). e.g. "_2_" for link tables, "Reference" for
        reference-data tables.
    limit: Max tables to return (default 500; the DB has 242).

Returns:
    Dict `{count, tables: [{table, rows, engine}], truncated}`, ordered by
    row count descending. Row counts are exact (all tables are MyISAM).

ParametersJSON Schema

Name	Required	Description	Default
`filter`	No
`limit`	No

TDQS

A4.8/5.0

Behavior5/5

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

Discloses row counts are exact (MyISAM), return structure (dict with count, tables, truncated), and ordering. No annotations provided, so description fully covers behavioral aspects.

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?

Concise with clear Args/Returns sections, examples, and key details. No unnecessary text.

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?

Complete for a simple list tool with 2 params. No output schema but return format is explained. Sibling tools cover other needs.

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 has 0% description coverage, but the description adds full meaning: filter is case-insensitive substring, limit is max count with default. Includes practical filter examples.

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 clearly states the tool lists tables with exact row counts and engine, specifying the database is MyISAM. It distinguishes from siblings like describe_table (single table) and schema_overview.

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

Usage Guidelines4/5

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

Provides filter examples and limit context (default 500, DB has 242), guiding effective use. Lacks explicit when-not-to-use but implied by sibling tools.

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

queryA

Run a single READ-ONLY SQL statement against the Reactome DB.

Accepts one `SELECT` / `WITH` / `SHOW` / `DESCRIBE` / `EXPLAIN` statement.
Writes are impossible (the connection is a SELECT-only user) and multiple
statements are rejected. If a `SELECT`/`WITH` has no `LIMIT`, one is injected
automatically. Call `schema_overview` first to learn the join patterns.

Args:
    sql: The statement to run. Use parameter-free SQL; quote literals
        normally. e.g. `SELECT d.DB_ID, d._displayName FROM DatabaseObject d
        JOIN StableIdentifier si ON d.stableIdentifier = si.DB_ID
        WHERE si.identifier = 'R-HSA-69278'`.
    max_rows: Max rows to return (1-5000, default 200). Long text cells are
        also truncated; `truncated` flags either kind.

Returns:
    Dict `{columns, rows, row_count, truncated, sql}` where `rows` is a list
    of lists aligned to `columns`, and `sql` is the statement actually run
    (with any auto-injected LIMIT). On a bad statement or DB error, returns
    `{"error": ...}`.

ParametersJSON Schema

Name	Required	Description	Default
`sql`	Yes
`max_rows`	No

TDQS

A4.7/5.0

Behavior5/5

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

With no annotations, the description fully discloses behavioral traits: writes are impossible (SELECT-only user), auto-LIMIT injection, max_rows with default and truncation, error handling, and return format. All critical behaviors are covered.

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 well-structured with a clear opening, bullet-like details, an example, and return format. It is slightly lengthy but every sentence adds value. Front-loads purpose and key restrictions.

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?

Given no annotations and no output schema, the description is remarkably complete. It covers input, output (with fields), restrictions (read-only, auto-LIMIT, error), and even guides the agent to first call schema_overview. No gaps remain for effective tool selection and 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%, so the description compensates fully. It explains the sql parameter with constraints (single statement, parameter-free, literals quoted) and provides an example. It also defines max_rows (range 1-5000, default 200) and mentions truncation of long text cells.

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 clearly states the tool's purpose: 'Run a single READ-ONLY SQL statement against the Reactome DB.' It specifies accepted statement types (SELECT/WITH/SHOW/DESCRIBE/EXPLAIN) and distinguishes from siblings by recommending schema_overview first.

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

Usage Guidelines4/5

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

The description provides explicit context: it is for read-only queries, accepts only one statement, and suggests calling schema_overview first. It gives an example and mentions rejection of multiple statements, but does not explicitly list when not to use this tool versus alternatives like get_object or search_by_name.

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

schema_overviewA

Explain the Reactome GKB schema so you can write correct SQL.

Returns a primer on the class-table-inheritance model (the `DatabaseObject`
supertable, subclass tables sharing `DB_ID`, the `Class_2_attribute` link
tables, and the stable-id join), the most useful tables, key join recipes,
and the data release loaded. **Read this once before writing `query()` SQL.**
The same primer is also available as the `schema://reactome` MCP resource.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.7/5.0

Behavior4/5

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

No annotations exist, so the description carries full burden. It describes the return content comprehensively (primer on class-table-inheritance, useful tables, join recipes, data release). For a read-only explanation tool, this is transparent; no destructive behavior is expected.

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?

The description is concise (three sentences) and well-structured: purpose first, then contents, then usage directive. Every sentence adds value without verbosity.

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?

Given no parameters or output schema, the description is self-contained. It fully explains what the tool returns and mentions the data release loaded and the alternative resource. No gaps for an explanation tool.

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

Parameters4/5

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

There are no parameters; baseline is 4. The description adds value by detailing what the tool explains, but no parameter documentation is needed.

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 clearly states the tool's purpose: explaining the Reactome GKB schema to enable writing correct SQL. It uses specific verbs ('explain') and resources ('schema'), and distinguishes from siblings like describe_table and query.

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?

Explicit usage guidance is provided: 'Read this once before writing `query()` SQL.' This tells the agent when to use the tool and implies it as a prerequisite for querying. It also mentions an alternative source (schema://reactome resource).

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

search_by_nameA

Search objects by _displayName.

Args:
    query: Text to look for in the display name.
    classes: Optional `_class` filter, e.g. ["Pathway", "Reaction"].
    limit: Max results (1-200, default 25).
    anchored: If True, match `name LIKE 'query%'` (fast — uses the prefix
        index). If False (default), match `'%query%'` — more thorough but a
        full scan of the 1.86M-row supertable (~1-2s). There are no FULLTEXT
        indexes, so prefer `anchored=True` and/or a `classes` filter for hot
        paths.

Returns:
    Dict `{count, anchored, results: [{DB_ID, _class, _displayName, stable_id}]}`.

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes
`classes`	No
`limit`	No
`anchored`	No

TDQS

A5/5.0

Behavior5/5

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

Despite no annotations, the description fully discloses behavior: it performs a search on a 1.86M-row supertable, describes the two different query modes (prefix vs substring) and their performance, and details the return structure. No contradictions.

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?

The description is concise and well-structured: a brief intro, a clear bulleted list of arguments with explanations, and a return format. Every sentence adds value; no redundant or missing information.

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?

Given the complexity of 4 parameters and no output schema, the description is fully complete. It covers argument details, performance, return format, and gives practical advice. The return dict structure is explicitly listed, compensating for the missing output schema.

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?

With 0% schema description coverage, the description compensates by explaining all four parameters (query, classes, limit, anchored) with their default values, constraints, and behavioral implications. This adds significant meaning beyond the schema.

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 clearly states the tool searches objects by `_displayName` with a clear verb and resource. It distinguishes from siblings like get_object (which retrieves by ID) and get_participants (which retrieves by specific relationships).

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?

The description provides explicit guidance on when to use the anchored parameter, performance implications, and recommendations for hot paths. It also notes the absence of FULLTEXT indexes, helping the agent decide between anchored=True vs anchored=False and using classes filter.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

9 tool updatesv0.1.0Jun 22, 2026
- First observeddescribe_table
- First observedget_object
- First observedget_participants
- First observedget_pathway_events
- First observedget_referrers
- First observedlist_tables
- First observedquery
- First observedschema_overview
- First observedsearch_by_name

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.4/5.0

Disambiguation5/5

Each tool has a distinct purpose: schema exploration (list_tables, describe_table, schema_overview), object retrieval (get_object, search_by_name), relationship queries (get_participants, get_pathway_events, get_referrers), and raw SQL (query). No overlapping functionality.

Naming Consistency4/5

Most tools follow a consistent verb_noun pattern (e.g., describe_table, get_object, list_tables). However, 'query' and 'schema_overview' are outliers—'query' is a bare verb and 'schema_overview' is noun_noun—but the overall pattern is mostly adhered to.

Tool Count5/5

With 9 tools, the server is well-scoped for a biological database MCP server. It provides essential operations without bloat, covering schema exploration, object retrieval, relationship navigation, and custom queries.

Completeness5/5

The tool set covers the primary interactions with Reactome: exploring schema, fetching objects, searching by name, retrieving participants and pathway events, reverse lookups, and arbitrary SQL queries. No obvious gaps for typical workflows.

Maintenance

ActivityStale

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

AI2SQLOAuth
io.ai2sql
Generate, fix, explain and run read-only SQL on PostgreSQL, MySQL and SQL Server
1
dataOAuth
co.thinair
Read-only PostgreSQL, MySQL, SQL Server access via MCP — 24 dialect-aware hosted tools.
Databases Developer Tools
2
sqlai.dev SQL Verifier A
io.github.JadeSparrow
Executes SQL in a real ephemeral database: rows, typed errors with suggestions, plans, diffs.
Databases Developer Tools
52
mcp A
com.googleapis.sqladmin
Create, manage, and query your Google Cloud SQL resources.
Cloud Platforms Databases
152

Related MCP Servers

mcp-tools-sql
Databases Developer Tools
MarcusJellinghaus
A
license
Not graded
quality
A
maintenance
Provides safe, configurable SQL database access via MCP tools, enabling schema introspection, predefined queries, and structured updates with multi-backend support.
Updated 9 days ago (2026-08-28 13:33 UTC)
2
MIT
mcp-server-database
Databases Developer Tools
Citadel-Cloud-Management
F
license
Not graded
quality
D
maintenance
Provides tools for interacting with relational databases (PostgreSQL, MySQL, SQLite), enabling SQL queries, schema inspection, and migration execution.
Updated 5 months ago (2026-04-11 22:18 UTC)
-
mysql-mcp-server
Databases Developer Tools
xujcbiz
A
license
A
quality
D
maintenance
Provides read-only MySQL query execution, database/table browsing, and table structure inspection with SQL safety validation.
Updated 3 months ago (2026-06-10 13:11 UTC)
5
23
MIT
mysql-readonly-mcp
beydemirfurkan
A
license
Not graded
quality
C
maintenance
Provides secure, read-only access to a single MySQL database for schema inspection and querying.
Updated 3 months ago (2026-06-04 12:51 UTC)
66
5
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/tc2fh/reactome-db-mcp'

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

reactome-db-mcp

reactome-db-mcp vs reactome-mcp

Prerequisites — the local database

Quickstart

Register with your agent

Tools

Schema discovery

Guarded raw SQL

Ergonomic helpers (sugar over the common joins)

Configuration (env vars)

Example prompts

Development

Acknowledgements

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

`reactome-db-mcp` vs `reactome-mcp`