Skip to main content
Glama
BenjaminNH

workbuddy-subagent-bridge

by BenjaminNH

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault

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

CapabilityDetails
tools
{}

Tools

Functions exposed to the LLM to take actions

NameDescription
workbuddy_session_startA

Start a current-version WorkBuddy session. ACP mode returns a taskId immediately by default; poll status and request the report after completion. Set waitForCompletion=true when a blocking report is preferred.

workbuddy_session_sendC

Send a follow-up message to the same WorkBuddy session.

workbuddy_session_statusA

Read task/session status and any pending ACP permission requests without sending a prompt.

workbuddy_session_cancelC

Cancel the active WorkBuddy session.

workbuddy_session_closeB

Close the local ACP process and mark the task completed.

workbuddy_session_permission_replyA

Reply to a pending ACP permission request. Inspect workbuddy_session_status first and pass the raw response payload expected by the current WorkBuddy version.

workbuddy_session_reportA

Read the in-memory report produced by a completed prompt. Reports are not persisted in the task registry.

workbuddy_statusA

List persisted WorkBuddy tasks and their current lifecycle status.

workbuddy_modelsB

List models returned by the current WorkBuddy ACP session/new response.

workbuddy_doctorB

Check Node, CodeBuddy CLI, and ACP stdio initialization.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A3.5/5.0

Scored across 10 tools

Disambiguation4/5

Most tools target distinct session actions (start, send, cancel, close, permission reply, report) and are easy to tell apart. The only potential confusion is between workbuddy_session_status (per-session state) and workbuddy_status (persisted task registry), which are related but serve different purposes.

Naming Consistency4/5

All tools share the workbuddy_ prefix and mostly follow a predictable pattern: workbuddy_session_<verb> for session operations, plus standalone nouns (status, models, doctor). The mix of verb-based session actions with noun-only utility tools is a minor deviation, but the overall convention is clear.

Tool Count5/5

Ten tools is well within the ideal range for a session-bridge server and each one maps to a distinct lifecycle stage or utility concern. No tool feels redundant or unnecessary for the stated purpose.

Completeness4/5

The session lifecycle is well covered: start, send, status, cancel, close, permission reply, and report. The persisted task listing, model enumeration, and environment diagnostic round out the surface. Minor gaps exist, such as no explicit session resume or task-triggered report fetch, but agents can generally work around these.

Maintenance

ActivityMaintained
ResponsivenessNo issues