perch-agent
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| PERCH_AGENT_CLI | No | Explicit path to the Perch CLI's JS entry. Point this at the .js file, not the .cmd shim. | auto-resolve |
| PERCH_AGENT_MODEL | No | Default model pin for every delegation. | standard |
| PERCH_AGENT_EFFORT | No | Default reasoning effort. | high |
| PERCH_AGENT_DEFAULT_CWD | No | Fallback cwd when the caller omits one. | OS temp dir |
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 |
|---|---|
| delegate_to_perchA | Delegate a task to Perch AI (worker agent) via the official perch CLI. Perch runs autonomously in the given working directory with its own tools (bash, file read/write, skills) on the signed-in Perch plan. Karpathy working guidelines (assumptions, simplicity, surgical scope, evidence-based verification) are prepended to every task by default (guidelines:false to disable). Returns the final answer, thread id, and status. Long-running tasks: pass wait_seconds to bound blocking; if still running you get a job_id — poll perch_job_status. |
| perch_job_statusC | Get status/result of a delegated Perch job by job_id. |
| perch_job_cancelB | Kill a running delegated Perch job (process tree). |
| perch_statusA | Free local check (no model call): perch CLI presence and sign-in state, plus this server's live job list. Call before delegating if unsure the worker is ready. |
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
Each tool maps to a distinct operation: delegate, poll a job, cancel a job, and a local readiness check. The only potential confusion is between perch_job_status (job result by job_id) and perch_status (free local CLI/sign-in plus job list), but the descriptions explicitly separate these and note the 'no model call' distinction.
All names are snake_case and prefixed around 'perch', which helps grouping, but the structural patterns vary: delegate_to_perch (verb_prep_noun), perch_job_status (noun_noun), perch_job_cancel (noun_verb), perch_status (noun_noun). The verb position shifting between prefix, suffix, and infix makes the set less predictable than a uniform verb_noun scheme.
Four tools is a tight, well-scoped surface for an async delegation server: dispatch, check, cancel, and readiness. Nothing appears extraneous, and the job-list functionality is folded into perch_status rather than adding a fifth tool.
The async lifecycle (delegate → poll → cancel) plus a pre-flight readiness check is fully covered. Minor gaps remain: the delegate response returns a thread id but there is no tool to resume/follow up on an existing thread, and no way to stream or fetch intermediate logs for a long-running job.