Skip to main content
Glama

protocol-mcp

BioContextAI - Registry Tests Documentation

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_mcp

Or from a Git repository:

uvx git+https://github.com/biocontext-ai/protocol-mcp.git@main

2. 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_mcp

4. Install the latest development version:

pip install git+https://github.com/biocontext-ai/protocol-mcp.git@main

Contact

If you found a bug, please use the issue tracker.

Citation

t.b.a

Available Tools

2 tools
get_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.

ParametersJSON Schema
NameRequiredDescriptionDefault
protocol_idYesProtocol identifier: URI, DOI, or numeric ID from search results
include_stepsNoInclude step-by-step instructions
include_materialsNoInclude materials/reagents list

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.9/5.0
Behavior3/5

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.

Conciseness4/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
queryYesSearch term (e.g., 'RNA extraction', 'CRISPR knockout')
max_resultsNoNumber of results to return (1-50)

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.7/5.0
Behavior3/5

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.

Conciseness4/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines3/5

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.

  1. 2 tool updatesv0.1.3
    • First observedget_protocol
    • First observedsearch_protocols

TDQS

A3.7/5.0
Disambiguation5/5

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.

Naming Consistency5/5

Both tools follow a consistent verb_noun pattern with underscores: 'get_protocol' and 'search_protocols'. The naming is predictable and clear.

Tool Count2/5

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.

Completeness2/5

The server only provides read operations (get and search). Missing create, update, delete, and list functionalities, leaving significant gaps in protocol management.

Maintenance

ActivityInactive
ResponsivenessNo issues

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

Related MCP Servers

Latest Blog Posts

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