MCP GeneLab Server

Server Quality Checklist

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

Latest release: v0.4.0
Disambiguation4/5
Most tools have clearly distinct purposes, especially the four DEG-related tools (find, common, venn, volcano) each target different outputs. However, 'create_chat_transcript' is an outlier unrelated to gene expression analysis, and 'clean_mermaid_diagram' and 'visualize_schema' both deal with Mermaid diagrams, causing slight ambiguity.
Naming Consistency4/5
The tools mostly follow a snake_case verb_noun pattern (e.g., clean_mermaid_diagram, select_assays). One exception is 'query', which is just a plain verb without a noun. Overall, the pattern is consistent and predictable.
Tool Count5/5
With 12 tools, the server covers a reasonable scope for a gene expression analysis platform. Each tool contributes to data retrieval, selection, analysis, or visualization, without being overwhelming or too sparse.
Completeness4/5
Core workflows such as finding differentially expressed genes, comparing assays via Venn diagrams, and generating volcano plots are present. However, the toolset lacks direct support for downloading raw data or exploring beyond the predefined thresholds, and the inclusion of unrelated tools like 'create_chat_transcript' does not fill domain gaps.
Average 4/5 across 12 of 12 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 14 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
This repository is licensed under BSD 3-Clause.
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.
This repository includes a glama.json configuration file.
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 provided, so description must disclose all behavioral traits. It fails to explain how the transcript is generated (e.g., from current session), whether it is written to a file or returned, or any side effects. The wording 'Prompt for creating' is ambiguous.
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?
Single sentence is very concise, but slightly ambiguous wording ('Prompt for creating') reduces clarity. Front-loads the action and format, but could be more precise without much length increase.
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?
Despite simplicity (no parameters, output schema exists), the description omits critical context about how the transcript is sourced or what 'prompt' means. Leaves agent uncertain about invocation without further context.
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?
No parameters exist, so schema coverage is 100% trivially. Description adds nothing for parameters, but this is acceptable since there are none to describe. Baseline for zero parameters is 4.
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?
Description clearly specifies the tool creates a chat transcript in markdown format with user prompts and Claude responses. It uniquely distinguishes itself from sibling tools which focus on data analysis and visualization.
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?
No explicit guidance on when to use this tool versus alternatives, but the unique purpose makes usage context clear without needing exclusion criteria. A minor gap exists in not stating that this tool likely captures the current conversation.
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, the description must convey all behavioral traits. It only states 'Get metadata' without specifying the nature of the metadata (e.g., fields, format) or any side effects. Since it is a read operation with no parameters, more detail on the output structure would improve 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 a single, front-loaded sentence that efficiently conveys the tool's purpose. However, it could be slightly expanded with minimal detail about the output without losing conciseness.
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 simplicity and the presence of an output schema, the description is adequate. However, it does not explain what 'MetaNode nodes' are, which may be unclear without domain knowledge. The tool is complete for its narrow scope but could benefit from clarifying the term 'MetaNode'.
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?
The input schema has zero parameters, so there is no need for parameter descriptions. Schema description coverage is 100% because there are no parameters to document.
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 metadata for all nodes from MetaNode nodes in the knowledge graph. It distinguishes itself from sibling tools like get_neo4j_schema (broader schema) and get_relationship_metadata (focused on relationships) by specifying the exact scope (MetaNode nodes).
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 query or get_neo4j_schema. The description does not mention any prerequisites, context, or exclusion criteria, leaving the agent to infer usage from the tool's name and sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/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 describes the removal operations clearly but doesn't discuss side effects, edge cases, or limitations (e.g., handling of malformed content). It is adequate but not deeply transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with a summary, bullet list, and args/returns, which is helpful. However, it is somewhat verbose (e.g., 'Cleaned Mermaid content with note statements, empty braces, and post-newline strings removed') and could be tightened.
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 simplicity (one parameter, no annotations), the description covers the basic functionality and return value. However, it lacks completeness regarding expected input format, error handling, or robustness. It meets minimum requirements but leaves gaps.
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 adds meaning by specifying 'The raw Mermaid class diagram content' for the single parameter. This goes beyond the schema's minimal definition, though it could provide more format details.
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: 'Clean a Mermaid class diagram by removing unwanted elements.' It lists specific elements removed (note statements, empty curly braces, strings after newline), making the action concrete. Sibling tools are unrelated (creating charts, querying), so it distinguishes well.
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 when to use this tool (when a Mermaid class diagram needs cleaning), but it doesn't explicitly guide usage or mention alternatives. No when-not-to-use advice is given, leaving some ambiguity.
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?
The description says 'Prompt for visualizing', which suggests it generates a prompt rather than executing directly, but this is not elaborated. With no annotations provided, the description should disclose more behavioral traits such as mutability, permissions, or output format beyond the output schema.
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, concise sentence that front-loads the key action and tool output. Every word earns its place without redundancy.
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 simplicity (zero params, output schema present), the description is minimally adequate. However, it could mention that it generates a Mermaid class diagram and that it is a prompt (not direct execution), to reduce ambiguity with sibling tools.
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, and the schema coverage is 100%, so baseline is 4. The description adds no parameter information, but none is needed since all parameters are already captured in the input 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 action ('visualizing'), the resource ('knowledge graph schema'), and the method ('Mermaid class diagram'). It distinguishes from sibling tool 'get_neo4j_schema' which retrieves raw schema data, while this tool produces a visual diagram.
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?
No explicit guidance on when to use this tool versus alternatives like 'get_neo4j_schema' or 'clean_mermaid_diagram'. The usage is implied but not stated, leaving room for confusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the burden. It indicates a read operation returning metadata, but lacks detail on behavior like performance or data scope.
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?
A single, clear sentence that is front-loaded and contains no unnecessary 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 zero parameters and the presence of an output schema, the description is sufficient to convey the tool's purpose, though additional context about the output format would slightly improve completeness.
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?
No parameters exist, so schema coverage is trivially 100%. The description adds no parameter info, but none 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 verb 'Get' and the resource 'descriptions of properties of all relationships in the knowledge graph', distinguishing it from sibling tools like 'get_node_metadata' or 'get_neo4j_schema'.
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 versus alternatives. There is no mention of suitable contexts or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It describes the return value (link and summary statistics) and explains the significance coloring logic. However, it does not disclose potential side effects (e.g., whether it modifies data) or authorization requirements, which are minor omissions given the tool's read-like nature.
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 concise and front-loaded with purpose. The formatting instruction is slightly unnecessary but does not detract significantly from clarity. Every sentence adds value.
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 presence of an output schema (not shown but implied by context signals), the description need not detail return values. It covers plot interpretation, threshold logic, and output type. Missing usage guidelines prevent a higher score, but overall it is sufficient for correct 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?
All 6 parameters have schema descriptions (100% coverage), so the baseline is 3. The tool description adds overall context (e.g., meaning of thresholds) but does not provide additional details per parameter beyond what the schema already offers.
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 that it creates a volcano plot for differential gene expression data, specifying the axes (log2 fold change vs -log10 adjusted p-value) and coloring logic. This distinguishes it from sibling tools like create_venn_diagram or find_differentially_expressed_genes, which serve different purposes.
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 visualizing DE results but does not explicitly state when to use this tool versus alternatives like find_differentially_expressed_genes or create_venn_diagram. No guidance on prerequisites or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses that edge properties are on relationships and gives examples, which helps agents understand the data model. However, it does not clarify whether the tool is read-only or can modify data, nor does it mention any side effects.
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 relatively concise, with a clear main line and an important note about edge properties. There is a minor typo ('downreguluated'), but overall it is well-structured and front-loaded.
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 presence of an output schema (return values are covered) and the complexity of the tool, the description adequately highlights the critical edge property context. It could mention that it can be used for arbitrary Cypher queries, but the current content is sufficient for an informed agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (both parameters described in schema). The description adds no additional meaning beyond what the schema provides for 'query' and 'params'. Baseline score of 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 'Execute a Cypher query on the Neo4j database,' which is a specific verb and resource. It also distinguishes itself from sibling tools by advising when to use alternatives (find_upregulated_genes, find_downreguluated genes).
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 explicitly tells when not to use this tool (for up/down-regulated genes) and mentions edge properties as critical. However, it does not provide a complete set of when-to-use guidelines or alternatives for other query types.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/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 reveals that two separate queries are run, the log2fc filtering criteria, and ordering. It also includes a formatting instruction (render in markdown). While it does not mention side effects or rate limits, for a read-only query tool this level of detail is sufficient.
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: two sentences and one formatting instruction. Every sentence adds value—the first states the purpose, the second details the queries, and the instruction ensures proper output. No redundancy or 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?
Given that the tool has an output schema (context signal: true), the description is not required to detail return field structure. It adequately explains what is returned (top-N up/down genes) and how they are determined. With an output schema available, this completeness level is appropriate.
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 the input schema already describes both parameters (assay_id with example, top_n with default). The tool description adds no additional parameter context beyond what the schema provides, so it meets the baseline without exceeding it.
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 explicitly states it returns top-N up- and down-regulated genes for a given assay_id, using two specific queries. This is distinct from sibling tools like create_volcano_plot or find_common_differentially_expressed_genes, so the purpose is clear and differentiated.
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 explains what the tool does but offers no guidance on when to use it versus alternatives like find_common_differentially_expressed_genes. Usage context is implied by the name and description, but no explicit when-to-use or when-not-to-use information is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description details the output (side-by-side Venn diagrams for up and down regulated genes, link to plot, summary statistics) and includes a formatting instruction. No annotations are provided, so the description carries the burden, and it adequately covers behavior without contradictions.
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 bullet points and clear sections, front-loading the purpose. The FORMATTING INSTRUCTION is somewhat extraneous but not overly verbose. It could be slightly more concise, but it remains 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 the tool has 6 parameters, no annotations, and an output schema, the description fully covers the behavior, expected input, and output. It explains the up/down regulation logic and return value, making it complete for an AI agent.
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 the schema already describes each parameter. The description adds context by explaining the effect of assay_id_3 and the threshold, but this is largely redundant with the schema. 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 it creates Venn diagrams for comparing differentially expressed genes between 2 or 3 assays, specifying the up/down regulation distinction. This distinguishes it from siblings like create_volcano_plot and find_common_differentially_expressed_genes.
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 explains when to use the tool (comparing DE genes) and how the number of assays affects the output (2-way vs 3-way). However, it does not explicitly state when not to use it or compare with alternatives like find_common_differentially_expressed_genes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It clearly indicates the tool is read-only ('list') and provides a failure scenario (APOC missing) with remediation. It lacks details on permission requirements or performance impact, but the core behavioral intent is transparent.
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 only two sentences: the first defines the core action, the second provides critical error guidance. No extraneous information, well front-loaded, and every sentence serves a purpose.
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 presence of an output schema (which covers return values) and sibling tools, the description adequately explains what the tool does and how to handle a common failure. It could mention that it relies on APOC or that it returns a full graph schema, but this is not critical. The description is complete for its intended scope.
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?
The tool has zero parameters, so schema coverage is 100% and the description does not need to explain parameters. According to guidelines, baseline is 4. The description adds value beyond the schema by explaining the output (nodes, attributes, relationships) and error handling, justifying a 4.
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 states 'List all nodes, their attributes and their relationships to other nodes' which is a specific verb-resource pairing. It clearly distinguishes from siblings like get_node_metadata (specific node) and visualize_schema (likely visualization format).
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 use when a full schema listing is needed, and includes a helpful error handling tip for APOC missing. However, it does not explicitly state when to use this tool over alternatives like get_node_metadata or visualize_schema, nor does it provide exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite lacking annotations, the description fully discloses the behavior: it performs inner joins on upregulated and downregulated genes, returns a markdown table with log2fc values, and includes formatting instructions. This covers the tool's non-destructive, read-only nature sufficiently.
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 concise intro and numbered steps. It includes useful formatting instructions, though the capitalization in 'FORMATTING INSTRUCTION' is slightly noisy. Overall, it is efficient and front-loaded.
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 presence of an output schema (so return details are covered), the description is complete. It explains the entire process, threshold usage, and output format, with no observable gaps for a tool of this complexity.
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%, providing definitions for each parameter. The description adds value by explaining how thresholds are used in the algorithm (filtering genes) but does not significantly extend beyond the schema's parameter descriptions.
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 states 'Find common differentially expressed genes across multiple assays' and explains the step-by-step process, clearly distinguishing it from sibling tools like 'find_differentially_expressed_genes' which likely handle single assays.
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 specifies that the tool requires 2 or more assay IDs and explains the algorithm, implicitly indicating when to use. It does not explicitly contrast with alternatives or provide 'when not to use' guidance, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It reveals the interactive, stateful nature (first vs second call), the prompting for study_id if missing, and the pairing of indices. While it doesn't explicitly state read-only or permission requirements, the behavior is well-disclosed for a selection tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is somewhat lengthy due to detailed step-by-step instructions, but it is well-structured with bullet points and clear sections. Most sentences provide necessary information, though some redundancy could be trimmed.
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 presence of an output schema (not shown), the description appropriately avoids detailing return values. It covers the interaction flow, input constraints, and formatting instruction. The description is complete for an agent to understand the tool's full behavior.
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 thoroughly explains both parameters: study_id (if missing, prompt; example given) and selection (string of comma-separated indices, pairs consecutive indices, must be even count). This adds critical 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 lists and selects assays for a study and renders the response in markdown format. The verb 'list and select' combined with the resource 'assays' provides a specific purpose. It also distinguishes from sibling tools, which are focused on different data operations.
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 explicitly outlines a two-step process: first call to generate a menu, second call with a selection string. It specifies when to provide study_id, how to format selection, and that an even number of indices is required. This provides clear guidance on when and how to use the tool.
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:

[![mcp-genelab MCP server](https://glama.ai/mcp/servers/sbl-sdsc/mcp-genelab/badges/card.svg)](https://glama.ai/mcp/servers/sbl-sdsc/mcp-genelab)

Score Badge

Copy to your README.md:

[![mcp-genelab MCP server](https://glama.ai/mcp/servers/sbl-sdsc/mcp-genelab/badges/score.svg)](https://glama.ai/mcp/servers/sbl-sdsc/mcp-genelab)

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/sbl-sdsc/mcp-genelab'

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