Session Multiplayer

Official

by wybe-labs

Overview Schema Related Servers Score Discussions

JavaScript

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.3.0
Disambiguation5/5
Each tool maps to a distinct action: invite creation, joining, sending, checking unread messages, reading history, status, display name, and leaving. The closest pair, check_messages and show_history, is clearly separated by clearing versus non-destructive reading.
Naming Consistency4/5
The tool set overwhelmingly follows a verb_noun pattern (create_invite, join_room, send_message, check_messages, show_history, set_display_name, leave_room). The single noun-only tool, status, is a minor deviation that could have been get_status.
Tool Count5/5
Eight tools is well-scoped for a session-multiplayer collaboration server. Each tool addresses a real user or agent need without redundant surface area.
Completeness5/5
The core workflow is fully covered: invite/join/leave room lifecycle, sending and receiving messages, non-destructive history, status visibility, and profile naming. There are no obvious dead ends or missing operations that would prevent the primary multiplayer session use case.
Average 4.4/5 across 8 of 8 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 30 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It indicates a mutation of the peer-visible name, which is transparent about the operation's primary effect. It does not clarify persistence, whether past messages are affected, or any permission/error conditions, but for a simple setter this is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single concise sentence that front-loads the action and resource, with no filler or redundancy. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter, no-output-schema setter, the description is largely complete: it states the operation, the target attribute, and the audience. Minor gaps like return value, error behavior, and scope of effect (future messages vs history) are not critical for basic invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain the parameter. It does so directly: 'name' is the display name shown to peers. This adds meaning beyond the bare schema property and resolves ambiguity about what kind of 'name' is expected.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Set') and a specific resource ('display name'), and clarifies the exact scope: 'shown to peers on your messages'. This clearly distinguishes it from sibling tools like send_message, status, or join_room.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description's effect is clear enough to imply its use case — call when you need to change the name peers see on your messages. However, it gives no explicit guidance on when not to use it or how it compares to alternatives (e.g., whether it affects history).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description alone must signal behavioral traits. The verb 'Show' strongly implies a read-only operation with no side effects, and the list of returned data is helpful. Still, it does not explicitly state that no state is changed, nor mention freshness, permissions, or failure behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficiently structured sentence that front-loads the action ('Show') and then lists the distinct data categories in a readable sequence. Every listed item adds useful information, with no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless status tool with no output schema, the description provides a comprehensive semantic picture of the return content. It covers identity, rooms, peers, member activity, message queue, and unread count, which is sufficient for an agent to understand the tool's full scope without needing additional detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description does not need to explain any parameter semantics because there are none, and it accurately focuses on what the tool returns.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with a specific verb, 'Show', and names the resource (multiplayer status) along with a detailed enumeration of the exact information returned: display name, rooms, peers, members with last-seen times, queued messages, and unread count. This clearly distinguishes it from sibling tools like check_messages or show_history, which focus on narrower message or history concerns.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied by the tool name and the listed contents: call this when you need a broad multiplayer status snapshot. However, there is no explicit guidance about when to prefer this over alternatives such as check_messages or show_history, and no exclusions or conditions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden and does so thoroughly. It discloses waiting up to 90 seconds for a P2P connection, the requirement that the inviter's session be open, project-directory scoping of membership, and that joining announces user details (display name, hostname, session label, harness) to all members. These are non-obvious side effects and constraints an agent must know.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Although longer than a one-liner, every sentence adds distinct value: purpose, cross-harness compatibility, timeout and prerequisite, project scoping, and user-announcement behavior. The most important facts (purpose, timeout, prerequisite) are front-loaded, and there is no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purose, prerequisites, timeout, scoping, and side effects — enough for an agent to invoke it correctly. The main omission is success/error return behavior (e.g., what happens on invalid code or timeout), but since no output schema exists this might be useful. Still, the provided context is strong and complete for the decision to call the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% — the single 'code' parameter is already described with an example format and note that dashes/case are optional. The description only repeats 'invite code from a friend' and adds no new semantic information about the parameter beyond what the schema already provides. Baseline 3 applies because the schema handles parameter documentation fully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Redeem an invite code from a friend to join their room,' which is a specific verb-resource pairing that clearly distinguishes joining from the sibling tool create_invite. The title reinforces the action, so a model can immediately identify what this tool does even without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly defines when to use the tool: when you have a friend's invite code and want to join their room. It provides essential usage conditions: the inviter's session must be open, waits up to 90 seconds, and membership is project-directory-scoped. However, it does not explicitly name sibling tools like create_invite or leave_room as alternatives or state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so well: TTL, single-use, independence of codes, room scoping, P2P/encryption, and the requirement to keep the session open are all disclosed. It also clarifies that expired codes are handled by creating a new one.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The core action is front-loaded in sentence one, and the remaining sentences each add distinct operational detail: expiry/reuse, redemption, scoping, and session requirement. No filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter tool with no output schema and no annotations, this covers the lifecycle end-to-end: creation, code characteristics, delivery, redemption, encryption, scope, and session-lifetime requirement. Nothing needed for correct invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and room_name is already described with an example. The description only refers to 'named room' without adding constraints or naming rules beyond the schema, so it meets the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence states a specific action ('Create (or reuse) a named room') and the concrete deliverable ('short single-use invite code'), with an explicit code format example. This clearly separates it from the sibling join_room, which is the redemption step, and from messaging tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives a concrete workflow: generate a code, share it, have the friend redeem it with join_room, and keep the session open until they join. It does not explicitly enumerate when-not-to-use alternatives, but the flow is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for disclosing side effects. It explicitly states that peer connections stop, other projects' memberships are unaffected, and the action cannot be undone without a new invite—strong transparency for a mutating operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences with no filler. The primary action is front-loaded, and the second sentence adds essential side-effect and irreversibility context efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter tool with no output schema and no annotations, the description covers what happens, scope, side effects, and undo conditions. Nothing essential is missing for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only room_name as a required string with zero description coverage. The description does not directly document the parameter, but the surrounding language makes clear that room_name identifies the room to leave; adequate for a single self-evident parameter but not explicit.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: forget this project's copy of a room's key and stop connecting to its peers. It distinguishes leave_room from sibling tools like join_room and create_invite by focusing on leaving and membership scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The use case is evident: call this when this project wants to leave a room while other projects keep membership. It gives clear contextual effects but does not explicitly name alternatives or state when not to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden, and it clearly discloses the 'Fetch and clear' side effect and the nuance about passive messages. It does not specify whether clearing is permanent deletion or just marking as read, nor describe the return format, which keeps it from a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core action and scope, then provides targeted environment-specific guidance. Both sentences earn their place, and the structure moves from 'what' to 'when' efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool, this is nearly complete: it covers purpose, side effects, delivery behavior, and usage timing. The only notable omission is what exactly the tool returns beyond 'messages' and the permanence of the clearing behavior, especially since no output schema exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero parameters and 100% coverage, so the baseline is 4. The description adds contextual meaning about what 'messages' means and when results arrive, which is sufficient for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Fetch and clear all unread messages from all rooms.' It also distinguishes this from passive delivery and sibling tools by noting it covers 'passive ones that are never auto-delivered.' This makes the tool's unique role clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance: call it 'whenever the user asks what their friends said' and consider checking it when starting or finishing a task. It also distinguishes environments: Claude Code usually delivers automatically via hooks, while harnesses without hooks require this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and fully delivers. It discloses reliability caveats (local queueing and delivery on reconnect when no peer is online), platform dependence (hooks vs. Codex fallback), access-control reality ('to' is best-effort steering, not access control; everyone can read everything), and interruption semantics — all far beyond what the schema encodes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The lead sentence states the core operation, and every subsequent sentence covers a distinct behavior: shared log, priority semantics, harness fallback, recipient scoping, default addressing, and offline queuing. For a four-parameter tool with three delivery modes, the length is proportionate and contains zero fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Thoroughly covers the hardest parts — priority semantics, harness differences, offline queueing, and recipient scoping — for a tool with no output schema. It remains silent on what the call returns on success or failure, and does not mention prerequisites like joining the room first (a join_room sibling exists). Minor gaps against otherwise exceptional coverage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3, but the description adds real meaning: delivery timing behind each priority enum (mid-turn injection at next tool boundary, end-of-turn delivery, inbox-only), the stated default ('normal'), and the best-effort/not-access-control caveat for 'to.' It does not add per-parameter syntax details, but it genuinely clarifies behavior the enum names alone would leave ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Opens with 'Send a plain-text message to a room,' pairing a specific verb with a concrete resource and scope. The detailed coverage of priorities, recipient steering, and queuing makes it unmistakably distinct from siblings like check_messages, show_history, and join_room.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Names an explicit sibling and the condition that selects it: 'on harnesses without hooks, such as Codex, everything lands in the inbox and is read with check_messages.' It also gives usage guidance for priorities ('use sparingly — it barges in') and explains when to include vs. omit 'to.' It does not exhaustively route across all seven siblings, but the send/read distinction is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden. It clearly discloses that the operation is non-destructive, does not clear anything, and includes messages relayed while offline. This goes beyond the schema by describing side-effect-free behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core action, then the key differentiator and usage intent. There is no filler; every sentence adds decision-relevant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with two well-documented parameters and no output schema, the description covers purpose, behavior, limits, and sibling distinction. The agent has everything needed to call it correctly and understand what it will do.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3 even without parameter details in the description. The description does add context like the 7-day window and offline relay, but count and room_name are already well documented in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Read the recent chat log of a room' with clear bounds (200 messages / 7 days). It also distinguishes itself from the sibling tool check_messages by noting this tool clears nothing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly contrasts with check_messages: 'unlike check_messages this clears nothing' and gives the exact use case: 'use it to answer "what did they say earlier?"'. This tells an agent when to select this tool over its sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![session-multiplayer MCP server](https://glama.ai/mcp/servers/wybe-labs/session-multiplayer/badges/card.svg)](https://glama.ai/mcp/servers/wybe-labs/session-multiplayer)

Score Badge

Copy to your README.md:

[![session-multiplayer MCP server](https://glama.ai/mcp/servers/wybe-labs/session-multiplayer/badges/score.svg)](https://glama.ai/mcp/servers/wybe-labs/session-multiplayer)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/wybe-labs/session-multiplayer'

If you have feedback or need assistance with the MCP directory API, please join our Discord server