This is a pretty big topic so I have a few questions that hopefully will clarify what your intentions are and make it easier for us to give you some advice.

You say you are doing it for personal interest and development, however are you more interested in the coding and software design aspect of creating a mud codebase, or in actually creating a game?

Following on from that, are you wanting to create a generic codebase that could be used as a framework for any style of mud or do you want to create something with features specific to the type of game you envisage?

How far have along are you with this project already? What programming language or framework are you using?

At the highest level I would say a mud codebase needs a minimum of 3 components – connections, communications and persistence.

Ok Javascript is an interesting choice, but I guess it's as good a choice as any.

Well back to my 3 components that define a mud. This is going to be very basic so please don't be offended if I'm stating the obvious :)

1. Connections.

A mud is a multiuser game so your server will need to accept and manage connections from clients. Traditionally muds use the telnet protocol (well kind of!) but if you wanted to do something a bit different you could always define your own. This would probably mean your server was incompatible with existing clients, but you could write your own client instead. Infact if you were to write the server in actionscript it would lend itself rather nicely to a bespoke flash client.

You can probably find several socket libraries for javascript/actionscript so experiment and see what works best for you.

2. Communication.

It's no good having users connect if they can't communicate with each other or with the game world. Communication can be divided into input and output handling. You will need a system to process user input that reads from the socket and then parses the input according to your game logic. For output you need to be able to write text (or send other information) to each connected client.

3. Persistence.

A mud is more than a chatroom, it's a virtual world that persists when users disconnect. Whatever design decisions you make regarding rooms, objects, npcs etc. you will need a way to store this information on the server. You could design your own storage format, or make use of an existing flatfile schema or relational database. Some options would be SQL, XML or even some kind of ORM.

The above is all pretty obvious, but I think it's worth keeping the bare basics in mind when you start a project like this.

As for some practical advice, I would recommend that you start simple with a server that can accept connections and echo input. Once you have that working you can add in more advanced communications and then look at trying to persist your data. Start small but have a clear path in mind, and also try to adopt good habits with regards to programming style right from the beginning.

I would still recommend you try to get multi user support going before you get too far along with other systems, as this is really the core of a mud. However to answer your question, there are several ways that you could parse commands and you might want to download some existing codebases to see how they do it.

A simple approach is to take the first word of input and compare it to your list of commands for a full or partial match, then call the function that handles the command and pass any remaining input as an argument.

I would also echo what Kleothera says – working on an established mud with other experienced people may be a better way to learn the basics.