Summary
Would you consider providing an officially maintained Model Context Protocol (MCP) server for Crab?
I'm evaluating Crab as a file storage and versioning backend for an AI-agent platform. An official MCP integration would make it easier to expose Crab's capabilities as discoverable, structured tools, without requiring each integrator to maintain a custom CLI wrapper.
Use case
The workflow I have in mind involves agents working with documents, engineering files, and generated artifacts:
- Inspect the files in a repository and their availability.
- Retrieve only the files needed for the current task.
- Save generated or modified files and publish them back to the repository.
- Inspect changes and coordinate access to shared files.
I noticed that Crab already provides Agent Skills integration through crab skills, along with structured CLI output. These are useful foundations.
MCP could complement them by supporting clients that consume structured tools directly, including integrations where unrestricted shell access is unavailable or intentionally disabled. It would also reduce the amount of platform-specific command construction and output handling needed across Windows, macOS, and Linux.
Suggested initial scope
A small initial tool set would already be valuable:
| Area |
Suggested capabilities |
| Inspection |
Repository status, tracked-file listing, file metadata, and hydration state |
| Selective retrieval |
Fetch or hydrate explicitly selected files |
| Publishing, optionally enabled |
Stage selected files and push changes, with clearly documented commit behavior |
| Collaboration, potentially later |
Inspect changes and query or manage advisory file locks |
These are suggestions rather than a request to expose the entire CLI. An initial release focused on inspection and selective retrieval would be a useful starting point.
Integration considerations
Start with stdio. A stdio-based server would fit local clients and agent runtimes that can launch a subprocess. A Crab subcommand or an official companion executable would both work. Streamable HTTP could be considered later for remote deployments; it does not need to block an initial release.
Keep operations structured and scoped. Typed inputs, structured results, actionable errors, and progress/cancellation support would be helpful. The server should support restricting access to explicitly configured repositories and paths.
Make side effects explicit. Inspection, local file materialization, and remote publication should be clearly distinguished. Publishing should be opt-in, and destructive maintenance operations could remain outside the initial scope.
Reuse existing credentials. Storage credentials should remain in the configured execution environment rather than being passed through model-visible tool arguments or results.
Avoid returning large binary payloads in tool results. File metadata and references would usually be more useful. For stdio deployments, a materialized local path could work when the client and server share a filesystem; any remote deployment would need a documented file-access mechanism.
Why an official integration?
A custom wrapper around the CLI is an alternative, but an official implementation would provide a shared tool schema, consistent behavior, and a compatibility contract maintained alongside Crab releases.
The goal is to make Crab easier to integrate into MCP-based applications while keeping its existing storage and Git workflows.
Is an official MCP integration something you would consider supporting? If there is already related work or a preferred integration approach, I would appreciate a pointer.
Summary
Would you consider providing an officially maintained Model Context Protocol (MCP) server for Crab?
I'm evaluating Crab as a file storage and versioning backend for an AI-agent platform. An official MCP integration would make it easier to expose Crab's capabilities as discoverable, structured tools, without requiring each integrator to maintain a custom CLI wrapper.
Use case
The workflow I have in mind involves agents working with documents, engineering files, and generated artifacts:
I noticed that Crab already provides Agent Skills integration through
crab skills, along with structured CLI output. These are useful foundations.MCP could complement them by supporting clients that consume structured tools directly, including integrations where unrestricted shell access is unavailable or intentionally disabled. It would also reduce the amount of platform-specific command construction and output handling needed across Windows, macOS, and Linux.
Suggested initial scope
A small initial tool set would already be valuable:
These are suggestions rather than a request to expose the entire CLI. An initial release focused on inspection and selective retrieval would be a useful starting point.
Integration considerations
Start with stdio. A stdio-based server would fit local clients and agent runtimes that can launch a subprocess. A Crab subcommand or an official companion executable would both work. Streamable HTTP could be considered later for remote deployments; it does not need to block an initial release.
Keep operations structured and scoped. Typed inputs, structured results, actionable errors, and progress/cancellation support would be helpful. The server should support restricting access to explicitly configured repositories and paths.
Make side effects explicit. Inspection, local file materialization, and remote publication should be clearly distinguished. Publishing should be opt-in, and destructive maintenance operations could remain outside the initial scope.
Reuse existing credentials. Storage credentials should remain in the configured execution environment rather than being passed through model-visible tool arguments or results.
Avoid returning large binary payloads in tool results. File metadata and references would usually be more useful. For stdio deployments, a materialized local path could work when the client and server share a filesystem; any remote deployment would need a documented file-access mechanism.
Why an official integration?
A custom wrapper around the CLI is an alternative, but an official implementation would provide a shared tool schema, consistent behavior, and a compatibility contract maintained alongside Crab releases.
The goal is to make Crab easier to integrate into MCP-based applications while keeping its existing storage and Git workflows.
Is an official MCP integration something you would consider supporting? If there is already related work or a preferred integration approach, I would appreciate a pointer.