Pyrogenesis Fair Player MCP

Overview Schema Source Related Servers Discussions Admin

join_lan_game

Joins an unpassworded 0.28.0 LAN room over Python ENet with a chosen player nickname; the host must start the match first.

Instructions

Join an unpassworded 0.28.0 LAN room through Python ENet. Host must start the match.

nickname is the visible in-room player name; give each model a distinct nickname. player_name remains a compatible alias. Omit both for "MCP Player". If both are supplied they must be identical; conflicting aliases fail before joining. Names must contain 1..32 Unicode characters, include a non-whitespace character and contain no control, surrogate or formatting characters. XMPP lobby discovery/authentication is outside this direct LAN connector.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "host": "<host>"
    },
    "name": "join_lan_game"
  }
}

Input Schema

Name	Required	Description	Default
`host`	Yes
`port`	No
`nickname`	No
`player_name`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 12, 2026

TDQS

A4.1/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations supplied, the description carries the full burden and does disclose concrete behavior: unpassworded rooms only (no password parameter or flow), 0.28.0 protocol gating, and a pre-join failure mode when the two alias fields conflict. It leaves out what a successful join returns and how failures surface at runtime, 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.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose and the host prerequisite are front-loaded in the first sentence, and subsequent sentences are scoped to naming rules and the XMPP boundary. The validation sentence is dense but every clause constrains behavior an agent could otherwise get wrong.

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 four-parameter, no-annotation, no-output-schema mutation-ish tool, the definition covers prerequisites, defaulting, conflict handling, and validation constraints. The remaining gaps are the undocumented port parameter and no statement about what the agent gets back on success or failure.

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 0%, so the description must compensate for all four parameters. It does so thoroughly for nickname and player_name (alias relationship, default of "MCP Player" when omitted, conflict-fails-before-joining rule, 1-32 Unicode characters, must include non-whitespace, no control/surrogate/formatting characters), but host is only indirectly implied and port is never mentioned despite a 20595 default 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?

States a specific verb and resource ("Join an unpassworded 0.28.0 LAN room through Python ENet") with the protocol version and the security mode, which is enough to distinguish it from hosting-oriented siblings such as start_local_game. The added "Host must start the match" clause clarifies the join's dependency without ambiguity.

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 real prerequisite (the host must have started the match) and draws an explicit boundary: "XMPP lobby discovery/authentication is outside this direct LAN connector," which tells the agent when this tool is not the right path. It does not name an alternative tool for the XMPP/lobby case, keeping it short of a full when/when-not matrix.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.