local-vibes
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| LOCAL_VIBES_LANE | No | Default sticky-session id, sent as the standard OpenAI user field (per-call lane overrides) | |
| LOCAL_VIBES_MODEL | No | Model name on that endpoint | qwen3-coder:30b |
| LOCAL_VIBES_API_KEY | No | Sent as the key; local servers ignore it | not-needed |
| LOCAL_VIBES_BASE_URL | No | OpenAI-compatible endpoint | http://localhost:11434/v1 |
| LOCAL_VIBES_MAX_ITERS | No | Max model↔tool round-trips per task | 25 |
| LOCAL_VIBES_ALLOW_BASH | No | 0 disables the run_bash tool entirely | 1 |
| LOCAL_VIBES_EXTRA_BODY | No | JSON object merged into every request body — superset passthrough | {} |
| LOCAL_VIBES_LANE_HEADER | No | Optional: also send the lane under this custom header (opt-in; for header-routing servers) | |
| LOCAL_VIBES_TEMPERATURE | No | Default sampling temperature (per-call temperature overrides) | 0.1 |
| LOCAL_VIBES_BASH_TIMEOUT | No | Per-command timeout (seconds) | 120 |
| LOCAL_VIBES_MAX_CONCURRENCY | No | Cohort width — concurrent delegate loops offered to the backend | 8 |
| LOCAL_VIBES_TOOL_RESULT_CAP | No | Max chars of any tool result fed back to the model | 12000 |
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 |
|---|---|
| delegateA | Delegate a self-contained coding or research task to a LOCAL model running in its own sandboxed agent loop. USE PROACTIVELY to offload grunt work — codebase searches, boilerplate, mechanical multi-file edits, test scaffolding — instead of doing it inline. The subagent reads/edits files and runs shell commands confined to |
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 1 tool
Only one tool exists, so there is no ambiguity or overlap between tools. The tool's purpose is clear and distinct by default.
With a single tool named 'delegate', there is no pattern to contradict. The name is a simple, clear verb that aligns with its action.
The server has only one tool, which feels thin and borderline. However, the tool is broad enough to cover a variety of delegation tasks, making it somewhat self-sufficient despite the low count.
The delegate tool covers the core workflow of delegating tasks and receiving results, which is sufficient for the stated purpose. Minor gaps exist around task management (e.g., status, cancellation), but the synchronous design makes these less critical.