Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@bioportal-mcp Search for melanoma terms in BioPortal."
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.
A Model Context Protocol (MCP) server for interacting with the BioPortal API to search and retrieve ontology terms.
Search ontology terms: Search across BioPortal's extensive collection of biomedical ontologies
Search ontology properties: Find object properties, annotation properties, and datatype properties
Get ontology analytics: Access visitor statistics and usage analytics for ontologies
Flexible filtering: Filter by specific ontologies (e.g., NCIT, GO, HP, MONDO)
Exact matching: Option to require exact matches or allow fuzzy matching
Rich results: Returns term IDs, preferred labels, ontology information, and ontology page URLs
Related MCP server: BioOntology MCP Server
You can install the package from source:
pip install -e .Or using uv:
uv pip install -e .Before using this MCP server, you need to obtain a BioPortal API key:
Visit BioPortal
Create an account or sign in
Go to your account settings to get your API key
Set the API key as an environment variable:
export BIOPORTAL_API_KEY="your_api_key_here"Run the MCP server:
bioportal-mcpsearch_ontology_termsSearch for ontology terms in BioPortal.
Parameters:
query (str): The search term (e.g., "melanoma", "breast cancer", "neuron")
ontologies (str, optional): Comma-separated list of ontology acronyms (e.g., "NCIT,GO,HP")
max_results (int, default=10): Maximum number of results to return
require_exact_match (bool, default=False): Whether to require exact matches
api_key (str, optional): BioPortal API key (uses environment variable if not provided)
Returns: List of tuples containing:
Term ID (e.g., "http://purl.obolibrary.org/obo/NCIT_C4872")
Preferred label (e.g., "Breast Cancer")
Ontology acronym (e.g., "NCIT")
Ontology URL (e.g., "https://bioportal.bioontology.org/ontologies/NCIT")
Examples:
# Search for cancer terms
results = search_ontology_terms("cancer")
# Search for cell types in Cell Ontology
results = search_ontology_terms("neuron", ontologies="CL")
# Search for exact matches only
results = search_ontology_terms("melanoma", require_exact_match=True)
# Limit results
results = search_ontology_terms("disease", max_results=5)search_ontology_propertiesSearch for ontology properties (object properties, annotation properties, datatype properties) by their labels and IDs.
Parameters:
query (str): The search term (e.g., "has part", "related to", "has dimension")
ontologies (str, optional): Comma-separated list of ontology acronyms (e.g., "NCIT,GO,HP")
max_results (int, default=10): Maximum number of results to return
require_exact_match (bool, default=False): Whether to require exact matches by property id, label, or generated label
require_definitions (bool, default=False): If True, only return properties that have definitions
property_types (str, optional): Comma-separated list of property types to filter by: "object", "annotation", "datatype"
api_key (str, optional): BioPortal API key (uses environment variable if not provided)
Returns: List of tuples containing:
Property ID (e.g., "http://www.w3.org/2000/01/rdf-schema#label")
Property label (e.g., "label")
Ontology acronym (e.g., "NCIT")
Ontology URL (e.g., "https://bioportal.bioontology.org/ontologies/NCIT")
Examples:
# Search for properties containing "part"
results = search_ontology_properties("part")
# Search for object properties only
results = search_ontology_properties("related", property_types="object")
# Search for properties with definitions in specific ontologies
results = search_ontology_properties("has", ontologies="GO,CHEBI", require_definitions=True)get_ontology_analyticsGet visitor analytics for BioPortal ontologies using Google Analytics data.
Parameters:
ontology_acronym (str, optional): Ontology acronym to get analytics for (e.g., "NCIT", "GO"). If None, returns analytics for all ontologies
month (int, optional): Month number (1-12) to filter analytics. Only valid when ontology_acronym is None
year (int, optional): Year to filter analytics (e.g., 2024). Only valid when ontology_acronym is None
api_key (str, optional): BioPortal API key (uses environment variable if not provided)
Returns: Dictionary containing visitor statistics:
For all ontologies: dict with ontology acronyms as keys and visit counts
For single ontology: detailed analytics with monthly/yearly breakdowns
Examples:
# Get analytics for all ontologies
analytics = get_ontology_analytics()
# Get analytics for a specific ontology
analytics = get_ontology_analytics(ontology_acronym="NCIT")
# Get analytics for all ontologies in April 2024
analytics = get_ontology_analytics(month=4, year=2024)
# Get analytics for all ontologies in 2024
analytics = get_ontology_analytics(year=2024)This MCP server can be integrated with AI assistants like Claude Desktop. Add the following to your MCP configuration:
{
"mcpServers": {
"bioportal": {
"command": "bioportal-mcp",
"env": {
"BIOPORTAL_API_KEY": "your_api_key_here"
}
}
}
}A streamable version of this MCP is also available from the following URL:
https://bioportal.fastmcp.app/mcpThis means it may be used through any agentic framework supporting HTTP streaming of MCPs.
This MCP server provides access to the following BioPortal API endpoints:
Search (/search): Search for ontology terms/classes across all ontologies
Property Search (/property_search): Search for ontology properties (object, annotation, datatype)
Analytics (/analytics): Retrieve visitor statistics and usage analytics for ontologies
BioPortal hosts hundreds of ontologies. Some popular ones include:
NCIT: NCI Thesaurus - comprehensive cancer terminology
GO: Gene Ontology - gene and protein functions
HP: Human Phenotype Ontology - phenotypes and clinical features
MONDO: Disease ontology
CHEBI: Chemical entities
UBERON: Anatomy ontology
CL: Cell Ontology
SO: Sequence Ontology
# Clone the repository
git clone https://github.com/ncbo/bioportal-mcp.git
cd bioportal-mcp
# Install development dependencies
uv pip install -e ".[dev]"BSD-3-Clause
Get visitor analytics for BioPortal ontologies.
This function retrieves Google Analytics data for ontology visits. You can get analytics for all ontologies, filter by month/year, or get detailed analytics for a specific ontology.
| Name | Required | Description | Default |
|---|---|---|---|
| year | No | Year to filter analytics (e.g., 2024). Only valid when ontology_acronym is None. | |
| month | No | Month number (1-12) to filter analytics. Only valid when ontology_acronym is None. | |
| api_key | No | BioPortal API key. If not provided, uses BIOPORTAL_API_KEY environment variable. | |
| ontology_acronym | No | Ontology acronym to get analytics for (e.g., "NCIT", "GO"). If None, returns analytics for all ontologies. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior fully. It describes that it retrieves analytics data but does not mention authentication, rate limits, or side effects. However, the tool is read-only and the API key parameter is in the schema, so basic transparency is adequate.
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?
The description is two sentences with no redundant words. The first sentence states the purpose, and the second elaborates on usage, making it front-loaded and efficient.
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?
The description covers the main functionalities: retrieving analytics for all or specific ontologies with optional time filters. An output schema exists, so return values are documented separately. No missing critical aspects for this simple tool.
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 baseline is 3. The description summarizes parameter usage (filter by month/year, specific ontology) but adds no new details beyond the schema descriptions. Thus, it does not exceed the baseline.
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?
The description clearly states it gets visitor analytics for BioPortal ontologies. It specifies three modes: all ontologies, filtered by month/year, or for a specific ontology. This distinguishes it from sibling tools which search properties and terms.
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?
The description provides clear usage context: it can retrieve analytics for all ontologies, filter by month/year, or get detailed analytics for a specific ontology. However, it does not explicitly state when not to use it or compare with alternatives, though the alternatives are unrelated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for ontology properties in BioPortal.
This function searches for ontology properties (object properties, annotation properties, datatype properties) by their labels and IDs across BioPortal ontologies.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | The search term (e.g., "has part", "related to", "has dimension"). | |
| api_key | No | BioPortal API key. If not provided, uses BIOPORTAL_API_KEY environment variable. | |
| ontologies | No | Comma-separated list of ontology acronyms to search in (e.g., "NCIT,GO,HP"). If None, searches across all ontologies. | |
| max_results | No | Maximum number of results to return (default: 10). | |
| property_types | No | Comma-separated list of property types to filter by: "object", "annotation", "datatype". If None, returns all property types. | |
| require_definitions | No | If True, only return properties that have definitions (default: False). | |
| require_exact_match | No | If True, only return exact matches by property id, label, or generated label (default: False). |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. It states it searches by labels and IDs but lacks details on idempotency, side effects, or expected response specifics. Output schema exists, reducing need to explain return values, but behavioral traits like rate limits or necessary permissions are omitted.
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?
Two sentences, no redundant information, clear and direct.
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?
Given the tool's complexity (7 parameters, output schema), the description covers the core purpose and adds context on property types and scope. Could mention relationship to sibling tool for differentiation, but overall adequate.
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 100% with detailed parameter descriptions. Description adds value by specifying that search is by labels and IDs, which is not in schema. This clarifies the search mechanism.
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?
Description clearly states it searches for ontology properties, lists types (object, annotation, datatype), and mentions operation across BioPortal ontologies. Distinguishes from sibling tools which are analytics and term search.
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?
Description gives context but does not provide explicit guidance on when to use this tool over siblings, nor does it mention conditions where it should not be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for ontology terms in BioPortal.
This function searches across BioPortal ontologies for terms matching the given query. It returns a list of tuples containing the term ID, preferred label, ontology, and ontology URL.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | The search term (e.g., "melanoma", "breast cancer", "neuron"). | |
| api_key | No | BioPortal API key. If not provided, uses BIOPORTAL_API_KEY environment variable. | |
| ontologies | No | Comma-separated list of ontology acronyms to search in (e.g., "NCIT,GO,HP"). If None, searches across all ontologies. | |
| max_results | No | Maximum number of results to return (default: 10). | |
| require_exact_match | No | If True, only return exact matches (default: False). |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It does not disclose any behavioral traits like case sensitivity, pagination, performance implications, or side effects. The schema provides some details but the description adds little beyond the basic search operation.
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?
The description is two sentences, concise, and front-loaded with the purpose. Every sentence adds value without redundancy.
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?
Given the absence of annotations and the presence of an output schema, the description should provide more contextual completeness about usage and behavior. It lacks guidelines and behavioral details, making it insufficient for full understanding.
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 description coverage is 100%, so baseline is 3. The description does not add any additional meaning beyond the schema; it only mentions the return format. No extra parameter context.
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?
The description clearly states the tool searches for ontology terms in BioPortal and specifies the return format (list of tuples with term ID, label, ontology, URL). It distinguishes from siblings like get_ontology_analytics and search_ontology_properties by focusing on term search.
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?
The description provides no guidance on when to use this tool versus alternatives, no exclusions, and no context about prerequisites or limitations. It only describes the basic function.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.1get_ontology_analyticssearch_ontology_propertiessearch_ontology_termsEach tool targets a different aspect of BioPortal: analytics for usage data, properties search for ontology properties, and term search for ontology terms. There is no overlap in functionality.
All tool names follow a consistent verb_noun (snake_case) pattern: get_ontology_analytics, search_ontology_properties, search_ontology_terms.
Three tools is on the lower end but reasonable for a focused search and analytics server. The number is appropriate given the scope, though additional tools could be justified.
The server lacks essential operations for ontology management: no tool to list or retrieve ontologies, no term details beyond search, no mappings or annotations. This leaves significant gaps for typical BioPortal use cases.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server for querying BrainKB, a knowledge base for neuroscience knowledge graphs.
Hosted MCP server for finding authoritative primary data sources and official portals.
Auditable MCP server for PubMed, Europe PMC, ClinicalTrials.gov, and bioRxiv/medRxiv queries
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/ncbo/bioportal-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
