What can you do with this server?

FlowProof is an MCP server that enables AI assistants to reproducibly execute bioinformatics pipelines with verifiable provenance. You can: * List pipelines: Retrieve registered pipelines with IDs, descriptions, and read types (e.g., short-read, ONT long-read). * Describe a pipeline: Get detailed inputs, parameters, and outputs for a specific pipeline. * Run a pipeline: Launch a pipeline with inputs and parameters, receiving a run ID for tracking. * Check run status: Query the current state (running, completed, failed) of a run. * Retrieve results: Obtain a manifest of output files and their SHA-256 checksums. * Get provenance: Download a Workflow Run RO-Crate record capturing workflow version, container digests, tool versions, exact parameters, and all input/output checksums for independent verification.

Which integrations are available for this server?

Enables execution of bioinformatics pipelines using Nextflow as the workflow backend, providing reproducible run management and verifiable provenance.

How do I use FlowProof?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@FlowProof run the ONT assembly on sample.fastq" 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.

FlowProof

by ajibadedapo

Overview Schema Related Servers Score Discussions

Hybrid

FlowProof

PyPI Python License: MIT

Reproducible bioinformatics pipeline execution over the Model Context Protocol (MCP), with verifiable provenance.

FlowProof lets an AI assistant run a bioinformatics pipeline and hand back results whose provenance can be independently verified: pipeline version, container digests, tool versions, parameters, and SHA-256 checksums of every input and output, emitted as a Workflow Run RO-Crate.

It fills the layer the MCP-for-bioinformatics ecosystem is missing. Data access already has MCP servers (BioMCP); analysis planning already has AI agents (Biomni, AutoBA). The gap is reliable, trustworthy execution, which needs orchestration and provenance discipline. That is what FlowProof provides.

Why it exists

An AI that "runs an analysis for you" is only useful if you can trust the result. FlowProof makes every run reproducible and independently checkable, so an AI-driven result is not a black box: it ships with the exact recipe and checksums to reproduce it byte-for-byte.

Related MCP server: SciAgentKit

Status

FlowProof is working and installable today (pip install flowproof-mcp). The pipeline registry, execution backends, and RO-Crate provenance are complete and covered by tests, and the MCP server exposes six tools (list, describe, run, status, results, provenance). It ships with two execution backends: a zero-dependency backend for development and CI, and a Nextflow backend that runs real pipelines.

Install

uv sync

Using FlowProof

FlowProof works two ways. Both let an AI assistant run pipelines for you; you never touch a terminal after setup.

Local (recommended for real data)

Runs on your own machine, so your data never leaves it and your compute runs the pipelines. No token needed.

Add this to your MCP client config (Claude Desktop: claude_desktop_config.json; Cursor: MCP settings):

{
  "mcpServers": {
    "flowproof": {
      "command": "uvx",
      "args": ["flowproof-mcp"]
    }
  }
}

Then just ask your assistant: "list the FlowProof pipelines" or "run the ONT assembly on this file". Runs are written under ~/.flowproof/runs (override with FLOWPROOF_RUNS_DIR).

Cloud (instant, no install)

Connect your client to the hosted server. Nothing to install; the cloud runs it. Uses a bearer token today (per-user keys and OAuth are on the roadmap):

{
  "mcpServers": {
    "flowproof": {
      "url": "https://flowproof.specvista.com/mcp/",
      "headers": { "Authorization": "Bearer YOUR_TOKEN" }
    }
  }
}

Run the server directly

flowproof                        # stdio (local, default)
FLOWPROOF_TRANSPORT=http flowproof   # HTTP server on :8000

Tools

Tool	Purpose
`list_pipelines`	Registered pipelines with id, description, read type
`describe_pipeline`	Inputs, parameters, outputs for a pipeline
`run_pipeline`	Execute a pipeline reproducibly, returns a run id
`get_run_status`	Status of a run
`get_results`	Output file manifest with checksums
`get_provenance`	The verifiable Workflow Run RO-Crate record

Pipelines (seed)

id	Read type	Analysis
`ont-read-stats`	long	Oxford Nanopore read statistics (QC); optional Flye assembly. Runs on a built-in sample if you provide no input.
`variant-call-short`	short	Short-read QC to germline variant calling (nf-core/sarek)
`rnaseq`	short	RNA-seq quantification: QC, trimming, alignment, gene counts (nf-core/rnaseq)
`fetchngs`	short	Fetch raw reads and metadata from public archives, SRA/ENA/GEO (nf-core/fetchngs)
`viralrecon`	short	Viral genome reconstruction and variant calling from amplicon data (nf-core/viralrecon)

New pipelines register by manifest; the server does not change.

Try it instantly: ask your assistant to "run ont-read-stats" with no input, and FlowProof runs the bundled Oxford Nanopore sample end to end and returns a verifiable provenance crate, no data or reference genome required.

Backends

MockBackend: deterministic, dependency-free. Used for development and tests.
NextflowBackend: runs nextflow run with a container profile. Requires Nextflow and Docker.

Provenance

Every run emits ro-crate-metadata.json following the Workflow Run RO-Crate profile, capturing the workflow and version, container images, resolved tool versions, exact parameters, and SHA-256 checksums of all inputs and outputs.

Develop

PYTHONPATH=src uv run --with pytest --no-project python -m pytest tests/ -q

Architecture

See DESIGN.md.

Cite

If you use FlowProof in your research, please cite the archived software release:

Ajibade, H. A. (2026). FlowProof: reproducible bioinformatics pipeline execution over the Model Context Protocol with verifiable provenance (v0.1.2). Zenodo. https://doi.org/10.5281/zenodo.21932977

A machine-readable CITATION.cff is included, so GitHub shows a "Cite this repository" button with BibTeX and APA formats.

@software{flowproof,
  author    = {Ajibade, Hammed Adedapo},
  title     = {FlowProof: reproducible bioinformatics pipeline execution over the Model Context Protocol with verifiable provenance},
  year      = {2026},
  version   = {0.1.2},
  publisher = {Zenodo},
  doi       = {10.5281/zenodo.21932977},
  url       = {https://github.com/ajibadedapo/flowproof-mcp}
}

Available Tools

6 tools

describe_pipelineA

Return the full manifest for one pipeline: its required inputs, tunable parameters, container image, and output file patterns. Call this before run_pipeline to learn exactly which inputs and params it expects.

ParametersJSON Schema

Name	Required	Description	Default
`pipeline_id`	Yes	The pipeline id, as returned by list_pipelines.

TDQS

A4.5/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the burden. It discloses the tool's behavior by stating it returns a full manifest containing required inputs, tunable parameters, container image, and output file patterns. However, it does not explicitly state whether the operation is read-only or side-effect-free, though the verb 'return' and the context imply a safe query. The enumeration of output components adds transparency beyond a simple 'describe' statement.

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 concise at two sentences, with the primary function and contents in the first sentence and a usage tip in the second. Every word earns its place, and it is structured with the most important information upfront. No redundancy or unnecessary detail.

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?

For a simple tool with one parameter and no output schema, the description is complete. It specifies the exact components of the returned manifest, compensating for the lack of an output schema. It also provides contextual guidance on when to use it (before run_pipeline). There are no significant gaps given the tool's simplicity.

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 single parameter pipeline_id is fully described in the schema ('The pipeline id, as returned by list_pipelines'), providing high schema coverage. The tool description does not add parameter-specific details, but since schema coverage is complete, the baseline score of 3 is appropriate. The description adds contextual purpose but not additional semantic meaning for the parameter.

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 function: 'Return the full manifest for one pipeline' and enumerates the specific contents. It also distinguishes itself from run_pipeline by positioning itself as a pre-execution step. This makes the purpose unambiguous and distinct from sibling tools.

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 provides explicit usage guidance: 'Call this before run_pipeline to learn exactly which inputs and params it expects.' This tells the agent exactly when to use this tool and why. The directive is clear and actionable, even if it doesn't explicitly mention 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.

get_provenanceA

Get the Workflow Run RO-Crate provenance for a run: workflow version, container digests, tool versions, parameters, and input/output SHA-256 checksums, the full record needed to reproduce the run byte-for-byte.

ParametersJSON Schema

Name	Required	Description	Default
`run_id`	Yes	The run id returned by run_pipeline.

TDQS

A3.8/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It discloses the content of the returned provenance record and asserts a completeness guarantee for byte-for-byte reproduction, which is a behavioral claim. However, it doesn't mention operational details like error handling, permissions, or the output format beyond naming RO-Crate.

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, well-structured sentence that uses a colon to introduce a list of specific provenance elements. Every word contributes to clarifying the tool's purpose and output, with no filler or redundancy.

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?

For a one-parameter, read-only tool, the description sufficiently defines the scope of the returned provenance and its purpose. It gives a detailed list of what the record contains, which is enough for an agent to select it. It lacks details on error scenarios or how the RO-Crate output is delivered, but these are not critical for tool selection given the simplicity.

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 schema provides 100% description coverage for the single run_id parameter, stating it is 'The run id returned by run_pipeline.' The description adds no new meaning about the parameter beyond what the schema already conveys, so the 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 the tool gets 'Workflow Run RO-Crate provenance' for a run, enumerating specific contents (workflow version, container digests, checksums). This specific resource distinguishes it from sibling tools like get_run_status and get_results, which focus on status and outputs rather than full reproducibility metadata.

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 when a full record is needed to reproduce a run byte-for-byte, but it doesn't explicitly compare with alternatives like get_results or state when not to use this tool. The usage context is embedded in the phrase 'needed to reproduce the run byte-for-byte' but lacks explicit guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_resultsA

Get the outputs of a run: each output file with its SHA-256 checksum and size in bytes, plus the run status. Use the checksums to verify results independently.

ParametersJSON Schema

Name	Required	Description	Default
`run_id`	Yes	The run id returned by run_pipeline.

TDQS

A4/5.0

Behavior4/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 the return structure (output files with checksums, size, status) and adds a behavioral note about verifying results independently. This is transparent for a read-only operation, though it doesn't mention potential errors or response format details.

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 two concise sentences, front-loaded with the core purpose. Every word adds value—no fluff or repetition.

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?

For a simple one-parameter tool with no output schema, the description adequately explains returns and usage. It might benefit from a mention of get_run_status to avoid redundancy, but overall it is complete for its 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 coverage is 100%, so the single parameter run_id is fully documented with its description. The tool description adds no extra parameter semantics beyond what the schema already provides, aligning with the baseline for complete schema coverage.

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 function: retrieving run outputs including checksums, size, and status. It uses a specific verb ('get') and resource ('outputs of a run'), distinguishing it from siblings like list_pipelines or get_run_status.

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 (to get outputs/checksums) but does not explicitly state when to use this tool versus alternatives like get_run_status. No exclusions or alternate 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.

get_run_statusA

Get the current status of a run (queued, running, succeeded, or failed) by its run_id, as returned by run_pipeline.

ParametersJSON Schema

Name	Required	Description	Default
`run_id`	Yes	The run id returned by run_pipeline.

TDQS

A4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the burden of disclosure. It clearly indicates a read-only operation (get status) and lists the exact status values. It does not mention error conditions or response format, but for a simple status check, the provided information 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 a single, concise sentence that front-loads the action and includes all necessary information without any filler or redundancy.

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?

For a tool with one parameter and no output schema, the description effectively covers core behavior, parameter source, and possible return values. It lacks details on error handling or response structure, but these are minor for a status-checking tool.

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 schema already fully describes the run_id parameter and its origin ('The run id returned by run_pipeline'). The description repeats this origin without adding new semantic detail, so it adds minimal value 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's function with a specific verb ('Get'), a defined resource ('status of a run'), and enumerates the possible status values. It distinguishes itself from siblings by focusing on run status rather than pipeline execution, results, or provenance.

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 provides context that run_id comes from run_pipeline, implying usage after starting a run. However, it does not explicitly state when to use this tool versus alternatives like get_results, nor does it mention any exclusions or recommended next steps.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_pipelinesA

List the available bioinformatics pipelines. Returns each pipeline's id, a short description, and its read_type (short-read or long-read). Call this first to discover what can be run, then describe_pipeline for details.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.3/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the burden of behavioral disclosure. It discloses the return fields and the read_type enum values, which is useful for a read-only list operation. However, it does not mention potential pagination, ordering, errors, or authentication requirements.

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 two sentences, front-loaded with the primary action, and every sentence adds value. It is highly concise without unnecessary detail.

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's low complexity (no parameters, list operation) and the existence of an output schema, the description is complete. It states the purpose, return contents, and how to proceed, covering all necessary context for correct use.

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 the description does not need to explain parameters. The baseline of 4 applies because there is nothing missing in parameter guidance.

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 uses a specific verb 'List' and clearly identifies the resource ('available bioinformatics pipelines'). It also specifies what is returned (id, description, read_type) and explicitly distinguishes this discovery tool from describe_pipeline by recommending it as the first step.

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?

Provides explicit usage guidance: 'Call this first to discover what can be run, then describe_pipeline for details.' This clarifies when to use the tool and gives a clear next step, though it does not enumerate all alternatives or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

run_pipelineA

Start a pipeline run and return a run_id to track it. Provide inputs (a map of input name to file path or value) and params (a map of parameter name to value), as described by describe_pipeline. The run executes asynchronously; poll get_run_status, then fetch get_results and get_provenance when it completes.

ParametersJSON Schema

Name	Required	Description
`inputs`	No	Map of input name to file path or value, per describe_pipeline.
`params`	No	Map of parameter name to value, per describe_pipeline.
`pipeline_id`	Yes	The pipeline id to run, from list_pipelines.

TDQS

A4.3/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Without annotations, the description takes on the burden of explaining behavior. It discloses that the run executes asynchronously, returns a run_id, and requires polling for status and results. This is substantial behavioral context, though it could mention failure handling or validity checks.

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?

Two sentences, front-loaded with the primary purpose and follow-up steps. Every clause serves a purpose with 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?

For a complex asynchronous tool with no output schema and no annotations, the description covers initiation, return value, asynchronous behavior, polling, and final result retrieval. It references describe_pipeline for additional detail, making it complete enough for an agent to orchestrate the full pipeline lifecycle.

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%, and the schema descriptions already indicate that inputs and params are maps 'per describe_pipeline.' The description adds no meaning beyond the schema, merely restating the same guidance. This meets the baseline but does not elevate 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 clearly states the verb and resource: 'Start a pipeline run and return a run_id to track it.' This distinguishes it from sibling tools like list_pipelines, describe_pipeline, and get_run_status, which are explicitly mentioned as complementary follow-ups.

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 provides clear usage context by instructing to use describe_pipeline for input/param semantics and directing the sequence: poll get_run_status, then fetch get_results and get_provenance. It does not explicitly mention when not to use this tool, but the workflow is well-defined.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

5 tool updatesAug 10, 2026
- Changeddescribe_pipeline1 field changed
  - addedInput schema / properties / pipeline_id / description
```
Added value: +"The pipeline id, as returned by list_pipelines."
```
- Changedget_provenance1 field changed
  - addedInput schema / properties / run_id / description
```
Added value: +"The run id returned by run_pipeline."
```
- Changedget_results1 field changed
  - addedInput schema / properties / run_id / description
```
Added value: +"The run id returned by run_pipeline."
```
- Changedget_run_status1 field changed
  - addedInput schema / properties / run_id / description
```
Added value: +"The run id returned by run_pipeline."
```
- Changedrun_pipeline3 fields changed
  - addedInput schema / properties / inputs / description
```
Added value: +"Map of input name to file path or value, per describe_pipeline."
```
  - addedInput schema / properties / params / description
```
Added value: +"Map of parameter name to value, per describe_pipeline."
```
  - addedInput schema / properties / pipeline_id / description
```
Added value: +"The pipeline id to run, from list_pipelines."
```
6 tool updatesv0.1.0Aug 10, 2026
- First observeddescribe_pipeline
- First observedget_provenance
- First observedget_results
- First observedget_run_status
- First observedlist_pipelines
- First observedrun_pipeline

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.2/5.0

Disambiguation5/5

Each tool has a distinct purpose: listing, describing, running, status checking, result retrieval, and provenance. No two tools overlap in function, so an agent can easily select the correct one.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern (list_pipelines, describe_pipeline, run_pipeline, get_run_status, get_results, get_provenance). The style is uniform and predictable.

Tool Count5/5

Six tools is well-scoped for a pipeline management server, covering discovery, execution, monitoring, results, and provenance without excess or redundancy.

Completeness4/5

The workflow from listing pipelines to retrieving results and provenance is fully covered. A cancel/abort run operation is missing, but the core lifecycle is otherwise complete.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

pAIchart MCP HubOAuth
app.paichart
MCP Hub: AI service discovery, per-user OAuth, and multi-service workflow orchestration
App Automation Cloud Platforms Data Platforms
22
Workflow A
io.github.Jonnyton
Create, browse, remix, collaborate on, and run durable AI workflow nodes from MCP hosts.
Autonomous Agents App Automation Workplace & Productivity
21
Elnora MCP ServerOAuth
io.github.Elnora-AI
AI-powered bioprotocol optimization — generate, search, and manage lab protocols via MCP
Biology & Medicine Research & Data App Automation
23
Arquestra — Scientific Computing Orchestration
io.github.Apertura-AI
AI orchestration for computational chemistry and HPC workflows.
Bioinformatics AI & Machine Learning
2

Related MCP Servers

pipen-mcp
Bioinformatics Command Line Developer Tools
pwwang
A
license
Not graded
quality
B
maintenance
Exposes pipen bioinformatics pipelines as MCP tools, allowing AI assistants to discover and run complex workflows through a progressive disclosure interface.
Updated 24 days ago (2026-08-13 04:32 UTC)
1
MIT
SciAgentKit
Bioinformatics Biology & Medicine
ehsansyh
A
license
Not graded
quality
C
maintenance
MCP-native scientific skills for reproducible computational biology and AI-driven drug-discovery workflows. It combines deterministic scientific tools with an MCP server to give AI agents real computational capabilities.
Updated 3 months ago (2026-06-18 21:24 UTC)
Apache 2.0
n8n MCP Server
App Automation Developer Tools
MrBozkay
A
license
Not graded
quality
D
maintenance
Enables AI assistants to programmatically create, manage, and orchestrate n8n workflows through a standardized MCP interface.
Updated a year ago (2025-10-19 19:20 UTC)
MIT
Spine
CI/CD & DevOps Coding Agents Autonomous Agents
synaptixs
A
license
Not graded
quality
A
maintenance
Exposes a governed, provenance-grounded autonomous delivery pipeline as an MCP server, enabling AI coding assistants like Claude Code or Codex to initiate requirements-to-PR workflows with human approval gates and full audit.
Updated a day ago (2026-09-04 20:45 UTC)
10
MIT

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/ajibadedapo/flowproof-mcp'

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