MCPmed
A call to MCP-wrap bioinformatics web services for agent discovery/invocation — tool exposure, not a validity gate; its framing, strengths, and where it sits on our values.
arXiv:2507.08055v1 — "MCPmed: A Call for MCP-Enabled Bioinformatics Web Services for LLM-Driven Discovery" (Flotho et al., Saarland University / Helmholtz HIPS, Jul 2025). A position/initiative paper proposing that bioinformatics web services adopt the Model Context Protocol so agents can discover, invoke, and "verify" them — backed by a GEOmcp prototype, a cookie-cutter template, and an opensource hub (
github.com/MCPmed,mcpmed.org). Call-to-action stage, not a finished system. Verified 2026-06-27 against the arXiv HTML.
Its framing
MCPmed argues that bioinformatics databases — GEO, STRING DB, the UCSC Cell
Browser, PLSDB — are built for human browsers and fragile scraping, and should
instead expose a "standardized semantic contract layered over existing API
specifications" so LLM agents can use them directly. In their progression, a
service moves up three layers — UI → API → MCP — where the MCP layer "explicitly
associates each API endpoint with scientific concepts, along with versioned
metadata, facilitating automated discovery, invocation, and verification of
webservices." They ship a prototype (GEOmcp, exposing search_geo_series,
search_geo_profiles, search_geo_datasets), a cookie-cutter template for new
MCP PyPI packages, and a call for "a rigorously curated MCP app store" of
"secure, pre-vetted MCP packages." It is explicitly "A Call for" adoption: an
enabling-infrastructure vision with seed implementations, not a built platform.
Strengths relative to our approach
The enabling-infra vision is real and well-aimed, and the Foundry benefits from exactly this layer existing:
- A concrete, standards-based push to make services agent-actionable. Rather than each agent re-deriving how to call GEO, MCPmed wraps the endpoint once with a typed contract — "standardized manifests surface details such as rate limits, authentication, and pagination clearly, eliminating ad-hoc code and fragile scraping routines." This is genuinely useful plumbing.
- A working prototype, not just a manifesto. GEOmcp demonstrates an agent contextually refining a query ("microglia depletion mouse" → "CSF1R inhibitor") and recovering real datasets — the wiring works.
- Community scaffolding. A cookie-cutter template, an opensource hub, and a proposed curated app store lower the cost for service maintainers to join.
- Call-side provenance. "Concept-level versioning and audit-ready parameter tracking" record which endpoint, which version, which parameters produced a result — useful reproducibility metadata at the service boundary.
- MCP is itself a portability standard — one wrapped service is reachable from any MCP-speaking client, not bound to a single agent.
Where it sits on our values
| Value | MCPmed |
|---|---|
| Produces skills | No — it emits MCP server packages that expose web-service endpoints as agent-callable tools, not portable, self-contained skill artifacts. The deliverable is a live tool surface, not a SKILL.md. |
| Progressive disclosure | No — the semantic metadata and manifests exist for machine discovery and invocation; there is no layered surface authored for a human to read and learn from. |
| Traceability | Partial, at the call boundary — "explicit provenance," concept-level versioning, and audit-ready parameter tracking trace what service call was made with which version/parameters. That is provenance of the invocation, not lineage from an authoritative knowledge source to an artifact. |
| CLI instructions derived from CLI docs | N/A — MCPmed wraps web services / REST APIs, not command-line tools. (Its sibling BioinfoMCP is the CLI→MCP case.) |
| Portability | No skills produced — but worth a nuance: MCP is itself a portability standard, so a wrapped service is callable across MCP clients. There is no runtime-agnostic skill artifact, though; portability is of the tool endpoint, via the protocol. |
| Human scrutiny | Minimal — the human-facing layer lives at the underlying web service's own UI; the MCP output is agent-facing. Nothing here is authored for a human to read, correct, or contribute to as knowledge. |
| Knowledge-base backed | No — it exposes external databases as live, queryable tool endpoints; the knowledge stays remote and is fetched per-call. There is no inspectable knowledge base beneath the wrapper. |
Where it diverges from the Foundry
MCPmed strengthens the wiring layer — making bioinformatics services
agent-actionable through a typed, discoverable contract — which is genuinely
valuable and is a layer the Foundry happily sits atop rather than competes with.
The precision that matters is the word "verification." In MCPmed it means
verification of the webservice and the call: the endpoint exists, advertises a
versioned contract tagged with scientific concepts, and records audit-ready
parameters so a run is reproducible — "verify results through explicit
provenance" is provenance of what was invoked, not of whether the analysis is
sound. That is contract/availability/provenance verification of a service call.
The Foundry's referee gate verifies the orthogonal thing one layer down: whether
the statistical method beneath the result is valid — assumptions met, no
double-dipping, the named method real and appropriate, error rate actually
controlled. MCPmed can faithfully record that a confounded or invented method was
run, with perfect call-provenance, and never flag it; method validity is outside
its scope by design. It is a vision paper for the tool-exposure layer LLMs already
use well — and the Foundry's edge is the validity gate beneath the tool call,
not the tool's exposure. Distinct, too, from knowledgebase-mcp: that cluster
exposes knowledge retrieval (RAG) to agents; MCPmed exposes web-service tools.
Crux: MCPmed verifies that the call was well-formed and well-recorded; the Foundry
referees whether what the call computed is statistically true.
Sources
- https://arxiv.org/html/2507.08055v1 — the position paper: the MCP-wrapping proposal, the UI→API→MCP layering, the GEOmcp prototype and its three search tools, the cookie-cutter template / hub / app-store call, and every use of "verification"/"provenance" (grounds the contract-vs-method-validity distinction).