Cross Repo Ops MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| repo_treeC | List files and directories in an allowed repository with safety exclusions. |
| repo_searchB | Search an allowed repository using ripgrep with bounded output and safety exclusions. |
| repo_readB | Read a bounded slice of a non-sensitive text file from an allowed repository. |
| git_statusC | Inspect the current Git repository status. |
| git_diffC | View the diff of unstaged or staged changes in a repository. |
| apply_patchB | Apply a bounded, context-checked patch to a file in a writable repository. If old_text is empty and create=true, creates the file. |
| run_taskB | Run an approved named task for a repository. No arbitrary shell commands are accepted. |
| git_branchC | List or safely create a branch in a repository. |
| git_commitC | Stage and commit files in a writable repository. |
| git_pushC | Push the current or specified branch to origin in a pushable repository. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 10 tools
Each tool maps cleanly to a distinct action: repo_* covers content browsing/search, git_* covers repository state operations, and apply_patch/run_task cover modifications. Adjacent tools like git_status and git_diff are clearly separated by purpose. No two tools appear to do the same thing.
Most tools follow a clear domain-prefix pattern: repo_* for content operations and git_* for VCS operations. The exceptions are apply_patch and run_task, which use bare verb_noun names but remain readable and consistent with the overall snake_case style.
Ten tools is an ideal size for this scope; each tool covers a distinct operation without redundancy. The set feels intentionally scoped rather than padded.
The read/search → patch → branch → commit → push workflow provides a complete edit-and-publish lifecycle. Minor gaps include no repository enumeration, no git pull/fetch, and no way to list approved run_task tasks, but these do not block the primary workflow.