io.github.nika110/openhuddle
NPM · OPENHUDDLE
Multiplayer mode for AI coding agents: team huddles, master prompt, task board, file claims.
Available components
Last scanned (1 hour ago)
Scores higher than 92% of npm servers
Category Project Management
How this component scores in each security and reliability category. Every signal is checked automatically from public evidence about the published package, including repeated runs of it in an isolated sandbox, and we only credit what we can confirm. How we score → Why this is hard to score →
Supply Chain Security100
- No malware found by supply-chain analysis.Pass
- No known CVEs affecting this package version or its production dependencies.Pass
- No install/post-install scripts declared.Pass
- No production dependencies, so there is no dependency health to assess. View diagnostics → Pass
Provenance & Transparency100
- Source repository is publicly reachable at the declared URL. View diagnostics → Pass
- Cryptographically verified build provenance (signed, bound to nika110/openhuddle). View diagnostics → Pass
- Clear OSI-approved license (MIT).Pass
- Actively maintained (last published 17 days ago).Pass
- Publishes a security disclosure policy (SECURITY.md).Pass
Schema Quality & AI Usability64
- AI-judged instruction clarity (good).Pass
- Context-footprint check failed: tool/resource definitions use about 2066 tokens (~206/item across 10 items; 10 tools + 0 resources), over budget; trim descriptions and params. See how to fix → Fail
- Usage-examples check failed: none of the tools include examples. See how to fix → Fail
Stability & Change Management60
- Stability observed for 18 of 30 days with no destabilising changes; credit accrues until the full window elapses.Partial
Tool Coverage100
- 100% of tools have a non-trivial description (not blank, and not just the tool's name).Pass
- 100% of tool parameters carry a description.Pass
Tool Safety100
- No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.Pass
- We read all 10 captured tool definition(s), and no name or description among them implies an irreversible operation.Pass
- An AI judge read all 11 captured unit(s) of tool text and found none that tries to manipulate the model reading it.Pass
Capabilities100
- Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.Pass
Every change we have recorded for this component, newest first. Security-relevant changes are always shown. ▲ marks a change for the better, ▼ a change for the worse; unmarked changes are neutral.
- 4 Nov 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 53 to 57. That category is still filling its 30-day observation window: 16 days of observed history at the previous scan, 17 at this one. The score rises as the window fills, whether or not the server changes.
- 2 Nov 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 47 to 50. That category is still filling its 30-day observation window: 14 days of observed history at the previous scan, 15 at this one. The score rises as the window fills, whether or not the server changes.
- 31 Oct 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 40 to 43. That category is still filling its 30-day observation window: 12 days of observed history at the previous scan, 13 at this one. The score rises as the window fills, whether or not the server changes.
- 29 Oct 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 33 to 37. That category is still filling its 30-day observation window: 10 days of observed history at the previous scan, 11 at this one. The score rises as the window fills, whether or not the server changes.
- 27 Oct 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 27 to 30. That category is still filling its 30-day observation window: 8 days of observed history at the previous scan, 9 at this one. The score rises as the window fills, whether or not the server changes.
- 25 Oct 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 20 to 23. That category is still filling its 30-day observation window: 6 days of observed history at the previous scan, 7 at this one. The score rises as the window fills, whether or not the server changes.
- 23 Oct 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 13 to 17. That category is still filling its 30-day observation window: 4 days of observed history at the previous scan, 5 at this one. The score rises as the window fills, whether or not the server changes.
- 20 Oct 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 3 to 7. That category is still filling its 30-day observation window: 1 days of observed history at the previous scan, 2 at this one. The score rises as the window fills, whether or not the server changes.
Diagnostic detail from the automated scan of this channel: what the scanner observed at each step, so you can see exactly where a check passed or failed. It is informational only and never changes the trust score.
Captured 5 Nov 2026 · Analysed npm/openhuddle@0.4.1
Provenance Verified
A signed build attestation was found and verified, binding this exact artifact to the source repository it claims to come from.
| Result | Verified |
|---|---|
| Ecosystem | npm |
| Reason | Verified |
| Discovered via | Registry attestation endpoint |
| Source repo | nika110/openhuddle |
| Certificate issuer | https://token.actions.githubusercontent.com |
| Certificate SAN | https://github.com/nika110/openhuddle/.github/workflows/publish.yml@refs/tags/v0.4.1 |
| Rekor log index | 3317377514 |
| Predicate type | SLSA build provenance https://slsa.dev/provenance/v1 |
| Subject digest | sha512:4c290b8dccbd5afa8bbf427e99c235b4d2d41119904a6b76b76139f7af5747ce1543a734eda0304cd91570aa64ccc290aed99b9c39ac126c0d6e6f66b |
Background: How many MCP packages publish verified provenance →
Dependencies 0 packages
| Packages resolved | 0 |
|---|---|
| Tree resolution | Complete |
Background: SBOMs and build attestations, explained →
The tools this component advertises to a client, with an estimated token cost for each. Expand a tool to see its parameters and schema. The per-tool counts are indicative and are not scored directly; the schema's total context footprint is one signal in Schema Quality & AI Usability. A tool's description is untrusted text the model reads on every call, which is what makes this list a security surface and not just an inventory: how tool poisoning works →
claim ~104
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.
| Name | Type | Req | Description |
|---|---|---|---|
| action | string | yes | What to do. |
| paths | array | yes | File paths (relative to the repo or absolute). |
| task_key | string | – | Optional task the claim belongs to. |
No output schema declared.
No examples provided.
huddle ~374
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).
| Name | Type | Req | Description |
|---|---|---|---|
| action | string | yes | What to do. |
| context | string | – | start: background the team needs: constraints, what you tried, the branch or commit to review. |
| decision | string | – | close: what the team settled on. |
| id | string | – | Huddle id, e.g. H2 (all actions except start and list). |
| idea | number | – | react: the idea number; comment: optional idea number the comment is about. |
| kind | string | – | start: what kind of huddle. |
| note | string | – | react: your reason. |
| people | array | – | start: teammates to huddle with. Leave out for the whole team. |
| proposal | string | – | start: your proposed approach (required for design; becomes idea #1). |
| text | string | – | idea/comment: what you want to say. |
| topic | string | – | start: the question or subject, in one line. |
| vote | string | – | react: up to back the idea, down to push back. |
| why | string | – | close: the reason, in a sentence or two. |
No output schema declared.
No examples provided.
master_prompt ~177
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.
| Name | Type | Req | Description |
|---|---|---|---|
| action | string | yes | What to do. |
| approve | boolean | – | true to approve, false to reject (vote). |
| comment | string | – | Optional note with your vote. |
| mode | string | – | replace (default) or append (edit). |
| section | string | – | Section title (edit). |
| text | string | – | New section text (edit). |
No output schema declared.
No examples provided.
plan ~135
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.
| Name | Type | Req | Description |
|---|---|---|---|
| action | string | yes | What to do. |
| replace | boolean | – | create only: remove tasks that nobody has started. |
| tasks | array | – | Tasks to create or add. |
No output schema declared.
No examples provided.
task ~156
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.
| Name | Type | Req | Description |
|---|---|---|---|
| action | string | yes | What to do. |
| assignee | string | – | Teammate's name (assign). |
| branch | string | – | Git branch (start/done). Defaults to your current branch. |
| key | string | – | Task key, e.g. T3. |
| note | string | – | Progress note (update/done). |
No output schema declared.
No examples provided.
team_ask ~88
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.
| Name | Type | Req | Description |
|---|---|---|---|
| question | string | yes | Your question. |
| to | string | yes | The teammate's name. |
No output schema declared.
No examples provided.
team_post ~86
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.
| Name | Type | Req | Description |
|---|---|---|---|
| kind | string | yes | "update" for progress, "decision" for a choice the team should know about. |
| text | string | yes | The message. |
| why | string | – | For decisions: the reason. |
No output schema declared.
No examples provided.
team_reply ~67
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.
| Name | Type | Req | Description |
|---|---|---|---|
| answer | string | yes | Your answer. |
| ask_id | string | yes | The question id, e.g. Q3. |
No output schema declared.
No examples provided.
team_settings ~308
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.
| Name | Type | Req | Description |
|---|---|---|---|
| action | string | yes | What to do. |
| assign_mode | string | – | How tasks get assigned. |
| auto_respond | boolean | – | Yours only (Claude Code): before finishing a turn, answer teammates' questions and huddles waiting for you. On by default. |
| claim_mode | string | – | What happens when you try to edit a file a teammate holds. |
| claim_ttl_min | number | – | Minutes a claim lasts without activity. |
| lead | string | – | Teammate's name to make lead (main agent). |
| master_prompt_approval | string | – | Who must approve the master prompt. |
| my_strengths | string | – | What you are good at, e.g. "frontend, design". |
No output schema declared.
No examples provided.
team_sync ~61
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.
Input schema present but exposes no named parameters.
No output schema declared.
No examples provided.
How do I install the io.github.nika110/openhuddle MCP server?
io.github.nika110/openhuddle runs locally as an npm package, launched with npx -y openhuddle. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.
npm · openhuddle
claude mcp add nika110-openhuddle -- npx -y openhuddle
What is the io.github.nika110/openhuddle MCP server?
io.github.nika110/openhuddle is an MCP server listed in the public MCP registry as io.github.nika110/openhuddle. Multiplayer mode for AI coding agents: team huddles, master prompt, task board, file claims. This page covers its npm package (openhuddle).
Is the io.github.nika110/openhuddle MCP server safe to use?
io.github.nika110/openhuddle scores 88 out of 100 on VerifyMCP. We found no known CVEs affecting it as of 5 November 2026. It declares no install or post-install scripts. Its build provenance is signed and verified. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.
What tools does the io.github.nika110/openhuddle MCP server expose?
io.github.nika110/openhuddle exposes 10 tools: team_sync, team_post, team_ask, team_reply, huddle, and 5 more. Their descriptions and schemas cost roughly 1,556 tokens of context every time the server is loaded.
Is the io.github.nika110/openhuddle MCP server still maintained?
io.github.nika110/openhuddle is still listed as active in the MCP registry. We last reached this channel on 5 November 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.
What licence is the io.github.nika110/openhuddle MCP server under?
io.github.nika110/openhuddle declares the MIT licence, which is OSI-approved. That covers the source only, and says nothing about the cost of any service it calls.