SCP vs MCP: When Lab Orchestration Beats Point-to-Point

Shanghai AI Lab’s Science Context Protocol adds 1,600+ tools and centralized experiment management to MCP — but only 7.7% handle actual lab hardware. Here’s when the orchestration overhead pays off.

What Shipped

On December 30, 2025, Shanghai Artificial Intelligence Laboratory released the Science Context Protocol — an open-source extension of Anthropic’s Model Context Protocol designed specifically for scientific research. While MCP handles stateless tool invocations between AI agents and external resources, SCP adds three critical layers: centralized hub orchestration, structured experiment lifecycle management, and formal JSON experiment contexts.

The release includes an Intern-Discovery platform with 1,600+ integrated tools spanning biology (45.9%), physics (21.1%), chemistry (11.6%), and other disciplines. Computational tools dominate at 39.1%, databases at 33.8%, but physical lab operations account for just 7.7% — suggesting the wet-lab integration is more aspirational than comprehensive.

The baseline comparison matters because MCP already handles general tool interactions well. SCP’s pitch isn’t “better AI reasoning” but “better scientific plumbing” — standardizing how experiment context gets packaged and transported so agents and lab equipment can work across institutional boundaries without custom integrations.

Why the Hub Architecture Changes Things

MCP uses peer-to-peer communication. An agent calls a tool, gets a response, moves on. This works fine for single-step interactions like “search this database” or “run this calculation.” It breaks down when you need to orchestrate a multi-stage workflow that combines literature search, computational design, robotic synthesis, and iterative optimization — all while maintaining experiment provenance across institutional boundaries.

SCP replaces peer-to-peer with a hub-and-spoke model. The centralized SCP Hub acts as experiment orchestrator, maintaining a global registry of available resources (tools, datasets, models, instruments), generating and ranking executable plans based on resource requirements and risk, and managing the complete experiment lifecycle from registration through archival.

Each experiment becomes a first-class object with a persistent identifier, experimental type (dry/wet/hybrid), goals, and data storage URIs. This structured context enables comprehensive traceability and versioning that goes beyond MCP’s simple tool interactions. When a fluorescent protein engineering workflow needs to combine computational design with automated lab experiments, SCP maintains a single unified timeline where all components share context.

The hub validates results, monitors for anomalies, and can trigger fallback strategies during execution. For multi-institution workflows — literature retrieval from one server, simulation on remote HPC, closed-loop control of robotic instruments at a third site — this centralized coordination becomes essential.

The Coordination Tax

But centralized orchestration introduces overhead. Teams adopting SCP need strong identity and access management, network segmentation for multi-institution deployments, per-tool permissions, and comprehensive provenance logging. The protocol standardizes how these controls get applied but doesn’t guarantee correct implementation.

Security becomes particularly complex across institutional boundaries with varying data governance requirements. A protocol that works seamlessly within SAIL’s environment may struggle when external labs attempt cross-institution integration. The paper addresses authentication and authorization conceptually but leaves implementation details thin.

There’s also the ecosystem question. Protocols are only as strong as their adoption. If SCP remains primarily an InternScience/SAIL interface rather than achieving broad community uptake, it delivers value within that specific environment but falls short of becoming a cross-community standard. The 1,600+ tools sound impressive until you realize most external labs would need to write adapters for their existing equipment and workflows.

The tool composition skews heavily computational. With only 7.7% handling physical lab operations, the headline capability of wet-lab integration represents current limitations rather than proven deployment. The case studies in the paper demonstrate potential rather than production use across diverse institutions.

When to Adopt vs Skip

Adopt SCP if:

You’re running multi-institution collaborative research where experiment context needs to persist across organizational boundaries. You’re hitting orchestration limits with MCP’s point-to-point model because your workflows require coordinating multiple specialized agents with dependent steps. You have robotic lab equipment and need dry-wet integration pipelines where computational design feeds directly into automated synthesis and characterization.

Your reproducibility requirements demand structured experiment provenance with versioned protocols that can be replayed or inspected long after completion. You want to participate in building a shared scientific infrastructure layer rather than maintaining bespoke integrations.

Skip SCP if:

You’re operating within a single institution without cross-boundary collaboration needs. Your experiments don’t require coordinating multiple agents or maintaining complex experiment state. You already have working custom orchestration that meets your needs without the overhead of adopting a new protocol standard.

You lack robotic lab equipment or don’t need computational-physical integration. Your team isn’t prepared to implement the required security infrastructure (identity management, network segmentation, per-tool permissions) that centralized orchestration demands.

Decision Checklist

• Map your current workflow complexity: single-step tool calls vs multi-stage orchestrated experiments
• Count institutional boundaries in your typical research pipeline
• Inventory existing lab automation: purely computational vs physical equipment integration
• Assess security infrastructure maturity for hub-based architecture
• Evaluate team capacity for writing SCP adapters for your specific tools and instruments
• Consider ecosystem timing: early adoption vs waiting for broader community validation

The Ecosystem Gamble

The fundamental bet is whether SCP becomes shared infrastructure or remains one protocol among many. MCP achieved rapid adoption because Anthropic open-sourced it and major platforms integrated support. SCP’s success depends on external labs and equipment vendors implementing compatible clients and servers.

The Intern-Discovery platform provides a ready-to-use hub with public registration, lowering initial adoption barriers. But long-term viability requires that research groups beyond SAIL find the orchestration benefits worth the integration overhead. Apache 2.0 licensing helps by allowing commercial use and modifications without restrictive constraints.

For research engineers evaluating adoption: the protocol addresses real coordination problems in multi-institution, multi-agent scientific workflows. The centralized architecture makes sense for experiment lifecycle management. But practical deployment success depends on implementation quality, security infrastructure, and ecosystem development that hasn’t yet been proven at scale across diverse institutions.

The decision comes down to whether your orchestration needs justify the hub complexity, and whether you’re willing to bet on ecosystem adoption while the protocol remains early-stage. For single-lab computational work, MCP’s simpler model likely suffices. For ambitious cross-institution pipelines combining AI design with robotic synthesis, SCP offers infrastructure that doesn’t currently exist elsewhere — if you can absorb the integration costs and security requirements.

Paper: arXiv:2512.24189 Code: github.com/InternScience/scp License: Apache 2.0