Hyperledger Fabric Agent Suite MCP Server
Manage Fabric test networks and chaincode lifecycle with the MCP server in the Hyperledger Fabric Agent Suite.
Overview
The MCP (Model Context Protocol) server in the Hyperledger Fabric Agent Suite provides a lightweight HTTP API and orchestration layer to manage Fabric test networks and to automate chaincode lifecycle tasks. It is designed for developers who need repeatable, scriptable control over local or CI-based Fabric deployments — creating peers and orderers, creating channels, installing and committing chaincode, and retrieving deployment status through a consistent API.
Using the MCP server helps standardize how tools and automation scripts interact with Fabric test networks. Instead of embedding Fabric CLI sequences in many different places, teams can call the MCP server to perform lifecycle operations, making CI pipelines, local developer tooling, and teaching labs simpler and less error-prone.
Features
- REST API to manage Fabric test networks (create, start, stop, destroy)
- Chaincode lifecycle automation: package, install, approve, commit, invoke, query
- Channel management: create channel, join peers to channels, update anchors
- Environment configuration via JSON files or environment variables
- Suitable for local development, CI pipelines, and sandbox environments
- Basic status and logging endpoints for integration and troubleshooting
- Extensible architecture for adding custom runtime steps or integrations
Installation / Configuration
Prerequisites: Node.js (12+), Docker (for fabric containers), Fabric binaries or Docker images available locally.
Clone and install:
Create a minimal configuration file (config.json):
Run the server locally:
# or
Common environment variables:
- MCP_CONFIG — path to server config JSON
- PORT — HTTP port override (default 8080)
- FABRIC_TOOLS_PATH — path to peer/orderer binaries (if needed)
- DOCKER_HOST — if using remote Docker engine
If you prefer Docker:
Available Resources
- GitHub repository: https://github.com/padmarajkore/hlf-fabric-agent
- REST API root: GET /health (returns server and Fabric tooling status)
- Logging: GET /logs or stream via websocket (if enabled)
- Static config: /config (read-only view of effective configuration)
API endpoints (typical set):
| Endpoint | Verb | Description |
|---|---|---|
| /health | GET | Server and tooling health |
| /networks | POST | Create/start a test network |
| /networks/{id} | GET | Get network status |
| /networks/{id} | DELETE | Teardown a network |
| /channels | POST | Create a channel |
| /peers/{peerId}/join | POST | Join peer to channel |
| /chaincodes | POST | Package & install chaincode |
| /chaincodes/{cc}/approve | POST | Approve chaincode for org |
| /chaincodes/{cc}/commit | POST | Commit chaincode to channel |
| /chaincodes/{cc}/invoke | POST | Invoke chaincode transaction |
| /chaincodes/{cc}/query | GET | Query chaincode state |
Note: Exact paths may vary by release; consult the repo docs or /help endpoint.
Use Cases
CI/CD chaincode validation
- In a pipeline job, call POST /networks to provision a fresh test network, POST /chaincodes to install and approve a candidate chaincode package, then POST /chaincodes/{cc}/invoke and /query to run unit tests. After tests finish, call DELETE /networks/{id} to free resources.
Example (simplified):
Local developer sandbox
- Developers spin up a reproducible network with one command, deploy chaincode, and iterate on smart contracts without manually running peer and orderer containers. Use the server to snapshot and restore test states.
Teaching and workshops
- Course instructors provision identical networks for each lab, provide simple HTTP-based tasks to students (e.g., “POST /chaincodes to deploy this example”), and automate teardown between sessions.
Integration testing for off-chain services
- Services that need to test Fabric interactions can use the MCP server to create deterministic environments and assert on ledger state via /chaincodes/{cc}/query.
Tips and Next Steps
- Keep chaincode packages in a shared build artifact store or reference by label when automating.
- Use the health and logs endpoints to diagnose permissions or binary-version mismatches.
- Extend the server by adding custom handlers for non-standard lifecycle steps (e.g., private data collection setup or custom endorsement flows).
For detailed API shapes and example payloads, check the repository README and the server’s /help or OpenAPI endpoint in the running instance.