Skip to main content
Glama
912925635

Codex Team Workbench

by 912925635

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
PLUGIN_DATANoOptional base plugin data directory. When TEAM_WORKBENCH_DATA is not set, the server uses PLUGIN_DATA/team-workbench.
TEAM_WORKBENCH_DATANoOptional path to the explicit data directory. When set, it takes precedence over PLUGIN_DATA/team-workbench and the default .team-workbench directory under cwd.

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
{}
resources
{}

Tools

Functions exposed to the LLM to take actions

NameDescription
team_panelB

Open the persistent shared task board and team map. With boardId, remember that selection if the host supplies anonymous session metadata; {} reopens it. This correlation is not a native Codex thread ID. Does not discover or control agents.

team_snapshotB

List boards or read one board, including task revisions and source-labeled member observations. No native agent discovery.

team_create_boardB

Create an empty local team board. Does not create any agent or thread.

team_bind_sessionA

Bind or explicitly change a board conversation using a full native UUID. A change requires exact previousSessionId, confirmRebind=true and evidence after showing old/new IDs and history isolation to the user. Old members, executions and snapshots retain their original source and cannot be synced under the new origin. Never guess an ID.

team_archive_boardA

Archive or restore a workbench after explicit user confirmation of scope. This is reversible; it never deletes tasks, member records, transcripts or project files and does not stop agents.

team_observe_runtimeB

Record an actual collaboration list_agents or wait_agent state for the exact recorded runtime path. Evidence and observation time are lead-relayed and not server-authenticated; stale observations cannot overwrite newer ones. resumeAvailable is only true when the lead actually sees the exact agent and has the supported followup tool.

team_report_memberB

Record a caller-reported member and state, labeled reported. Does not create, verify, resume, or control a native agent. actor IDs are conventions, not authenticated identities.

team_create_taskA

Create an unassigned pending task with optional dependencies. Task assignment alone does not dispatch work to any agent.

team_update_taskA

Update a shared task with expectedRevision. Refresh after STALE_REVISION. actorId declares a workflow role, not host identity. Supports claim, release, complete, reopen, edit, dependencies, reassign, soft delete.

team_request_executionB

Request native execution through the lead. Starts no agent; the lead must use actual host collaboration tools and record their returned reference.

team_record_executionB

Record a real lead spawn receipt, worker start/result, or parent-collected result. These are reported observations, not authenticated runtime telemetry. Never invent runtimeRef or success. confirm completes the task only after worker report and collection.

team_record_workflowB

Record an actual caller-owned workflow/run group, with source evidence and revision. This groups agents visually and does not replace their actual parent relationships or start any work. Use expectedRevision=0 for a new group.

team_append_recordB

Append an explicitly agent-reported, user-visible work record, not a native transcript. Use a unique recordId for idempotent retry. Do not collect hidden reasoning, credentials, or private session files. All content stays labeled reported.

team_read_recordsB

Page recorded work observations, relayed public-host snapshots and execution receipts for one node. Does not directly read native threads or private host sessions/databases. Complete-native access is explicitly distinguished from stored bounded snapshots.

team_import_thread_pageB

Relay a bounded page actually returned by the public codex-app-tools.read_thread host tool for an explicitly bound member. Starts no model and calls no host API itself. Exact threadId binding required. Import selected visible messages/status/tool summaries, never reasoning or credentials. Snapshots remain marked agent-relayed, paginated/possibly truncated, not complete native transcripts.

team_bind_agent_activityB

Resolve and register one recorded child using exact subAgentActivity path/UUID items relayed from its recorded spawning parent. Does not read host history itself. Never substitutes another parent or guesses a UUID. Returns nextRead only after unique mapping; missing/ambiguous/unavailable sources are stored as visible resolution states.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription
Team Workbench

TDQS

B3.3/5.0

Scored across 16 tools

Disambiguation3/5

Most tools have distinct roles, but several recording/observation tools overlap conceptually: team_observe_runtime, team_report_member, team_record_execution, team_record_workflow, team_append_record, and team_import_thread_page all involve relaying or storing evidence with subtle source-label boundaries. team_panel vs team_snapshot also both deal with opening/reading board state, though descriptions help distinguish them.

Naming Consistency4/5

Almost all tools use a consistent team_ prefix and snake_case, and most follow a verb_noun pattern. The main deviations are noun-like names such as team_panel and team_snapshot, but the overall convention remains predictable.

Tool Count3/5

The server covers a complex workbench domain, so 16 tools is not unreasonable, but it sits at the edge where the set starts feeling heavy. The many recording/observation variants add cognitive load beyond a tightly scoped tool surface.

Completeness4/5

Core lifecycle operations are covered: boards can be created, viewed, bound, archived, and restored; tasks can be created and updated with claim/release/complete/reopen/soft delete; execution and record workflows exist. Minor gaps remain around explicit board metadata updates or direct task/member listing outside snapshots, but agents can generally work around them.

Maintenance

ActivityMaintained
ResponsivenessNo issues