RepoRescue MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| OPENAI_API_KEY | No | OpenAI API key for the OpenAI Repair Agent when using the OpenAI model. | |
| REPO_RESCUE_TRANSPORT | No | Transport for the Python MCP server. Omit for Streamable HTTP, 'stdio' for stdio, 'sse' for SSE. | |
| REPO_RESCUE_ACTIONS_REF | No | Protected branch containing the reviewed workflow for the GitHub Actions bridge. | |
| REPO_RESCUE_GITHUB_TOKEN | No | Fine-grained GitHub token with Actions read/write on the bridge repository. Required for platform mode and the XFYun competition deployment. | |
| REPO_RESCUE_NODE_TOOLSET | No | Selects the Node MCP toolset. Set to 'snippet' for snippet-only hosting, 'platform' for the GitHub Actions bridge, or omit for the default legacy toolset. | |
| REPO_RESCUE_OPENAI_MODEL | No | Model name for the OpenAI Repair Agent. | gpt-5.6-terra |
| REPO_RESCUE_ALLOWED_REPOS | No | Comma-separated list of allow-listed public Python repositories for project rescue, e.g., owner/broken-repository. | |
| REPO_RESCUE_ACTIONS_WORKFLOW | No | Workflow filename for the GitHub Actions bridge, e.g., repo-rescue-actions-bridge.yml. | |
| REPO_RESCUE_EXECUTION_BACKEND | No | Execution backend for untrusted repository code. 'docker' (default) or 'direct' only inside a disposable container. | docker |
| REPO_RESCUE_ACTIONS_REPOSITORY | No | Owner/repo for the GitHub Actions bridge, e.g., wenjieding327/repo-rescue-mcp. | |
| REPO_RESCUE_ACTIONS_EXPECTED_HEAD_SHA | No | Optional expected 40-character bridge commit SHA for release-ref assertion. | |
| REPO_RESCUE_ALLOWED_ADDITIONAL_DEPENDENCIES | No | Optional administrator-approved additional dependency distribution names. |
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
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| rescue_python_snippetA | Actually run a student's original and AI-repaired Python snippet in separate disposable WebAssembly child processes. Use after generating a minimal fix so the answer can show before/after evidence instead of an unverified suggestion. |
| inspect_github_projectA | Inspect a profiled, allow-listed public GitHub repository and return its exact commit and project evidence. Repositories without an explicit verification profile return unsupported. |
| reproduce_python_projectB | Compatibility endpoint that refuses Node-side repository execution and directs callers to the Python MCP Docker backend. |
| windows_environment_probeA | Return a non-mutating PowerShell probe the user can run locally; never claims automatic computer access. |
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 4 tools
The four tools have largely distinct roles: probing the Windows environment, running Python snippets, inspecting a GitHub repository, and routing full-project reproduction. The only possible overlap is between rescue_python_snippet and reproduce_python_project, but their descriptions clearly separate snippet-level execution from repository-level routing.
Three tools follow a verb_noun snake_case pattern, while windows_environment_probe is a noun phrase and does not fit the imperative style. The naming is still readable and not chaotic, but the deviation prevents a higher score.
Four tools is a compact, well-scoped count for this server. Each tool has a defined responsibility, and there is no sign of unnecessary duplication or bloat.
The set supports evidence gathering but leaves key rescue workflows incomplete: there is no actual repair/apply operation, no way to run a full project in this server, and reproduce_python_project explicitly refuses to execute. Additionally, windows_environment_probe returns a script but has no matching tool to ingest the result, so agents can easily hit dead ends.