Think about what will happen as more tools get added to the given directory. Will you need to change the code in your GUI, or not? If yes, then you might want to think harder about how you are designing it. OTOH, if just changing your "metadata" is all that is needed to adapt the GUI to any change in the tool set, you still need to consider how that metadata is created and modified. Can (any of) that work be done automatically? (If yes, then you're on the right track.)

Personally, I view GUI interfaces to command-line tools as being sort of like training wheels on a motorcycle. I don't doubt that some people who've never used a motorcycle before may find some comfort in using them, at least for the first little while. But as soon as one has a basic grasp of using the unmodified mechanism, the training wheels slow it down and limit its use to the point of being an unbearable hindrance. (And many people just jump right on the unmodified machine and start moving.)

Still, there is real value in a GUI tool that can provide a good, comprehensive summary of other tools of any type. So focus on providing easy, sensible displays of the tools -- e.g. a listing that shows: tool name; availability of a man page; command-line usage synopsis; maybe even type of tool (shell script, perl script, binary, ...). Clicking on a list item should bring up the man page with more detailed explanation of usage, along with purpose, resulting output, and error conditions.

You might choose to provide a dynamic set of buttons based on the usage synopsis in order to activate particular options, but I think it's just as well to allow the user to type in a set of command line args. (The sooner they take off the training wheels, the sooner they'll speed up.)

If some tools have especially intricate controls, it would certainly be handy to have a simple method for storing a particular command+option string, with a label, for future use. (Among CL/shell addicts, this is known as creating an "alias" or "shell function".)