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., "@Bio_MCP generate a volcano plot from minimal.csv with p=0.05"
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.
本项目把现有的 volcano.R 封装为一个可发现、可异步执行、可追踪产物的 MCP Plot 工具。当前聚焦单机 MVP：
MCP JSON-RPC：/mcp
REST 调试接口：/api
工具注册：扫描 bioinformatics/**/manifest.yaml
Job：SQLite 持久化、单 Worker、取消、超时和日志
执行器：local（直接调用 Rscript）或 docker（独立容器）
产物：本地 artifacts/，通过 artifact://job-id/path 引用
python -m venv .venv
. .venv/bin/activate
python -m pip install -r requirements.txt
mkdir -p data/input artifacts data/work
cp bioinformatics/plots/volcano/examples/minimal.csv data/input/
export BIO_MCP_EXECUTOR=local
uvicorn apps.mcp_api.main:app --host 127.0.0.1 --port 8000健康检查和工具发现：
curl http://127.0.0.1:8000/health
curl http://127.0.0.1:8000/api/tools提交任务时，input_file 必须是 data/input 下文件的绝对 file URI：
curl -X POST http://127.0.0.1:8000/api/jobs \
-H 'content-type: application/json' \
-d '{
"unit": "volcano",
"inputs": {
"input_file": "file:///绝对路径/MCP/data/input/minimal.csv"
},
"parameters": {
"feature_column": "gene_id",
"p": 0.05,
"drawFC": 1
}
}'返回 job_id 后查询：
curl http://127.0.0.1:8000/api/jobs/<job-id>
curl http://127.0.0.1:8000/api/jobs/<job-id>/artifactsMCP Client 配置见 部署教程.md，完整约束见 开发规范.md。
Related MCP server: ESMfold MCP Server
apps/mcp_api/ MCP API、注册表、Store、Runner
bioinformatics/plots/volcano volcano 单元、Schema、Dockerfile、样例
check/ 通用文件检查和 check_volcano_input
data/input/ 允许提交的本地输入根目录
data/work/ Job 临时工作目录
artifacts/ Job 产物
deploy/ Compose 和 API 镜像
tests/ 注册表、协议和契约测试
项目计划.md 分阶段架构和验收计划
文件流向图.md 输入检查、Runner、Docker 和产物流向
部署教程.md 本地、Compose、Docker 执行部署
开发规范.md manifest、CLI、测试和安全规范local 模式适合开发：Runner 直接调用宿主机 Rscript，速度快但隔离较弱。
docker 模式适合验证容器契约：
docker build -f bioinformatics/plots/volcano/Dockerfile \
-t local/bio/volcano .
BIO_MCP_EXECUTOR=docker uvicorn apps.mcp_api.main:app \
--host 127.0.0.1 --port 8000Docker 模式要求 Docker CLI 可用，并且 Runner 能访问 Docker Engine。生产环境不要把 Docker Socket 直接暴露给公网 API，应拆出受策略约束的 Runner Service。
python -m compileall -q apps
pytest -q
ruff check apps testsR 端到端测试需要安装 volcano.R 依赖；Docker 构建会在镜像内安装公开 R 包。
取消排队或正在运行的任务。
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must fully disclose behavior. It states cancellation of queued or running tasks but omits details on side effects, reversibility, idempotency, or error conditions.
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?
While very concise at one sentence, the description is under-specified and fails to provide essential information, making it inadequate rather than efficiently compact.
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 lack of annotations and output schema, the description should cover return values, state transitions, and error scenarios. It only covers the basic action, leaving significant gaps.
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 coverage is 0% and the description does not explain the job_id parameter (e.g., format, source, uniqueness). The schema only defines it as a required string with no description.
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 uses the verb 'cancel' and specifies the resource as 'queued or running tasks,' clearly distinguishing it from sibling tools like submit_job, get_job_status, and get_job_logs.
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?
No guidance is provided on when to use this tool versus alternatives, nor are there any preconditions or post-conditions mentioned. The agent must infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
在投递前检查输入文件和业务列；不合规时返回给 AI 的修复建议。
| Name | Required | Description | Default |
|---|---|---|---|
| unit | Yes | ||
| inputs | Yes | ||
| version | No | ||
| parameters | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It states it checks files and returns repair suggestions, but lacks details on side effects, permissions, or the exact format of suggestions. This is adequate but not thorough.
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 sentence that conveys the tool's purpose and behavior without any wasted words. It is front-loaded with the verb and highly 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?
Given the tool has 4 parameters including nested objects, and no output schema or annotations, the description is too brief. It does not explain what constitutes compliance, the structure of inputs, or the nature of repair suggestions, making it incomplete for effective use.
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%, and the description does not explain any of the four parameters (unit, inputs, version, parameters). It provides no guidance on their meaning or usage, leaving a significant gap.
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 checks input files and business columns before submission, and returns repair suggestions if non-compliant. This specific verb-resource combination distinguishes it from sibling tools which focus on job lifecycle management.
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 explicitly says 'before submission', providing clear context for when to use the tool. However, it does not mention when not to use it or suggest alternative tools for other scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
查看工具版本、Schema、镜像和资源限制。
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| version | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description implies a read-only operation but does not explicitly state safety, auth requirements, or side effects. The behavioral disclosure is minimal.
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 concise sentence with no redundant information. However, it could be more informative without being overly long.
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 no annotations or output schema, the description is insufficient. It does not clarify the return structure, parameter defaults, or how to specify a tool for describing. Missing details for a 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 description coverage is 0%, and the description does not explain the 'name' (presumably tool name) or 'version' (optional) parameters. It adds no meaning beyond the schema types.
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 states the tool views version, schema, image, and resource limits, which is a specific verb and resource. However, it is in Chinese and does not explicitly distinguish from sibling 'list_tools', though it implies a single tool lookup.
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?
No guidance on when to use this tool versus siblings like 'list_tools' or 'check_input_file'. The description lacks context on prerequisites or typical scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
读取任务日志。
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes | ||
| offset | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations and description does not disclose behavioral traits, such as whether logs are paginated, size limits, or 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence is concise but insufficiently informative for tool usage.
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?
Missing critical details: no output schema, no parameter semantics, no behavior guidance; inadequate for agent invocation.
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 0%, and description provides no explanation of parameters beyond what schema states.
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 reads job logs, but does not distinguish from siblings like get_job_status or list_job_artifacts.
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?
No guidance on when to use this tool versus alternatives; lacks context for appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
查询任务状态和错误信息。
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must bear the full burden of behavioral disclosure. The description only states that the tool queries status and error information, but does not mention whether it is read-only, requires authentication, or has any side effects. For a query tool, readOnlyHint would be valuable, but it is absent.
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, front-loaded sentence that efficiently conveys the tool's core function. It is appropriately sized for a simple query tool, though it could include slight more detail without losing conciseness.
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 lack of output schema and annotations, the description is incomplete. It does not explain what the response contains (e.g., status codes, error structure, fields), nor does it provide example usage or caveats. For a tool with sibling tools and no output documentation, more context is needed.
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%, and the description does not mention the 'job_id' parameter at all. Although 'job_id' is self-explanatory, the description fails to add any semantic detail about its format, source, or constraints beyond what the schema provides (name and type).
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 queries job status and error information. It uses a specific verb ('query') and resource ('job status and error information'). Although it doesn't explicitly differentiate from siblings like get_job_logs or list_job_artifacts, the purpose is unambiguous and distinct enough given the 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?
No usage guidelines are provided. The description does not indicate when to use this tool instead of alternatives such as get_job_logs (for logs) or check_input_file (for input validation). Agents receive no guidance on prerequisites or contextual fit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
列出任务产物及 artifact URI。
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes |
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 only states that the tool lists artifacts (implying a read operation), but does not disclose any behavioral details such as pagination, limits, or whether it returns metadata beyond URIs.
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 minimal (one sentence), which is concise but lacks necessary details. Conciseness is positive, but here it results in under-specification, so a score of 3 is appropriate.
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 lack of annotations and output schema, the description is incomplete. It fails to explain return values, behavior on invalid job_id, or any additional context needed for correct invocation. For a simple tool with one parameter, the description is insufficient.
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% coverage (no parameter descriptions), and the tool description does not add any meaning to the job_id parameter. It does not specify format, constraints, or examples, leaving the agent to infer from the parameter name alone.
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 explicitly states the tool's action: listing job artifacts and artifact URIs. It's clear and specific, though it doesn't differentiate from siblings explicitly. However, siblings like get_job_logs or get_job_status suggest that this tool is distinct for listing artifacts.
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?
No usage guidelines provided. The description does not indicate when to use this tool versus siblings, nor does it mention any prerequisites or context for calling it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
列出已注册的生信工具和绘图单元。
| Name | Required | Description | Default |
|---|---|---|---|
| category | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only states basic read operation but omits behavioral details like pagination, filtering behavior, or rate limits. Minimal 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?
Single sentence, front-loaded and efficient. However, very brief; could include parameter context without being verbose.
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 simple list tool with one optional parameter, description missing output format, category usage, and any filtering behavior. Incomplete for effective agent use.
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?
Input schema has 1 parameter 'category' with 0% description coverage; description does not mention or explain this parameter, failing to add value beyond 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?
Description clearly states tool lists registered bioinformatics tools and plotting units. Verb '列出' (list) and specific resource identified. Distinguishes from sibling tools like describe_tool which focuses on single tool details.
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?
No guidance on when to use this tool vs alternatives. lacks context on prerequisites or typical usage scenario.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
异步提交一个工具任务并立即返回 job_id。
| Name | Required | Description | Default |
|---|---|---|---|
| unit | Yes | ||
| inputs | Yes | ||
| version | No | ||
| parameters | No | ||
| idempotency_key | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It mentions async submission and immediate return of job_id, but fails to disclose behaviors like job lifecycle, failure handling, or rate limits.
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 sentence, making it concise, but it sacrifices essential details. It is front-loaded with the core action, but lacks structure to convey necessary context.
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 has 5 parameters (including nested objects), no output schema, and no annotations, the description is severely incomplete. It does not explain how to use the parameters or what the response contains beyond job_id.
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%, and the description adds no meaning to any of the 5 parameters (unit, inputs, version, parameters, idempotency_key). The agent gets no help understanding what these values represent.
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 function: asynchronously submit a tool task and immediately return a job_id. It distinguishes itself from sibling tools like get_job_status or cancel_job.
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 does not provide any guidance on when to use this tool versus alternatives, nor does it mention prerequisites or conditions like verifying input files with check_input_file.
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.0cancel_jobcheck_input_filedescribe_toolget_job_logsget_job_statuslist_job_artifactslist_toolssubmit_jobEach tool has a distinct purpose: listing tools, describing them, submitting jobs, checking input, monitoring status/logs, canceling, and listing artifacts. No overlaps.
All tools follow a consistent verb_noun pattern in snake_case (e.g., list_tools, submit_job, get_job_status). No deviations.
8 tools is well-scoped for a bioinformatics job submission and management server. Each tool serves a necessary function without bloat.
Covers the full lifecycle: discovery (list, describe), submission (check, submit), monitoring (status, logs, cancel), and retrieval (artifacts). No obvious gaps.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Knowledge graph ingestion, entity search, ontology analysis, and CoPass scoring.
MetaboLights MCP — EBI's metabolomics study repository.
Deploy apps on your cloud. Create environments, configure infrastructure, and monitor jobs.
Knowledge graph ingestion, entity search, ontology analysis, and CoSync scoring.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/ricancong/Bio_MCP'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
