Generic Mud Communication Protocol  
MUDhalla is a website dedicated to multiplayer text adventure games, also known as MUDs.
MUD servers often want to send additional data to a MUD client that doesn't necessarily need to be displayed, as well as needing a way to identify clients that support out-of-band data.
The history of GMCP starts with the Achaea Telnet Client Protocol (ATCP) using TELNET code 200 which was implemented by cMUD in 2008. ATCP however only allowed for sending plain text. MSDP (Mud Server Data Protocol) was developed in 2009 and provides a standardized way to define typeless variables, arrays, tables, and commands. In 2010 IRE launched in an attempt to update the ATCP protocol.
This resulted in the conceptualization of ATCP2 using TELNET code 201, which was later renamed to GMCP. GMCP uses the JSON syntax to define typed data.
As became defunct in 2011 this document provides a technical description of the GMCP protocol and MSDP over GMCP. MSDP over GMCP offers standardized event handling besides sending structured data. Servers that implement MSDP over GMCP will be able to use both the MSDP and JSON standard for defining structured data as well as perform MSDP event handling in either format.

The GMCP Protocol

GMCP is implemented as a Telnet option RFC854, RFC855. The server and client negotiate the use of GMCP as they would any other telnet option. Once agreement has been reached on the use of the option, option sub-negotiation is used to exchange information between the server and client.

Server Commands

IAC WILL GMCP    Indicates the server wants to enable GMCP.
IAC WONT GMCP    Indicates the server wants to disable GMCP.

Client Commands

IAC DO   GMCP    Indicates the client accepts GMCP sub-negotiations.
IAC DONT GMCP    Indicates the client refuses GMCP sub-negotiations.


When a client connects to a GMCP enabled server the server should send IAC WILL GMCP. The client should respond with either IAC DO GMCP or IAC DONT GMCP. Once the server receives IAC DO GMCP both the client and the server can send GMCP sub-negotiations.
The client should never initiate a negotiation, if this happens however the server should abide by the state change. To avoid trigger loops the server should not respond to negotiations from the client, unless it correctly implements the Q method in RFC 1143.

Disabling GMCP

When a typical MUD server performs a copyover it loses all previously exchanged GMCP data. If this is the case, before the actual copyover, the MUD server should send IAC WONT GMCP, the client in turn should fully disable GMCP. After the copyover has finished the server and client behave as if the client has just connected, so the server should send IAC WILL GMCP.
When a typical MUD client loses its link and reconnects it loses all previously exchanged GMCP data. The server should reset its GMCP state and re-negotiate GMCP whenever a client reconnects.

GMCP definitions

GMCP             201

Example MSDP over GMCP handshake

server - IAC WILL GMCP
client - IAC DO GMCP
The single quote characters mean that the encased text is a string, the single quotes themselves should not be send.

Data Format

Each GMCP data exchange should use the IAC SB GMCP '<package.subpackage.command>' <data> IAC SE format.
The package name can be case insensitive. When using MSDP over GMCP the package name is considered case sensitive and MSDP must be fully capitalized. There are no subpackages as these are not necessary.
The <data> field is optional and should be separated from the package field with a space. When sending a command without a data section the space should be omitted. The data field must use the JSON data syntax with keywords being case sensitive using UTF-8 encoding.
When using MSDP over GMCP the <data> field must always be set. If a MUD server exclusively uses MSDP over GMCP it does not need to worry about handling the CORE.HELLO or CORE.SUPPORTS packages because whenever the client sends an MSDP command the package is considered enabled.


Each MUD server is expected to define and document its own packages. The document you are currently reading is primarily focused on describing the MSDP over GMCP functionality built into TinTin++ 2.02.0 and MTH 1.5.
Writing and documenting GMCP packages can be quite the hassle. MSDP is self-documenting and relatively hassle free because it comes with a flexible event handler written in C.
MSDP over GMCP combines the popularity of JSON with the versatile command system of MSDP. It also allows the client to choose between using either MSDP, GMCP, or both. While JSON is easier for humans to read MSDP is easier for machines to read, which makes MSDP preferable for creating dynamically generated tables. In the case a client enables both MSDP and GMCP the client is expected to be able to process both MSDP and GMCP data interchangably, similarly the server is expected to process both MSDP and GMCP data interchangably, as is the case in MTH 1.5.
Keep in mind that JSON does not allow sending control-codes while MSDP does. Another advantage of MSDP over GMCP is that GMCP is not a proper protocol, it basically tells you to use JSON and if you do some googling you'll find some inconsistent package definitions. MSDP is a true protocol and tries to make it very clear which data to send, how to send it, and when to send it.
The MSDP Protocol Definition.


MSDP Discussion Reddit board
MSDP Discussion Discord channel


If you have any comments you can email me at

Clients supporting both MSDP and GMCP

Mudlet (doesn't allow control codes over MSDP)

BasedMUD - Full MSDP support using MTH 1.5. Based on DikuMUD / ROM / QuickMUD / BaseMUD.
Lowlands - Full MSDP over GMCP support. Based on DikuMUD / MrMud.
NekkidMUD - Full MSDP over GMCP support. Based on SocketMUD / NakedMud.
WickedMUD - Full MSDP over GMCP support. Based on SocketMUD.


MSDP Discussion Reddit board
MSDP Discussion Discord channel



Scandum's MUD Telopt Handler - Handles CHARSET, EOR, MCCP2, MCCP3, MSDP, MSDP over GMCP, MSSP, MTTS, NAWS, NEW-ENVIRON, TTYPE, and xterm 256 colors.