OpenHuddle
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 | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| team_syncA | See what your team is doing right now: who is online and on which task, the master prompt's state, your tasks, questions waiting for you, and what changed since you last looked. Call it at the start of a session and before starting new work. |
| team_postA | Tell your team something in one or two sentences: a progress update (what you finished, what changed for others) or a decision and why. Never include secrets. |
| team_askA | Ask a teammate's agent a question: what they are doing, whether you may change a file they hold, why they chose something. You get their live status at once; if their agent is active its answer comes back within about 20 seconds, otherwise it arrives later in your team news. |
| team_replyA | Answer a question a teammate's agent asked you (ids like Q3). Answer truthfully from what you actually did and know; say so when you don't know. |
| huddleB | Think together like a real dev team. start: open a huddle, either brainstorm (an open question), design (your proposed approach, for pushback), review (ask teammates to look at a branch, commit or task) or standup (everyone posts done, next, blockers); optionally only with some people. list: open and recently closed huddles. get: read the whole discussion. idea: add an idea. comment: discuss, optionally on one idea. react: back (up) or push back on (down) a teammate's idea, with a reason. close: record what the team decided (whoever started it, or the team owner). |
| master_promptA | The team's shared master prompt: one description of what you are building, co-written by everyone. get: read it. edit: replace or append one section (Idea, Who it is for, Must-haves, Not doing, Tech stack, Look and feel, Done means, Conventions; a new title adds a section). submit: start the team vote. vote: approve or reject the version being voted on. Only edit or vote when your user asks. |
| planA | Turn the locked master prompt into tasks (usually the lead's job) or add tasks later. Contracts first: the first task is always the skeleton (repo setup, shared types and API contracts, database schema, lint/format config) and the other tasks depend on it. Give every task its own folder area and explicit dependencies. create: save a plan (replace=true drops tasks nobody started). add: append tasks. list: show the board. |
| taskA | Work the task board. list: all tasks. take: claim an open task. accept/decline: answer a task proposed to you. start: begin (only when its dependencies are done). update: post a progress note. done: finish, with a one-line note on what changed for others. release: give it back. assign: give a task to a teammate. |
| claimA | Reserve files you are about to change so teammates' agents don't edit them at the same time (files you edit are claimed automatically for 30 minutes). check: see whether files are held by someone or sit in a teammate's task area. release: free files you are done with. |
| team_settingsA | Read or change how the team works, when your user asks. Team-wide rules can only be changed by the team owner: assign_mode (self: people pick tasks, agent: the lead assigns, hybrid: the lead proposes and each person accepts), master_prompt_approval (all, majority or owner), claim_mode (ask: pause and ask the user before editing a file a teammate holds, block: refuse, warn: only tell) and claim_ttl_min (how long claims last). Anyone can set lead (who the lead, the main agent, is) and my_strengths (what you are good at, used for assignments). auto_respond is personal: whether your agent answers waiting questions and huddles before it finishes a turn. |
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 10 tools
The tools mostly map to distinct resources (file claims, huddles, settings, master prompt, plan, tasks, comms), but the communication/update surfaces overlap: team_post (progress/decisions), task.update (progress note) and huddle.comment all serve as places to report status, and team_ask's 'may I change a file they hold' overlaps with claim.check. Descriptions help steer choices but a reasonable agent could still misfile an update.
Conventions are mixed: bare verbs/domain nouns (claim, huddle, plan, task), noun-style resource names (team_settings, master_prompt), and a team_ verb prefix for messaging (team_ask, team_post, team_reply, team_sync). The team_ cluster is consistent, but the overall set mixes several patterns.
Ten tools for a full team-coordination domain is well-scoped, and each bundles coherent sub-actions (huddle modes, task lifecycle, master-prompt voting) rather than exploding into dozens of endpoints. No tool feels redundant or thin.
Coverage is broad—file locking, discussion, settings, shared prompt, planning, task board and team messaging—so core coordination workflows have no dead ends. Minor gaps remain (no task deletion, leave-team, or notification management), but agents can work around them.