protocol-mcp
Allows connecting to protocols.io to access and manage wetlab protocol resources, including creating, retrieving, and updating protocols.
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., "@protocol-mcpfind protocols for CRISPR gene editing"
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.
protocol-mcp
MCP that connects to wetlab protocol resources, including protocols.io
Getting started
Please refer to the documentation, in particular, the API documentation.
You can also find the project on BioContextAI, the community-hub for biomedical MCP servers: protocol-mcp on BioContextAI.
Related MCP server: LabArchives MCP Server
Installation
You need to have Python 3.10 or newer installed on your system. If you don't have Python installed, we recommend installing uv.
There are several alternative options to install protocol-mcp:
1. Use uvx to run it immediately
After publication to PyPI:
uvx protocol_mcpOr from a Git repository:
uvx git+https://github.com/biocontext-ai/protocol-mcp.git@main2. Include it in one of various clients that supports the mcp.json standard
If your MCP server is published to PyPI, use the following configuration:
{
"mcpServers": {
"protocol-mcp": {
"command": "uvx",
"args": ["protocol_mcp"]
}
}
}In case the MCP server is not yet published to PyPI, use this configuration:
{
"mcpServers": {
"protocol-mcp": {
"command": "uvx",
"args": ["git+https://github.com/biocontext-ai/protocol-mcp.git@main"]
}
}
}For purely local development (e.g., in Cursor or VS Code), use the following configuration:
{
"mcpServers": {
"protocol-mcp": {
"command": "uvx",
"args": [
"--refresh",
"--from",
"path/to/repository",
"protocol_mcp"
]
}
}
}If you want to reuse and existing environment for local development, use the following configuration:
{
"mcpServers": {
"protocol-mcp": {
"command": "uv",
"args": ["run", "--directory", "path/to/repository", "protocol_mcp"]
}
}
}3. Install it through pip:
pip install --user protocol_mcp4. Install the latest development version:
pip install git+https://github.com/biocontext-ai/protocol-mcp.git@mainContact
If you found a bug, please use the issue tracker.
Citation
t.b.a
Available Tools
2 toolsget_protocolA
Retrieve full protocol details from protocols.io.
Parameters
protocol_id : str Protocol identifier - can be a URI (e.g., 'rna-extraction-abc123'), DOI (e.g., '10.17504/protocols.io.xxx'), or numeric ID. include_steps : bool Whether to include step-by-step instructions, defaults to True. include_materials : bool Whether to include materials/reagents list, defaults to True.
Returns
str Formatted markdown with protocol metadata, materials, and steps.
| Name | Required | Description | Default |
|---|---|---|---|
| protocol_id | Yes | Protocol identifier: URI, DOI, or numeric ID from search results | |
| include_steps | No | Include step-by-step instructions | |
| include_materials | No | Include materials/reagents list |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It describes parameters and return value but does not disclose side effects, rate limits, or authentication needs. It is adequate for a simple read operation.
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 well-organized with section headers and parameter listings. However, it is somewhat verbose as it repeats schema information. It is appropriately sized but could be more concise.
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 an output schema and full parameter coverage, the description is fairly complete. It lacks error handling or authentication details, but for a simple retrieval tool, it covers the essentials.
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 100%, so baseline is 3. The description adds examples for protocol_id and clarifies defaults for boolean parameters, but adds minimal additional meaning beyond the 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 tool retrieves full protocol details from protocols.io, using specific verb 'Retrieve' and resource. It distinguishes from sibling 'search_protocols' by implying retrieval of full 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?
The description implies usage after searching for protocols, but does not explicitly state when not to use or mention alternatives. Context is clear 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.
search_protocolsA
Search protocols.io for laboratory protocols.
Parameters
query : str Search term to find protocols. max_results : int Number of results (1-50), defaults to 10.
Returns
str Formatted list of matching protocols with title, DOI, URI, and step count.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search term (e.g., 'RNA extraction', 'CRISPR knockout') | |
| max_results | No | Number of results to return (1-50) |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
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 does not explicitly state read-only behavior or any side effects, though the search nature implies no mutations. It could be improved by stating that no modifications are made.
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 concise and well-structured, using a clear docstring format with separate sections for parameters and returns. No extraneous information is present.
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 presence of an output schema (covered in the return description), and full schema coverage for parameters, the description is sufficiently complete for an agent to use the tool effectively. It lacks authentication details but that is not expected for a search 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 100%, so the baseline is 3. The description repeats parameter info from the schema (e.g., query and max_results) without adding new meaning beyond defaults and range, which are already in the 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 tool searches protocols.io for laboratory protocols, with a specific verb ('search') and resource ('protocols'). It implicitly distinguishes from the sibling tool 'get_protocol' which likely retrieves a single protocol.
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 is clear about the tool's function but provides no explicit guidance on when to use it versus alternatives (e.g., get_protocol). The intended use is implied but not directly stated.
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.
2 tool updates
v0.1.3- First observed
get_protocol - First observed
search_protocols
TDQS
The two tools have clearly distinct purposes: one retrieves a specific protocol by ID, the other searches for protocols by query. No overlap in functionality.
Both tools follow a consistent verb_noun pattern with underscores: 'get_protocol' and 'search_protocols'. The naming is predictable and clear.
With only 2 tools, the server feels under-scoped for the domain of laboratory protocols. A typical server covering protocols would require more tools for CRUD operations and listing.
The server only provides read operations (get and search). Missing create, update, delete, and list functionalities, leaving significant gaps in protocol management.
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
AI-powered bioprotocol optimization — generate, search, and manage lab protocols via MCP
- mcpOAuthio.scispot
Turn any LLM into your lab assistant: search samples, track experiments, analyze data with AI.
Connect AI clients to biomedical data and tools.
Connect AI assistants to GitHub - manage repos, issues, PRs, and workflows through natural language.
Related MCP Servers
- AlicenseAqualityCmaintenanceA Model Context Protocol (MCP) server that enables MCP clients like Claude Desktop to interact with protocols.io, a popular platform for sharing scientific protocols and methods.1015MIT
- AlicenseNot gradedqualityCmaintenanceConnects AI assistants to LabArchives electronic lab notebooks, enabling querying, semantic search, page navigation, and file uploads with provenance tracking.5MIT

Elnora MCP Serverofficial
AlicenseNot gradedqualityAmaintenanceConnects AI agents to the Elnora bioprotocol optimization platform, enabling generation, management, and optimization of wet-lab protocols through natural language.5923Apache 2.0- AlicenseNot gradedqualityBmaintenanceEnables natural language interaction with the Labguru laboratory management system, providing 63 tools across experiments, protocols, inventory, and more.MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/biocontext-ai/protocol-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server