I can try.  This is simple to code, but not exactly simple to look up or understand.  You have 2 choices, depending on what information you have to go with the pathfinding.  Mostly, I can only introduce terms-the code is long and depends on your setup too specifically.
But first, graphs and heuristics.
A graph in computer science is a data structure consisting of nodes and edges.  Nodes can be thought of as rooms, while the edges between them can be thought of as exits.  An undirected graph is a graph in which each edge goes both ways--that is, a set of rooms where if you go east you can always go west and end up where you started, etc.  A directed graph is a set of rooms and exits where going east and then west again may not always take you back to where you started.  If there is one or more such case, the graph is directed.  Real life examples of undirected graphs include water pipes and computer networks (not always, but...); real life examples of directed graphs include city streets wherein some streets are only one way.
A heuristic is a function that intelligently guesses about something.  On a 2D grid, we can say that a heuristic for how close two objects are is the Pythagorean theorem.  This heuristic is perfect if you are able to walk in a straight line to the object, less so if you can only use cardinal directions, and even less so if you need to go further away before getting closer.  It's still a pretty good guess, but it's not always "right".
You always have the graph in a mud.  You do not always have a heuristic  for how close things are.
If you have only the graph, the algorithm you should look up and code is called bredth-first search.  This will work tolerably well for rooms that are separated only by a few exits, and will always give you the best path in terms of commands.  It will not always give you the best path if your exits have something like endurance costs, but it will always yield a walkable path.  You then record the paths as you check them--typically by pushing and popping rooms off a stack.
If you have a good heuristic, however, astar is better.  The better the heuristic, the faster Astar is going to find the "right" answer.  Astar is not only for 2D games, though a quick google search sure makes it look like it is.  In astar, you check the "best" option first.  Astar can give you the best cost in terms of endurance as well as in terms of commands, depending on how you code a couple parts of it.  Explaining the specific motivation behind it is more complicated, but essentially it's like this: the heuristic is an estimate of how much it's going to cost (number of steps, for example) to reach the goal.  As you build up paths, you use the heuristic to guide which nodes to check next.  This is not a complicated algorithm, but putting it into words is very difficult.  The python code for it comes out to be around 50 lines.
You can easily find numerous Python examples for both of these with a google, some of them reusable.  Beware anything from AI A Modern Approach or AIMA or Google, because you might run in to the one that wasted 2 weeks of my life because it claimed to be fine but was actually astronomically slow for large sets of nodes.  If you're willing to cache and make sure paths don't try to go through temporary exits, both of these can provide you paths to anywhere from anywhere, but will take a very, very long time to run if no such path exists.  You will need additional limits to make sure it doesn't bring your mud to its knees--if the two rooms are in the same area, both of these algorithms may still try to leave the area.  If no path exists between two rooms in the same area, both of these algorithms will check the entire mud before saying so.
Suggested terms: graph search python, python graph searching libraries, etc.  The important bit is graph search.  Many of these are very reusable; they ask you to pass them functions that do certain things and then handle the rest.  Most can be installed with pip.