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., "@miEAA3 MCP Server run enrichment analysis for hsa-miR-21-5p and hsa-miR-155-5p"
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.
An MCP (Model Context Protocol) server that integrates the miEAA 3.x REST API with Claude Desktop, exposing miEAA functionality as callable tools for microRNA and precursor enrichment analysis.
miEAA3_MCP provides a clean integration layer between Claude Desktop and the miEAA bioinformatics platform.
The server is implemented in TypeScript, bundled as a single Node.js ESM entry point, and registered with Claude via MCP.
The project focuses on:
Correct MCP protocol integration
Robust request/response normalization
Reliable execution of miEAA tools inside Claude Desktop
No biological logic is reimplemented; all analysis is performed by the official miEAA API.
Related MCP server: encode-toolkit
miEAA3_mcp/
├── README.md
├── manifest.json
├── package.json
├── package-lock.json
├── tsconfig.json
├── dist/
│ ├── server.js
│ └── handlers/
│ ├── mieaa_categories_handler.js
│ ├── mieaa_mirna_precursor_converter_handler.js
│ ├── mieaa_mirbase_converter_handler.js
│ └── over_representation_analysis_handler.js
├── src/
│ ├── server.ts
│ ├── handlers/
│ │ ├── mieaa_categories_handler.ts
│ │ ├── mieaa_mirna_precursor_converter_handler.ts
│ │ ├── mieaa_mirbase_converter_handler.ts
│ │ └── over_representation_analysis_handler.ts
│ └── utils/
│ └── mieaa.ts
├── test.mjs
└── miEAA3_mcp.dxtThe following four miEAA tools are integrated, registered, and visible in Claude Desktop:
Tool: over_representation_analysis
Runs miEAA ORA for miRNA or precursor inputs
Handles job submission, polling, and result retrieval
Supports category-based enrichment analysis
Tool: list_enrichment_categories
Queries available enrichment categories from miEAA
Intended to guide category selection for ORA
Tool: mirna_precursor_converter
Converts between miRNA and precursor identifiers
Handles miEAA rate limits
Normalizes plain-text API responses into structured output
Tool: mirbase_version_converter
Converts miRNA identifiers between miRBase versions
Explicitly reports converted, unchanged, and unmappable entries
Node.js ≥ 18
npm
Install dependencies:
npm installThe MCP server must be bundled into a single ESM-compatible file for Claude Desktop.
npx esbuild src/server.ts --bundle --platform=node --format=esm --target=node18 --outfile=dist/server.js --log-level=debugBundles all handlers and utilities into one file
Ensures compatibility with Claude’s Node runtime
Resolves MCP SDK and module resolution issues
The MCP server is correctly discovered and launched by Claude Desktop
Extension folder detection issues are resolved
MCP SDK resolution issues are resolved by the current build setup
All four tools appear as callable tools inside Claude
No manual server startup is required when using Claude Desktop.
node test.mjsAll tools execute correctly in a local Node.js environment.
For protocol-level inspection and debugging:
npm install @modelcontextprotocol/inspector --save-dev
npx @modelcontextprotocol/inspector.dxtInstall prerequisites: Node.js ≥ 18, npm, and Claude Desktop
Clone or open the miEAA3_mcp project directory
Install dependencies:
npm installnpx esbuild src/server.ts \
--bundle \
--platform=node \
--format=esm \
--target=node18 \
--outfile=dist/server.jsnpx esbuild src/server.ts `
--bundle `
--platform=node `
--format=esm `
--target=node18 `
--outfile=dist/server.js(or use the existing .dxt file from the repository):
zip -r miEAA3_mcp.dxt \
manifest.json \
package.json \
package-lock.json \
tsconfig.json \
dist \
-x "*.ts" "*.map" "*.log"Open Claude Desktop → Settings → Advanced → Install Extension
Select the miEAA3_mcp.dxt file (from your Windows or local folder)
Open a new Claude chat and use the miEAA tools directly
(no manual server start required)
At the moment, I am refining the result formatting, so the outputs are more structured and easier to use by user, while remaining MCP-compatible. The miEAA server was temporarily down during testing, but I expect to complete this today once it is reachable again.
One issue I encountered is that GSEA analysis has API endpoints but expects a different input format that is not documented on the miEAA website, which currently prevents successful execution. All other API-based tools are working as expected.
List available miEAA enrichment categories for a species.
| Name | Required | Description | Default |
|---|---|---|---|
| species | Yes | ||
| entity | Yes |
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 states the tool lists categories but does not describe any behavioral traits such as rate limits, authentication needs, or what the output looks like (e.g., format, pagination). This leaves significant gaps in understanding how the tool behaves.
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 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.
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 complexity (2 required parameters, no annotations, no output schema), the description is incomplete. It lacks details on parameter usage, behavioral context, and output expectations, making it insufficient for an AI agent to fully understand how to invoke and interpret results from this 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?
The schema description coverage is 0%, so the description must compensate for undocumented parameters. It mentions 'species' and implies 'entity' through 'miEAA enrichment categories', but does not explain what these parameters mean, their expected values, or how they affect the listing. This adds minimal semantic value beyond the bare schema.
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 action ('List available') and the resource ('miEAA enrichment categories for a species'), making the purpose understandable. However, it does not explicitly differentiate this tool from its siblings (e.g., converters and analysis tools), which slightly limits its clarity in context.
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 its siblings (mirbase_version_converter, mirna_precursor_converter, over_representation_analysis). It lacks context on prerequisites, alternatives, or exclusions, leaving usage decisions ambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convert miRNA identifiers between miRBase versions.
| Name | Required | Description | Default |
|---|---|---|---|
| mirnas | Yes | ||
| source_version | Yes | ||
| target_version | Yes |
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 states the conversion action but does not cover critical aspects like whether this is a read-only or mutative operation, error handling, rate limits, or output format. 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.
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 any extraneous information. It is front-loaded and wastes no words, making it highly concise and well-structured.
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 complexity of a conversion tool with 3 undocumented parameters, no annotations, and no output schema, the description is inadequate. It fails to address behavioral traits, parameter details, or output expectations, leaving the agent poorly equipped to use the tool effectively.
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?
The input schema has 0% description coverage, so the description must compensate. It implies parameters for miRNA identifiers and versions but does not explain their semantics, such as format requirements, valid version strings, or array constraints. This adds minimal value beyond the bare schema.
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 specific action ('Convert') and resource ('miRNA identifiers between miRBase versions'), distinguishing it from sibling tools like 'mirna_precursor_converter' which handles different conversions. It precisely communicates the tool's function without redundancy.
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, such as 'mirna_precursor_converter' or other sibling tools. It lacks context about prerequisites, typical use cases, or exclusions, leaving the agent with minimal direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convert between miRNA names and precursor names.
| Name | Required | Description | Default |
|---|---|---|---|
| input | Yes | ||
| direction | Yes |
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 states the conversion action but lacks details on permissions, rate limits, error handling, or output format. For a tool with two parameters and no output schema, 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's function without unnecessary words. It's appropriately sized and front-loaded, making it easy to parse quickly.
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 (two parameters, no output schema, no annotations), the description is incomplete. It doesn't cover parameter meanings, usage scenarios, or behavioral traits, leaving gaps that could hinder correct tool invocation by an AI agent.
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 0%, so the description must compensate. It mentions 'convert between miRNA names and precursor names', which implies the 'input' and 'direction' parameters, but doesn't explain their semantics, formats, or constraints. This adds minimal value beyond the schema's structure.
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's purpose: converting between miRNA names and precursor names. It specifies the verb 'convert' and the resources involved, making the function unambiguous. However, it doesn't differentiate from sibling tools like 'mirbase_version_converter', which might handle similar data but different operations.
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. It doesn't mention sibling tools like 'mirbase_version_converter' or 'over_representation_analysis', nor does it specify prerequisites or contexts for usage, leaving the agent to infer applicability.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run miEAA over-representation analysis (ORA) for miRNA or precursor.
| Name | Required | Description | Default |
|---|---|---|---|
| species | Yes | ||
| entity | Yes | ||
| ids | Yes | ||
| category_selection | No | ||
| reference_set | No | ||
| p_adjust | No | ||
| p_scope | No | ||
| alpha | No | ||
| min_hits | No |
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. While it indicates this is an analysis tool (likely non-destructive), it doesn't describe what the tool actually does behaviorally - whether it makes API calls, computes locally, has rate limits, requires authentication, returns specific data formats, or has any side effects. The description is too minimal for a 9-parameter tool with complex functionality.
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 extremely concise - a single sentence that gets straight to the point. While arguably too brief for such a complex tool, it's efficiently structured with zero wasted words. The front-loading is good, immediately stating the core functionality.
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?
For a complex bioinformatics analysis tool with 9 parameters, no annotations, no output schema, and 0% schema description coverage, this description is severely incomplete. It doesn't explain what ORA analysis entails, what results to expect, how to interpret parameters, or provide any context about the miEAA system. The agent would struggle to use this tool effectively.
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?
With 0% schema description coverage and 9 parameters (6 optional), the description provides no information about parameter meanings or usage. It mentions 'miRNA or precursor' which relates to the 'entity' parameter, but doesn't explain what 'species', 'ids', 'category_selection', 'reference_set', 'p_adjust', 'p_scope', 'alpha', or 'min_hits' represent or how they should be used.
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 action ('Run miEAA over-representation analysis (ORA)') and the target resources ('for miRNA or precursor'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate this tool from its siblings (list_enrichment_categories, mirbase_version_converter, mirna_precursor_converter), which appear to be related but distinct bioinformatics tools.
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 its siblings or alternatives. It mentions the analysis type (ORA) and target entities (miRNA/precursor), but doesn't specify use cases, prerequisites, or exclusions. This leaves the agent without context for tool selection.
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.
list_enrichment_categoriesmirbase_version_convertermirna_precursor_converterover_representation_analysisEach tool has a clearly distinct purpose: listing categories, converting miRNA identifiers, converting miRNA/precursor names, and running over-representation analysis. There is no overlap or ambiguity between these functions, making tool selection straightforward for an agent.
Three tools follow a consistent verb_noun pattern (list_enrichment_categories, mirna_precursor_converter, over_representation_analysis), while one uses a noun_verb_noun pattern (mirbase_version_converter). This minor deviation slightly reduces consistency but the naming remains readable and predictable overall.
With 4 tools, the server is well-scoped for miRNA enrichment analysis, covering key operations like listing categories, identifier conversion, and analysis. Each tool earns its place without feeling excessive or insufficient for the domain.
The toolset covers essential workflows for miEAA, including data preparation (conversions) and analysis (ORA). A minor gap exists in lacking tools for other analysis types (e.g., gene set enrichment), but agents can still perform core tasks effectively with the provided tools.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Your Aurentia workspace — projects, CRM, tasks, deliverables — in Claude, Cursor or any MCP client.
Connect Claude to your Platform7n workspaces — chat, links, and tasks. One-click OAuth.
Connect Claude to Fathom meeting recordings, transcripts, and summaries
One workspace of tools for Claude and ChatGPT: connect 600+ apps, generate media, build tools.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/kkShrihari/miEAA3_mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
