patchbay
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| PATCHBAY_LANG | No | `ts` (TypeScript+vitest) or `python` (Python 3.12+pytest). | ts |
| PATCHBAY_MOCK | No | Replay mode. Set to `false` for live runs. | true |
| NEBIUS_API_KEY | No | Nebius API key, needed for live runs. | |
| TAVILY_API_KEY | No | Tavily API key, needed for live runs. | |
| PATCHBAY_RUNNER | No | `nebius` (isolated sandbox) or `local` (dev fallback, TS only). | nebius |
| NEBIUS_AI_PROJECT | No | Nebius AI project ID, needed for live runs. | |
| PATCHBAY_MODEL_MID | No | Mid-tier model. | nvidia/Nemotron 3 Super |
| PATCHBAY_MODEL_FAST | No | Fast model tier. | nvidia/Nemotron 3.5 Lightning |
| PATCHBAY_LLM_BASE_URL | No | Point patchbay at any OpenAI-compatible endpoint, including a self-hosted vLLM serving the fine-tuned Qwen3-30B. | |
| PATCHBAY_LLM_PROVIDER | No | LLM provider for the OpenAI-compatible endpoint. | nebius |
| PATCHBAY_MAX_ATTEMPTS | No | Repair-loop cap. | 3 |
| PATCHBAY_MODEL_STRONG | No | Strong model tier. | nvidia/Nemotron 3 Ultra |
| PATCHBAY_PARALLEL_REPAIRS | No | N parallel repair branches per attempt (max 4). Best-of-N. | 1 |
| PATCHBAY_REPAIR_LLM_BASE_URL | No | Points patchbay's repair step at the self-hosted fine-tuned model behind a vLLM OpenAI-compatible endpoint. |
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
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| build_connectorA | Describe an integration in one sentence ("When X happens in A, do Y in B"). patchbay plans it, researches both APIs, generates a connector with tests and a README, then verifies it in a sandbox with up to N repair attempts. Default language is TypeScript (vitest); set lang: "py" for Python 3.12 (pytest). Falls back to the recorded TypeScript replay run when live API keys are missing. |
| research_apiB | Plan + Tavily-backed API research only. Returns the connector plan, the ranked documentation sources, and a normalized API spec (endpoints, auth, example payloads). No code is generated and no sandbox is used, so this is cheap and fast. |
| scan_repoA | Walk a repository (local directory or shallow-cloned GitHub URL) and report the integration opportunities patchbay could build: webhook handlers with TODO/empty bodies, .env.example entries pointing at vendor APIs with no implementation, TODO/FIXME comments mentioning vendors, and vendor SDKs imported but barely used. Understands TypeScript/JavaScript (Express/Next/Fastify routes) AND Python (FastAPI/Flask routes, pass bodies, raise NotImplementedError). Returns a ranked list, each item with a ready-to-run prompt the agent can hand straight to build_connector. Instant, free (no LLM / sandbox), auditable regex-only output. |
| verify_codeA | Type-check and test an existing connector (files you provide as {path, content}) in an isolated Nebius sandbox, with up to N repair attempts from the strong model. For TypeScript (default) the gate is tsc + vitest; for Python (lang: "py") it is compileall + pytest. Requires live keys (NEBIUS_API_KEY, NEBIUS_AI_PROJECT); returns the final test report and the (possibly repaired) files. |
| audit_mcp_serverA | Scan a remote MCP server URL (or a local MCP connector directory) for OAuth 2.1, RFC 8707 audience validation, RFC 8252 loopback redirects, OAuth metadata, scope posture, secret surface, tool manifest drift, and tool-description prompt injection patterns. Returns a letter grade, numeric score and the full findings list. Runs zero-auth probing by default (metadata-level checks only). Pass "authToken" to probe behind authentication. Pass "probeAudienceToken" to enable AUDIENCE-001 (cross-audience token check, RFC 8707). Pass "probeMissingAudToken" to enable AUDIENCE-002 (missing-aud-claim check, catches the if (aud && aud !== me) reject early-exit bug). Pass "probeDcrLoopback: true" to enable AUTH-006 (writes a throw-away client registration to the authorization server). The scanner never calls any of the server's tools. |
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 5 tools
build_connector bundles research and verification that research_api and verify_code expose separately, so an agent may briefly consider which layer to use. The descriptions make the boundaries clear enough (cheap research-only vs. full build vs. existing-code verification), while scan_repo and audit_mcp_server are distinctly scoped.
All five tools follow a consistent snake_case verb_noun pattern: build_connector, research_api, scan_repo, verify_code, audit_mcp_server. The action and target are predictable across the set.
Five tools cleanly cover the core workflows: discover opportunities, research APIs, build connectors, verify code, and audit MCP security. There are no filler tools and the surface is not bloated.
The connector lifecycle is well covered from repository scanning through research, generation, and sandbox verification. Minor gaps exist around deployment/publishing or connector listing/management, and the MCP audit is somewhat orthogonal to the connector-building workflow.