flotilla-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| REPO_REMOTE | Yes | Git remote URL for the main repository, without embedded credentials. | |
| SELF_DEV_REPO_REMOTE | Yes | Git remote URL for the self-dev bot's repository, without embedded credentials. | |
| WATCHER_GITHUB_TOKEN | No | GitHub token for the Deploy Watcher (contents read-only). Only needed when running the full fleet stack. | |
| GITHUB_REPO_FULL_NAME | Yes | Full name of the GitHub repository (e.g., 'owner/repo'). Required for GitHub API calls. | |
| SELF_DEV_GITHUB_TOKEN | Yes | Fine-grained GitHub token for the self-dev bot, with read/write access to contents, pull requests, and issues. Required for GitHub operations in Self-Dev MCP tools. |
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 | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| start_issueA | Begin work on a GitHub issue: clone the target repository into a fresh,
isolated per-issue workspace and create (or, if one already exists,
resume) a |
| read_fileA | Read a file's contents from the workspace start_issue created for this
issue. |
| write_fileA | Create or overwrite a file inside the workspace start_issue created for
this issue. |
| run_testsA | Run the target repository's own pytest suite for one service, inside the issue's workspace, subject to a timeout. This only executes tests and reports the result -- it never commits or modifies anything. Returns a string starting "OK" or "FAILED" followed by the exit code and captured stdout/stderr, "REFUSED: ..." if the path is option-like, escapes the workspace, or touches '.git', or "ERROR: ..." if the run times out or fails to start -- never raises. |
| submit_prA | Finish work on an issue: commit everything currently in the workspace,
push the |
| list_assigned_issuesA | List open GitHub issues carrying the given label; pull requests are excluded even though GitHub's issues API would otherwise include them. Use this to discover work before calling start_issue. Returns one "# " line per matching issue, a "No open issues labeled " message if none match, or a string starting "ERROR:" on failure -- never raises. |
| check_pr_statusA | Get the combined CI status for a pull request's head commit, from GitHub's Checks API. Returns exactly one of "pending" (no checks yet, or some still running), "success" (all checks completed without failure), or "failure" (at least one check reported a non-success conclusion: failed, cancelled, timed out, required action, or failed to start) -- or a string starting "ERROR:" if the status can't be retrieved (never raises). |
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 7 tools
Each tool owns a distinct stage of the issue-to-PR workflow: discovery, workspace setup, file read/write, test execution, PR submission, and CI status. There is no meaningful overlap between read_file and write_file or between run_tests and check_pr_status.
All seven tools follow a consistent snake_case verb_noun pattern: start_issue, read_file, write_file, run_tests, list_assigned_issues, submit_pr, check_pr_status. The naming is predictable and immediately signals what each tool does.
Seven tools is well-scoped for the server's stated purpose of working through GitHub issues from discovery to PR submission. Each tool earns its place and there are no redundant or filler entries.
The core workflow is covered: discover issues, start an isolated workspace, edit files, run tests, submit a PR, and check CI status. However, there is no way to read issue bodies/comments or list the workspace directory structure, which leaves notable gaps for agents that need to understand requirements or navigate an unfamiliar repository. There is also no explicit abort/discard tool for abandoning work.