MCXboxBroadcast and making a Geyser server visible to Xbox friends

A Geyser extension that emulates a console client

MCXboxBroadcast is described as a simple tool that broadcasts an existing Geyser or Bedrock server over Xbox Live. The effect is that it shows up to the authenticated account's friends in game as a joinable session.

The mechanism is the part to be clear about, and the project says so plainly. The disclaimer states that you use the project at your own risk, that the contributors are not responsible for any damage or loss caused by the software, and that the project suggests you use an alt account for running the tool in case the account is banned, as the authors emulate some features of a client which may or may not be against the terms of service.

That sentence is the honest centre of this project. It is not a protocol client for Xbox Live in the sanctioned sense. It emulates enough of a client to make a session appear to friends and to be joinable. Anyone evaluating it has to weigh the convenience against the possibility of the account behind it losing access, and the project itself recommends isolating that risk in a separate account.

The language is Java, the licence is GPL-3.0, and the project is not archived with the last push on 2026-10-03. The recent releases are numbered builds, 157 on 2026-09-25, 158 on 2026-10-02 and 159 on 2026-10-03, which is a very high release cadence and suggests an actively worked on tool rather than a stable library.

The feature list is about presence, not about hosting

The features tell you what the tool actually does, and the list is short enough to be complete.

Syncing of MOTD and other server details means the session that appears on console carries the same message of the day and server metadata as the Bedrock server behind it. Automatic friend list management means the tool handles the friend relationships it needs without you maintaining them by hand. It shows as online and playing Minecraft in the Xbox app and website, which is the presence layer that makes the session discoverable outside the game as well.

There is multi-account support, which is a different feature from the account list management: it lets one running instance present more than one account's session. And there is a web manager for larger networks.

The last feature in the list is more interesting than it sounds. You can upload a custom image for the account, which appears on the account's profile page. The image is a file named screenshot.jpg placed in the same directory as the config.yml, and the documentation gives recommended settings of 1200x675, quality 90 and chroma subsampling 4:2:0. The documentation also warns that this can take a few minutes to update on the Xbox Live servers and show in game, which is a useful expectation to set for anyone who changes it and expects an instant result.

Notice what is not here. There is no player management, no whitelist, no per-world configuration, and no sign that the tool controls gameplay. It is a presence and discovery tool in front of a server that Geyser already handles.

Two ways to run it, as an extension or standalone

There are two distributions, and the difference decides which one you want.

The extension version is a Geyser extension. The installation steps are deliberately simple: download the latest release file MCXboxBroadcastExtension.jar, drop the extension into the Geyser extensions folder, restart the server, and wait for the extension to start and present you with an authentication code. You then follow the link and enter the code, log in to the account you want to use, and add the account as a friend on Xbox Live. After that the server should be listed in the friends tab in game.

The standalone version is a separate jar, MCXboxBroadcastStandalone.jar, which you start yourself and which talks to a target server. The authentication flow is the same, but the standalone version adds two steps at the end: you edit the config.yml to have the correct ip and port for the target server, and you restart the tool.

The authentication step is the same in both cases and is worth describing precisely, because it is the part that touches a Microsoft account. The tool prints a message telling you to use a web browser to open the page https://www.microsoft.com/link and enter the code XXXXXXXX to authenticate, and you then log in to the account you want to use.

The mechanism is a device code sign-in, so the credential handling happens on Microsoft's own page rather than inside the tool. That is a meaningful design choice for a tool that asks you to attach a real account, and it is why the alt account advice in the disclaimer is about the emulated client behaviour rather than about password handling.

Whichever route you take, the last verification step is the same, and it is the one to run before you invite anyone: check the friends tab in game and confirm the server is listed.

The Docker image runs the standalone build with a config volume

For the standalone version there is a container image, published at ghcr.io/mcxboxbroadcast/standalone:latest, and the documented run command is a single line:

docker run --rm -it -v /path/to/config:/opt/app/config ghcr.io/mcxboxbroadcast/standalone:latest

The volume mount is the whole configuration story. The config directory is where config.yml lives, and mounting it means your settings survive container restarts and upgrades of the image, and it is also where the screenshot.jpg for the custom account image has to be placed, since that file is looked for in the same directory as the config.yml.

The container image is worth a second look for a network operator, because the extension and standalone split maps onto two deployment shapes. With the extension, the presence service runs inside the Geyser process, so there is one thing to run and one thing to keep alive. With the standalone build in a container, the presence service is separated from the game server and can be restarted or moved without touching the server, at the cost of one more component to monitor and the config directory to manage.

For larger setups there is a third piece. There is an egg supplied for Pterodactyl Panel, this being egg-m-c-xbox-broadcast.json, which gives easy instance creation on that panel. The same repository also contains the egg file, so it is part of the project rather than a separate download.

The web manager is a sponsor tier and needs MongoDB

The web manager is not part of the open source build in the way the extension and the standalone jar are. The documentation says a web manager is available for donators, and that after joining the relevant GitHub sponsors tier you will be able to access its builds in the Manager repository releases.

There is a further condition, stated in a note of its own: it also requires a MongoDB instance to be running.

Those two facts together define what the manager is for. It is a control plane for the presence bots, with views for bots, bot info, bot options, server options and manager settings, and it needs a database because it is managing multiple accounts and servers rather than one instance with one config file. Running MongoDB is a real operational commitment, and the sponsorship tier is a licence-like condition on the build, not just a donation request.

For a single server with one account, the standalone jar or the Geyser extension is the whole product and the manager is unnecessary. For a network running many accounts across many servers, the manager is what makes that operable, and at that point the MongoDB requirement and the tier are simply part of the cost of running the thing at that scale.

It is worth being explicit that the manager is a separate repository with its own releases, so its version and its compatibility with the broadcaster builds are not something the main repository documents.

In-game commands cover account and session administration

The command set is small, and for the extension version every command is prefixed with /mcxboxbroadcast.

The table is worth reading in full because it shows the operational surface. The exit command exists for the standalone version only and exits the program. The restart command restarts the tool. The dumpsession command dumps the current session data to files for debugging, which is the first thing to reach for when a session is not appearing as expected. The accounts list command lists the accounts currently in use along with their friend count, and the accounts add and accounts remove commands take a sub-session id to add or remove an account from the list of accounts to use.

That friend count in the list output is the diagnostic you want. The tool's job is to present a joinable session to the friends of the account it is authenticated as, so the number of friends on that account determines who can see the server. An account with three friends produces a session three people can discover, whatever else is configured.

The sub-session id in the add and remove commands is a detail that suggests the implementation models each authenticated account as a sub-session of a parent session, which is what makes the multi-account feature and the dumpsession debugging output possible.

The commands exist in game rather than only in a console, so an operator can manage accounts without leaving the game session they are hosting. That is a small design decision with a real convenience payoff for anyone running this on a server they also play on.

Where MCXboxBroadcast is the wrong tool

The first and largest wrong case is a server operator who needs a sanctioned way to reach console players. The project's own disclaimer says it emulates some features of a client which may or may not be against the terms of service, and the fact that the project suggests an alt account in case the account is banned is the strongest possible signal that the risk is real and not theoretical. A school, a company or a public server that cannot afford an account ban on its main identity should not run this.

The second wrong case is a server that is not a Geyser or Bedrock server. The tool is a broadcaster for an existing server, and the extension route requires a Geyser instance to drop the extension into. If you are trying to solve a discovery problem for a Java edition server with no Geyser layer, this is the wrong project.

The third is scale without preparation. The feature list advertises a web manager for larger networks, but that manager is behind a sponsorship tier and needs a MongoDB instance. A network that assumes the open build will scale to a hundred accounts is going to discover that the free path is one account, one config file and one process.

The alternative worth naming is a private or friends-only approach that does not need presence emulation at all. Xbox players on the same account, or players invited through the console's own friends list to a session started by a player who is actually on the platform, need none of this machinery. The difference in approach is fundamental: MCXboxBroadcast fabricates a session listing for an account that is not actually playing, whereas the sanctioned route requires a real console client in the session. If your audience is a handful of people you can add as friends on the account, the simple route works and carries none of the risk.

Release cadence, licence and the cost of running something unofficial

The project is GPL-3.0 licensed, with the licence file in the repository root, and the badge in the documentation points at it. There is a Discord community linked from the README, which is where the audience for a tool like this actually gathers.

The release history is unusual and worth understanding. The three most recent releases are 157, 158 and 159, all described as builds of master, dated 2026-09-25, 2026-10-02 and 2026-10-03, with the last push on 2026-10-03. There are no semantic version tags, so a deployment is pinned to a build number and the difference between a working build and the next one is a commit, not a changelog entry. For a project whose whole purpose is to track a platform's behaviour closely, that is a deliberate trade, and it has a cost: there is no stable release to pin to and no upgrade notes to read.

The repository layout is a Gradle build with a core module, a bootstrap directory, build-logic, a settings file and a build file, plus the Pterodactyl egg and the standard wrapper scripts. The build-logic directory suggests custom Gradle logic for producing the two different artifacts, the extension jar and the standalone jar, from one codebase.

The last thing to weigh is the operational reality of running an unofficial client continuously. The tool needs to be authenticated, its session has to be present for friends to see the server, and the friend list has to stay in a state where the account can see a session. Any of those failing means console players see nothing, and the failure is invisible from the Bedrock side, since the server is still up and serving players who joined by other routes. The dumpsession command exists for exactly this, and it is the first tool to reach for.

Editorial conclusion

MCXboxBroadcast fits a server operator who wants console players on their Geyser or Bedrock server and understands that it works by emulating a client, which the project says may or may not be against the terms of service. It is the wrong choice if you need a supported, sanctioned way to put a Bedrock server in front of console friends, and the wrong choice for anyone unwilling to use a separate account for it. Before you deploy it, read the disclaimer, put it on an alt account as the project suggests, and confirm whether the web manager tier and the MongoDB it needs are part of your plan.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. MCXboxBroadcast/Broadcaster on GitHub
4. README
5. Releases