pi-connector-cc
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| PI_BIN | No | Set this if `pi` is not on `PATH`. | |
| PI_CONNECTOR_CONFIG | No | Overrides the optional config file path (default is `~/.config/pi-connector/config.json`). | |
| PI_CONNECTOR_OLLAMA_URL | No | Overrides the Ollama URL. | |
| PI_CONNECTOR_DEFAULT_MODEL | No | Overrides the default model (default is `bonsai-2:9b`). | |
| PI_CONNECTOR_PRINT_TIMEOUT | No | Overrides the print timeout. | |
| PI_CONNECTOR_DEFAULT_ENDPOINT | No | Overrides the default Ollama endpoint (default is `http://localhost:11434/v1`). | |
| PI_CONNECTOR_INACTIVITY_TIMEOUT | No | Overrides the inactivity timeout. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
pi-connector MCP
This connector delegates work to a small local model served by Ollama through the pi harness. The model name, endpoint, and context setting are in every result header.
Work is done by a small local model served by Ollama, via the pi harness. The model name, endpoint, and context setting are in every result header.
Expect narrow, well-scoped edits and read-only questions to succeed. Broad refactors, multi-file design work, and tasks without a verify command will fail or come back needs_review.
The model does not reliably verify its own work. The connector does. Trust the status, changed_files, and verify lines. Routine protocol: scope the task, launch, wait, read the header. For completed, skim the diff stat and move on. For needs_review, incomplete, or failed, read the diff and decide. Do not treat the model's prose as evidence of completion.
Tools: pi_setup, pi_models, pi_execute, pi_research, pi_result, pi_wait, pi_list, pi_cancel, and pi_configure. Execute and research jobs run in the background; always call pi_wait or poll pi_result after launch. Write tasks run in disposable sandboxes and never modify the caller's working tree. Read the status, changed_files, and verify lines before accepting a result.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| pi_setupA | Report pi, Ollama, configured endpoints, models, and context settings without changing state. |
| pi_modelsC | List Ollama models for one endpoint, host, or all configured endpoints. |
| pi_executeC | Launch a scoped write task in a disposable git worktree or declared-file copy sandbox. Returns a job_id; wait for and inspect the result. |
| pi_researchC | Launch a strictly read-only research task. Returns a job_id; wait for and inspect the result. |
| pi_resultC | Get a non-blocking status or result. Trust status, changed_files, and verify rather than model prose. |
| pi_waitC | Wait up to 300 seconds for a job, then return its result header. |
| pi_listC | List tracked jobs for a workspace. |
| pi_cancelC | Cancel an active job and terminate its process tree. |
| pi_configureC | Persist an explicit default model, default endpoint, or named endpoint URL. |
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 9 tools
Core actions are clearly separated: pi_execute (write sandbox) vs pi_research (read-only) vs pi_configure (persist defaults) vs pi_setup (read-only report). The main soft overlaps are pi_result vs pi_wait (both fetch job output, distinguished only by blocking behavior) and pi_setup vs pi_models (setup's report includes models). Descriptions do resolve these, so misselection is unlikely but not impossible.
All nine tools share a consistent pi_ snake_case prefix, which makes the set easy to scan. Minor deviation: some names are bare verbs (pi_list, pi_setup, pi_execute) while others are nouns (pi_models, pi_result), so the verb_object pattern isn't fully uniform.
Nine tools is a well-scoped set for a job-orchestration connector. Each tool maps to a distinct lifecycle stage (discover, launch, poll, wait, cancel, configure) with no filler.
The job lifecycle is well covered end to end: launch (execute/research), observe (result/wait), cancel, plus discovery and configuration. Gaps are minor—no explicit log/diff retrieval, no job cleanup or delete, and no way to resume/retry a failed job.