DevPilot MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| HOST | No | HTTP listen address (remote mode; 127.0.0.1 in local mode). | 0.0.0.0 |
| PORT | No | HTTP listen port (remote mode). | 3000 |
| GITHUB_TOKEN | No | Fine-grained PAT. Read-only, public repos only for the hosted deployment. | |
| INSTALL_DEPS | No | Whether to install deps (remote mode). | true |
| TEST_COMMAND | No | Override the detected test command (local mode). | auto-detect |
| ALLOWED_HOSTS | No | Host-header allowlist for public binds (remote mode). | Render hostname |
| ALLOWED_REPOS | Yes | Required in remote mode. Comma-separated allowlist of repos: owner/repo[@ref][:subdir],… | |
| DEVPILOT_MODE | No | Mode: local or remote. | local |
| TEST_COMMANDS | No | JSON {"owner/repo": "command"} mapping test commands per repo (remote mode). | {} |
| WORKSPACES_DIR | No | Where to clone repos (remote mode). | /tmp/workspaces |
| WORKSPACE_ROOT | No | Repo to operate on (local mode). | cwd |
| TEST_TIMEOUT_MS | No | Test run timeout. | 120000 |
| DEVPILOT_API_KEY | No | Bearer token for /mcp. Unset means a public demo (remote mode). | |
| MAX_OUTPUT_CHARS | No | Cap on any tool's text response. | 20000 |
| RATE_LIMIT_PER_MIN | No | Per-IP limit on /mcp (remote mode). | 60 |
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": true
} |
| prompts | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_issueA | Fetch a GitHub issue with its discussion: title, state, labels, author, dates, body, recent comments, and linked pull requests. Read-only. Start here when triaging an issue. |
| analyze_issueA | Deterministically extract triage signals from an issue (no LLM): a type guess (bug/feature/question/docs), error messages, parsed stack frames (JS and Python), mentioned file paths, fenced code blocks, and suggested queries to pass to search_codebase. |
| search_codebaseA | Search the workspace with ripgrep (respects .gitignore; skips node_modules, dist, lockfiles and binaries). Returns matching lines with surrounding context and paths relative to the workspace root. |
| get_docsA | Read project documentation (README*, CONTRIBUTING*, root .md, docs/**/.md). With "path": return that file, or just the section whose heading matches "topic". With only "topic": return the 3 best-matching sections ranked by keyword hits. With neither: return the README intro and the list of docs. |
| run_testsA | Run the project's test suite (auto-detects vitest, jest, pytest, or npm test; in remote mode only the server's fixed, configured command runs). Returns pass/fail counts and a run_id; pass the run_id to summarize_test_failures for grouped failures and the source files to fix. |
| summarize_test_failuresA | Summarize the failures of a previous run_tests call: each failing test with its message, top project stack frames, and likely_source_files (non-test files from the stack — where the fix probably goes), plus groups of failures sharing the same normalized error, largest first. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| triage_issue | Walks the agent through get_issue → analyze_issue → search_codebase → run_tests → summarize_test_failures → proposed fix. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 6 tools
Each tool targets a distinct purpose: get_issue fetches raw issue data, analyze_issue extracts deterministic signals, get_docs reads documentation, search_codebase searches code, run_tests executes tests, and summarize_test_failures analyzes test output. The descriptions make the boundaries clear, and while get_issue and analyze_issue both relate to issues, one is read-only fetching and the other is analysis, so misselection is unlikely.
All tool names use snake_case with a consistent verb_noun pattern (get_issue, analyze_issue, get_docs, search_codebase, run_tests, summarize_test_failures). There are no naming outliers or mixed conventions, making the set predictable and easy to scan.
Six tools is well-scoped for a developer triage and test-diagnosis assistant. Each tool earns its place by covering a distinct step in the workflow, with no redundant or filler tools.
The surface covers issue fetching and analysis, docs reading, code search, and test running plus failure summarization, forming a coherent triage loop. However, there is no way to list or search issues, which is a minor gap for a triage-focused server where an agent may need to discover which issue to work on.