OLS MCP Server

Overview Schema Related Servers Score Discussions

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation5/5
Each tool has a clearly distinct purpose with no ambiguity: find_similar_terms uses embeddings for similarity, get_ontology_info and get_term_info retrieve metadata, get_term_ancestors and get_term_children handle hierarchical relationships, and search_ontologies and search_terms perform different types of searches. The descriptions clearly differentiate their functions.
Naming Consistency5/5
All tools follow a consistent verb_noun pattern with snake_case: find_similar_terms, get_ontology_info, get_term_ancestors, get_term_children, get_term_info, search_ontologies, and search_terms. The naming is predictable and readable throughout the set.
Tool Count5/5
With 7 tools, this is well-scoped for an ontology server, covering core operations like searching, retrieving metadata, and exploring term hierarchies. Each tool earns its place without being excessive or insufficient for the domain.
Completeness4/5
The tool set provides strong coverage for ontology exploration, including search, metadata retrieval, and hierarchical navigation. A minor gap is the lack of update or management tools (e.g., create_term, update_ontology), but this is reasonable for a read-focused server, and agents can work effectively with the provided tools.
Average 2.9/5 across 7 of 7 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states what the tool does ('Get detailed information'), without explaining what 'detailed information' entails, whether it's a read-only operation, if there are rate limits, authentication requirements, or how results are returned. For a tool with no annotations, this leaves significant behavioral gaps.
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 extremely concise and front-loaded in a single sentence ('Get detailed information about a specific ontology'). There is zero wasted language, and it directly states the core function without unnecessary elaboration, making it efficient for quick comprehension.
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?
Given the tool has an output schema, the description doesn't need to explain return values. However, with no annotations, 0% schema coverage, and sibling tools present, the description is incomplete. It lacks context on usage differentiation, parameter details, and behavioral traits, making it minimally adequate but with clear gaps in guiding the agent effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds minimal meaning beyond the input schema. With 0% schema description coverage and one parameter ('ontology_id'), the description doesn't clarify what an 'ontology_id' is, its format, or examples. It merely restates the tool's purpose without enriching parameter understanding, failing to compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool's purpose ('Get detailed information about a specific ontology'), which is clear but vague. It specifies the verb ('Get') and resource ('ontology'), but doesn't differentiate it from sibling tools like 'get_term_info' or 'search_ontologies', leaving ambiguity about what distinguishes this tool from others that also retrieve ontology-related data.
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 versus alternatives. With sibling tools like 'search_ontologies' and 'get_term_info', there's no indication of whether this tool is for high-level ontology metadata, detailed structural information, or something else. No explicit when/when-not instructions or alternative tool references are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves information, implying a read-only operation, but doesn't specify aspects like authentication needs, rate limits, error handling, or what 'detailed information' entails (e.g., format, fields). This leaves significant gaps in understanding the tool's behavior.
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, efficient sentence that directly states the tool's purpose without unnecessary words. It is appropriately sized and front-loaded, making it easy to parse quickly. Every part of the sentence contributes to understanding the tool's basic function.
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?
Given the tool's low complexity (1 parameter, no nested objects) and the presence of an output schema (which should cover return values), the description is minimally adequate. However, it lacks context on usage relative to siblings and behavioral details, making it incomplete for effective agent use without additional inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 1 parameter ('id') with 0% description coverage, meaning the schema provides no details about the parameter. The description adds no information about the 'id' parameter, such as its format, source, or examples. With low schema coverage, the description fails to compensate, leaving the parameter's meaning unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool's purpose ('Get detailed information about a specific term') with a clear verb ('Get') and resource ('term'), but it lacks specificity about what constitutes 'detailed information' and doesn't differentiate from sibling tools like 'get_term_ancestors' or 'get_term_children' which also retrieve term-related information. This makes it vague rather than specific.
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. With siblings like 'find_similar_terms', 'search_terms', and 'get_term_ancestors', the description fails to indicate that this tool is for retrieving information about a single known term by ID, as opposed to searching or exploring relationships. This omission leaves usage unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions 'search' but does not specify whether this is a read-only operation, how results are returned (e.g., paginated via 'page' and 'size'), or any limitations (e.g., rate limits). The description is minimal and fails to convey key behavioral traits beyond the basic action.
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, clear sentence with no wasted words. It is appropriately sized for a simple tool and front-loads the core action, making it easy to parse quickly.
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?
Given the tool's moderate complexity (3 parameters, no annotations, but with an output schema), the description is incomplete. It covers the basic purpose but lacks parameter explanations and behavioral context. The presence of an output schema mitigates the need to describe return values, but overall, the description does not provide enough information for confident tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate by explaining parameters. It does not mention any parameters ('search', 'page', 'size') or their purposes, leaving all three undocumented. This is a significant gap, as the agent cannot infer parameter meanings from the description alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Search for available ontologies' clearly states the verb ('search') and resource ('ontologies'), making the basic purpose understandable. However, it lacks specificity about what 'available' means or how this differs from sibling tools like 'search_terms' or 'get_ontology_info', leaving it somewhat vague in context.
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 versus alternatives like 'search_terms' (for terms within ontologies) or 'get_ontology_info' (for details on specific ontologies). Without any context about use cases or exclusions, the agent must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'using LLM embeddings', which hints at the method, but lacks details on performance (e.g., speed, accuracy), limitations (e.g., embedding availability, ontology support), or output behavior (e.g., format specifics, error handling). For a tool with no annotations, this leaves significant gaps in understanding its operational traits.
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 and appropriately sized, with a clear purpose statement followed by 'Args' and 'Returns' sections. Each sentence serves a purpose: the first explains the tool's function, and the others document parameters and output. It's front-loaded with the core action, though the 'Args' and 'Returns' labels add slight verbosity without detracting from clarity.
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?
Given the tool's moderate complexity (3 parameters, no annotations, but with an output schema), the description is partially complete. It covers the basic purpose and parameters, and the output schema handles return values, reducing the need for detailed output explanation. However, it lacks context on when to use it versus siblings and behavioral details, making it adequate but with clear gaps for effective agent invocation.
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 description lists parameters ('term_iri', 'ontology', 'size') and their purposes in the 'Args' section, adding meaning beyond the input schema, which has 0% description coverage. However, it doesn't fully compensate for the schema gap—e.g., it doesn't explain parameter formats (like IRI structure) or constraints (like valid 'size' ranges). With 3 parameters and low schema coverage, the added value is moderate but incomplete.
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?
The description clearly states the tool's purpose: 'Find terms similar to the given term using LLM embeddings.' It specifies the verb ('find'), resource ('terms'), and method ('using LLM embeddings'), which distinguishes it from siblings like 'get_term_info' or 'search_terms'. However, it doesn't explicitly differentiate from all siblings, such as how it compares to 'search_terms' in functionality.
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 versus alternatives. It doesn't mention when to choose 'find_similar_terms' over sibling tools like 'search_terms' or 'get_term_info', nor does it specify prerequisites or exclusions. Usage is implied only by the purpose statement, with no explicit context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions that it returns a 'JSON formatted list of ancestor terms,' which gives some output context, but it doesn't cover important aspects like whether this is a read-only operation, potential rate limits, authentication needs, or error handling. For a tool with four parameters and no annotation coverage, this is a significant gap in transparency.
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 and appropriately sized, with clear sections for purpose, arguments, and returns. It uses bullet points for parameters, making it easy to scan. Every sentence adds value, such as clarifying the output format, though it could be slightly more front-loaded by emphasizing the core purpose first.
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?
Given the tool's complexity (4 parameters, no annotations, but with an output schema), the description is partially complete. It covers the basic purpose and parameters but lacks usage guidelines and detailed behavioral context. The presence of an output schema means the description doesn't need to explain return values in depth, but it should still address when to use this tool and any operational constraints.
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 description lists parameters in the 'Args' section with brief explanations (e.g., 'The IRI of the term'), adding some meaning beyond the input schema, which has 0% description coverage. However, it doesn't fully compensate for the schema gap—for example, it doesn't explain what an 'ontology identifier' entails or the implications of 'include_obsolete.' With low schema coverage, the description provides basic but incomplete parameter context.
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?
The description clearly states the tool's purpose: 'Get ancestor terms (parents) of a specific term.' It specifies the verb ('Get') and resource ('ancestor terms'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'get_term_children' or 'get_term_info,' which would require a more specific comparison.
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 versus alternatives. It doesn't mention sibling tools like 'get_term_children' (for descendants) or 'get_term_info' (for general term details), nor does it specify prerequisites or contexts for usage. This lack of comparative information leaves the agent without clear direction on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions the OLS search API but doesn't disclose behavioral traits such as rate limits, authentication needs, pagination behavior (implied by 'rows' parameter), or what happens with large result sets. For a search tool with 5 parameters and no annotation coverage, this is a significant gap.
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, efficient sentence that front-loads the core purpose without unnecessary details. Every word earns its place, making it easy for an agent to quickly grasp the tool's function.
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?
Given 5 parameters with 0% schema coverage, no annotations, but an output schema exists, the description is incomplete. It adequately states what the tool does but lacks parameter explanations and behavioral context. The output schema mitigates some gaps, but overall it's minimally viable with clear deficiencies.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It doesn't explain any parameters beyond implying 'query' is for search terms. Parameters like 'ontology', 'exact_match', 'include_obsolete', and 'rows' are undocumented in both schema and description, leaving their purposes ambiguous.
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?
The description clearly states the action ('Search for terms') and the scope ('across ontologies using the OLS search API'), which distinguishes it from siblings like 'search_ontologies' or 'find_similar_terms'. However, it doesn't explicitly differentiate from 'find_similar_terms' in terms of search methodology or output focus.
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 versus alternatives like 'find_similar_terms' or 'search_ontologies'. It mentions the API but doesn't specify use cases, prerequisites, or exclusions, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions the return format ('JSON formatted list') but lacks critical details like whether this is a read-only operation, potential rate limits, authentication requirements, error conditions, or pagination behavior beyond the 'size' parameter.
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 efficiently structured with a clear purpose statement followed by organized sections for Args and Returns. Each sentence earns its place, though the Returns section could be slightly more informative about the structure of child terms.
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?
Given the tool's moderate complexity (4 parameters, 2 required), no annotations, but with an output schema present, the description is adequate but has gaps. The output schema existence means return values don't need explanation, but behavioral aspects like safety, performance, and error handling remain undocumented.
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?
With 0% schema description coverage, the description compensates well by explaining all 4 parameters in the Args section. It clarifies that 'term_iri' identifies the specific term, 'ontology' specifies the ontology identifier, 'include_obsolete' controls whether to include obsolete entities, and 'size' sets the maximum results. This adds meaningful context 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 specific action ('Get direct children') and resource ('of a specific term'), distinguishing it from siblings like get_term_ancestors (which goes upward) and get_term_info (which provides general info). The verb+resource combination is precise and unambiguous.
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 versus alternatives like get_term_ancestors or search_terms. It mentions what the tool does but offers no context about appropriate use cases, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![ols-mcp-server MCP server](https://glama.ai/mcp/servers/seandavi/ols-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/seandavi/ols-mcp-server)

Score Badge

Copy to your README.md:

[![ols-mcp-server MCP server](https://glama.ai/mcp/servers/seandavi/ols-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/seandavi/ols-mcp-server)

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/seandavi/ols-mcp-server'

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