workbuddy-delegate
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
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": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| workbuddy_statusA | Check the local WorkBuddy bridge, configured limits, and installation without sending a model request. |
| workbuddy_planB | Classify eligibility for bounded delegation without reading files or sending a model request. |
| delegate_to_workbuddyA | Send one bounded low-risk text task to the user's installed WorkBuddy. Use explicit relative files or short provided text. Supported kinds: summarize, extract, classify, translate, rewrite, code_draft. Only risk=low is routed. The main agent must verify the returned result. |
| workbuddy_read_resultB | Read a plugin-created result artifact when its short preview was truncated. |
| workbuddy_usageA | Show local invocation counts. This does not call WorkBuddy or estimate money. |
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
The tools are mostly distinct: status, plan, delegate, read_result, and usage each serve a clear purpose. However, 'workbuddy_plan' (classify eligibility) and 'workbuddy_status' (check limits) could be slightly confused as both are pre-flight checks, but descriptions clarify.
All tools share the 'workbuddy_' prefix and use a consistent verb_noun pattern (status, plan, delegate_to, read_result, usage). 'delegate_to_workbuddy' is slightly more verbose but still fits the pattern, so minor deviation.
With 5 tools, the server is well-scoped for its purpose of managing delegation to WorkBuddy. Each tool covers a distinct aspect: status, planning, delegation, result reading, and usage tracking, which is appropriate.
The surface covers the main lifecycle: check status (status), eligibility (plan), delegate, read result, and usage. A minor gap is the lack of a cancel/abort tool for pending delegations, but the bounded tasks are short-lived, so this is not critical.