How do I use mcp-ubergraph-query?

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., "@mcp-ubergraph-query get info for MONDO:0005015" 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.

mcp-ubergraph-query

by twhetzel

Overview Schema Related Servers Score Discussions

Python

Remote

mcp-ubergraph-query

An MCP server for querying the Ubergraph biomedical ontology SPARQL endpoint.

Ubergraph is a merged knowledge graph of OBO ontologies including MONDO, UBERON, HP, CHEBI, GO, CL, and more. This server exposes four tools that let AI assistants query it naturally.

Tools

Tool	Description
`query_ubergraph`	Execute custom SPARQL SELECT queries
`get_term_info`	Get label, definition, synonyms, and types for an ontology term
`search_terms`	Search terms by label or synonym across ontologies
`get_hierarchy`	Traverse parents, children, ancestors, or descendants

Related MCP server: OWL MCP Server

Quick Start

Prerequisites

Python 3.10+
uv

Install

git clone https://github.com/twhetzel/mcp-ubergraph-query
cd mcp-ubergraph-query
uv sync --all-extras

Run the server locally

The server uses stdio (stdin/stdout) for MCP transport. Start it with:

uv run mcp-ubergraph-query

Or:

uv run python -m ubergraph_query.server

Leave this process running; MCP clients (e.g. Claude Desktop, Cursor) connect by spawning this command and talking over stdin/stdout.

Configure Claude Desktop

Add to ~/Library/Application Support/Claude/claude_desktop_config.json:

{
  "mcpServers": {
    "ubergraph": {
      "command": "uv",
      "args": [
        "--directory",
        "/path/to/mcp-ubergraph-query",
        "run",
        "mcp-ubergraph-query"
      ]
    }
  }
}

Configuration

Copy .env.example to .env and adjust as needed:

cp .env.example .env

Variable	Default	Description
`UBERGRAPH_ENDPOINT`	`https://ubergraph.apps.renci.org/sparql`	SPARQL endpoint URL
`QUERY_TIMEOUT_DEFAULT`	`30`	Default query timeout (seconds)
`QUERY_LIMIT_MAX`	`1000`	Maximum allowed LIMIT value
`ENABLE_QUERY_CACHE`	`true`	Enable in-memory LRU result cache
`CACHE_TTL_SECONDS`	`3600`	Cache entry lifetime
`LOG_LEVEL`	`INFO`	Logging verbosity

Tool Reference

`query_ubergraph`

Execute a custom SPARQL SELECT query against Ubergraph.

Input:

{
  "query": "SELECT ?s ?p ?o WHERE { ?s ?p ?o } LIMIT 5",
  "timeout": 30,
  "limit": 100,
  "format": "json"
}

Output:

{
  "results": [{"s": "...", "p": "...", "o": "..."}],
  "query_time_ms": 234,
  "result_count": 5,
  "query_hash": "abc123def456"
}

Safety features: LIMIT is automatically injected if absent; write operations (INSERT, DELETE, DROP, etc.) are rejected; timeout is capped at 60 s.

`get_term_info`

Get comprehensive metadata for an ontology term by CURIE.

Input:

{
  "curie": "MONDO:0005015",
  "include_hierarchy": false
}

Output:

{
  "curie": "MONDO:0005015",
  "iri": "http://purl.obolibrary.org/obo/MONDO_0005015",
  "label": "diabetes mellitus",
  "definition": "A metabolic disorder characterized by...",
  "synonyms": ["DM", "diabetes"],
  "types": ["owl:Class"],
  "in_ontology": "mondo"
}

With include_hierarchy: true, parents and children arrays are added.

`search_terms`

Search ontology terms by label or synonym.

Input:

{
  "text": "diabetes",
  "ontologies": ["MONDO", "HP"],
  "limit": 10,
  "exact_match": false
}

Output:

{
  "matches": [
    {
      "curie": "MONDO:0005015",
      "label": "diabetes mellitus",
      "match_type": "partial",
      "ontology": "mondo",
      "score": 0.6
    }
  ],
  "search_text": "diabetes",
  "total_matches": 1
}

`get_hierarchy`

Traverse hierarchical relationships for a term.

Input:

{
  "curie": "MONDO:0005015",
  "relation": "parents",
  "depth": 1
}

relation values: parents, children, ancestors, descendants

Output:

{
  "curie": "MONDO:0005015",
  "relation": "parents",
  "depth": 1,
  "terms": [
    {"curie": "MONDO:0005066", "label": "metabolic disease", "distance": 1}
  ]
}

Example SPARQL Queries

Get term label and definition

PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
PREFIX obo:  <http://purl.obolibrary.org/obo/>
SELECT ?label ?definition WHERE {
  obo:MONDO_0005015 rdfs:label ?label .
  OPTIONAL { obo:MONDO_0005015 obo:IAO_0000115 ?definition }
}

Search by label substring

PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
SELECT ?term ?label WHERE {
  ?term rdfs:label ?label .
  FILTER(CONTAINS(LCASE(?label), "diabetes"))
  FILTER(STRSTARTS(STR(?term), "http://purl.obolibrary.org/obo/MONDO_"))
}
LIMIT 10

Get immediate parents

PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
PREFIX obo:  <http://purl.obolibrary.org/obo/>
SELECT ?parent ?label WHERE {
  obo:MONDO_0005015 rdfs:subClassOf ?parent .
  FILTER(!isBlank(?parent))
  OPTIONAL { ?parent rdfs:label ?label }
}

Get all ancestors (transitive)

PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
PREFIX obo:  <http://purl.obolibrary.org/obo/>
SELECT ?ancestor ?label WHERE {
  obo:MONDO_0005015 rdfs:subClassOf+ ?ancestor .
  FILTER(!isBlank(?ancestor))
  OPTIONAL { ?ancestor rdfs:label ?label }
}
LIMIT 100

Find phenotype terms for a disease (HP + MONDO cross-ontology)

PREFIX rdfs:    <http://www.w3.org/2000/01/rdf-schema#>
PREFIX obo:     <http://purl.obolibrary.org/obo/>
PREFIX oboInOwl: <http://www.geneontology.org/formats/oboInOwl#>
SELECT ?phenotype ?label WHERE {
  ?association obo:RO_0002200 obo:MONDO_0005015 ;
               obo:RO_0002200 ?phenotype .
  FILTER(STRSTARTS(STR(?phenotype), "http://purl.obolibrary.org/obo/HP_"))
  OPTIONAL { ?phenotype rdfs:label ?label }
}
LIMIT 20

Testing locally

The project is not on PyPI yet. Install and test from the repo:

# Install with dev dependencies (includes pytest)
uv sync --all-extras

# Run unit tests (no network)
uv run python -m pytest tests/ -v

# Test the MCP server: spawns server, lists tools, calls get_term_info, search_terms, get_hierarchy
uv run python examples/test_mcp_server.py

# Run direct SPARQL/query examples (hits Ubergraph)
uv run python examples/example_usage.py

Manual testing with MCP Inspector:
Run the server with uv run mcp-ubergraph-query, then use MCP Inspector and add a stdio server with command uv, args --directory, <path-to-this-repo>, run, mcp-ubergraph-query.

Development

# Lint
uv run ruff check src/ tests/

Project Structure

mcp-ubergraph-query/
├── src/
│   └── ubergraph_query/
│       ├── __init__.py        # Package metadata
│       ├── server.py          # MCP server + tool implementations
│       ├── sparql_client.py   # Async HTTP SPARQL execution with retries
│       ├── query_builder.py   # SPARQL query construction helpers
│       ├── cache.py           # Thread-safe LRU cache with TTL
│       ├── validators.py      # CURIE validation, query safety checks
│       └── config.py          # Environment-based configuration
├── tests/
│   └── test_queries.py        # Unit tests (no network required)
├── examples/
│   └── example_usage.py       # Live query examples
├── pyproject.toml
├── .env.example
└── README.md

Safety

Read-only: Write operations (INSERT, DELETE, DROP, etc.) are rejected
LIMIT enforcement: Queries without LIMIT get one injected; over-limit values are capped
Timeout cap: Hard maximum of 60 seconds per query
Retry with backoff: Transient 5xx/network errors are retried up to 3 times
Query logging: Every query is logged with a SHA-256 hash for provenance

License

MIT

Available Tools

4 tools

get_hierarchyB

Get hierarchical relationships for a term (parents, children, ancestors, descendants).

ParametersJSON Schema

Name	Required	Description	Default
`curie`	Yes	Ontology term CURIE
`relation`	No	Type of relationship to retrieve	parents
`depth`	No	How many levels to traverse (1-5)

TDQS

B3.3/5.0

Behavior2/5

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

No annotations are provided, so the description must fully disclose behavior. It only states 'get hierarchical relationships' without explaining return format, pagination, or whether data is read-only. No behavioral traits beyond the schema are revealed.

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 a single, front-loaded sentence that directly conveys the tool's purpose. No unnecessary words or repetition.

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

Completeness3/5

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

While the tool is simple with 3 params fully described, the description lacks context on default behavior (relation defaults to 'parents', depth to 1) and expected output structure. With no output schema, more context would help, but it is minimally adequate.

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 description coverage is 100%, so all parameters are already documented. The description adds no extra semantic detail beyond what's in the schema (e.g., default depth, effect of relation values). Baseline 3 is appropriate.

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 retrieves hierarchical relationships for a term, listing the specific types (parents, children, ancestors, descendants). It distinguishes from sibling tools (get_term_info, query_ubergraph, search_terms) by focusing on hierarchy navigation.

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 is provided on when to use this tool versus alternatives, such as get_term_info for metadata or query_ubergraph for complex graph queries. The description lacks context on typical use cases or exclusions.

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

get_term_infoA

Get comprehensive information about a specific ontology term (labels, definitions, synonyms, types).

ParametersJSON Schema

Name	Required	Description	Default
`curie`	Yes	Ontology term CURIE (e.g., 'MONDO:0005015', 'HP:0001945')
`include_hierarchy`	No	Include immediate parent and child terms

TDQS

A3.6/5.0

Behavior3/5

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

No annotations exist. The description implies a read operation but does not disclose specific behavioral traits (e.g., auth requirements, rate limits, or side effects). It is straightforward but minimal.

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 a single sentence of 15 words, clearly and efficiently communicating the tool's purpose without extraneous words.

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 the simple input (2 params) and no output schema, the description adequately covers what the tool returns. It could list more return fields, but it includes key examples (labels, definitions).

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 description coverage is 100%, so parameters are well-documented. The description adds no new meaning beyond the schema; it merely restates that the term is an ontology term.

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 retrieves comprehensive information about a specific ontology term (labels, definitions, synonyms, types). It distinguishes from siblings: get_hierarchy (hierarchy), query_ubergraph (graph queries), search_terms (search).

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 provides no guidance on when to use this tool compared to alternatives like get_hierarchy or query_ubergraph. It does not specify scenarios or prerequisites.

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

query_ubergraphA

Execute a SPARQL query against the Ubergraph endpoint. Use for custom queries when other tools don't fit your needs.

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes	SPARQL query to execute
`timeout`	No	Query timeout in seconds (max: 60)
`limit`	No	Maximum results to return (max: 1000)
`format`	No	Result format	json

TDQS

A3.9/5.0

Behavior2/5

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

No annotations provided, so description carries full burden. It does not disclose behavioral traits such as whether the query can write, authentication needs, rate limits, or potential side effects. The description assumes read-only behavior but does not confirm it.

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 sentences, directly conveying purpose and usage without unnecessary words. Every sentence adds value.

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

Completeness3/5

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

For a tool with 4 parameters and no output schema, the description covers purpose and usage context but lacks details on return format, error handling, or query constraints. It is adequate but not fully comprehensive.

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 has 100% description coverage for all 4 parameters, so the baseline is 3. The description does not add any extra meaning beyond what is already in 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?

Clearly states the tool executes SPARQL queries against the Ubergraph endpoint. The phrase 'when other tools don't fit your needs' distinguishes it from siblings like get_hierarchy, get_term_info, and search_terms.

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?

Explicitly says to use for custom queries when other tools don't fit, providing clear guidance on when to use this tool versus alternatives.

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

search_termsB

Search for ontology terms by label or synonym. Returns matching terms with their IDs.

ParametersJSON Schema

Name	Required	Description
`text`	Yes	Search text (label or synonym)
`ontologies`	No	Filter by ontology prefixes (e.g., ['MONDO', 'HP'])
`limit`	No	Maximum results
`exact_match`	No	Require exact match vs substring

TDQS

B3.2/5.0

Behavior2/5

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

No annotations exist, so the description must convey behavioral traits. It states the tool 'Returns matching terms' but does not disclose whether it is read-only, potential side effects, rate limits, or behavior for empty results. The description is too vague to ensure safe invocation.

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 two efficient sentences, front-loaded with the purpose. No extraneous information; every word serves a purpose.

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

Completeness2/5

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

With 4 parameters and no output schema, the description is insufficient. It does not explain the return format beyond 'IDs', lacks details on sorting, pagination, or error handling. Given sibling tools, more context could differentiate use cases.

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?

The input schema covers all 4 parameters with descriptions (100% coverage). The description adds no additional meaning beyond what the schema provides, so baseline 3 is appropriate.

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 'Search for ontology terms by label or synonym' with a specific verb and resource. It distinguishes from sibling tools (get_hierarchy, get_term_info, query_ubergraph) by focusing on term lookup, not hierarchy or graph queries.

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 is provided on when to use this tool versus sibling tools. For example, it could mention that for detailed term info, use get_term_info. The description does not address context or exclusions.

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.

4 tool updatesv0.1.0Jun 7, 2026
- First observedget_hierarchy
- First observedget_term_info
- First observedquery_ubergraph
- First observedsearch_terms

Install Server

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

TDQS

A3.8/5.0

Disambiguation5/5

Each tool serves a clearly distinct purpose: searching terms, retrieving term details, getting hierarchy, and executing custom SPARQL queries. No overlap or ambiguity.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in snake_case (get_hierarchy, get_term_info, query_ubergraph, search_terms), making them predictable and easy to understand.

Tool Count5/5

With 4 tools, the server is well-scoped for ontology querying. Each tool is essential and covers the primary use cases without being too few or excessive.

Completeness4/5

The tool set covers the core needs: search, term retrieval, hierarchy, and custom queries. Minimal gaps exist, such as batch operations or ontology-wide listings, but the surface is sufficient for most tasks.

Maintenance

ActivityInactive

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

UniBio IntelligenceOAuth
io.github.unibio-intelligence
Connect AI clients to biomedical data and tools.
Biology & Medicine Research & Data AI & Machine Learning
2
Noodle Biomedical Literature Discovery MCP A
io.github.helena-bioinformatics
Search biomedical papers, inspect publication records, and traverse citation or semantic graphs.
Bioinformatics Biology & Medicine Search
71
copass-remote
com.olane
Knowledge graph ingestion, entity search, ontology analysis, and CoPass scoring.
Knowledge & Memory Search RAG Systems
2
cosync-remote
com.olane
Knowledge graph ingestion, entity search, ontology analysis, and CoSync scoring.
Knowledge & Memory RAG Systems Search
2

Related MCP Servers

OLS MCP Server
seandavi
F
license
B
quality
D
maintenance
Provides reliable access to the Ontology Lookup Service (OLS) API, enabling AI assistants to accurately search and retrieve terms from biological and medical ontologies.
Updated a year ago (2025-07-16 18:02 UTC)
7
26
-
OWL MCP Server
Knowledge & Memory Search
liftkkkk
A
license
A
quality
B
maintenance
Enables AI assistants to query, modify, and reason over OWL/TTL/RDF ontology files using natural language, without needing SPARQL or OWL syntax.
Updated 2 months ago (2026-07-11 07:07 UTC)
14
3
MIT
Redis Graph MCP Server
Bioinformatics Biology & Medicine
yskale
F
license
Not graded
quality
D
maintenance
Enables LLMs and AI agents to query a biomedical knowledge graph stored in RedisGraph, with tools for concept search, synonym enrichment, and study variable discovery through semantic relationships.
Updated 4 months ago (2026-05-19 16:09 UTC)
-
mcp-ebi-ols
Open Data Bioinformatics Biology & Medicine
pipeworx-io
A
license
Not graded
quality
C
maintenance
Enables querying and browsing ontologies from the EBI Ontology Lookup Service, including searching for terms, retrieving term details, and navigating ontology hierarchies via natural language.
Updated 10 days ago (2026-08-26 17:02 UTC)
15
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/twhetzel/mcp-ubergraph-query'

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