Hi Mad Frog,
The easiest way to see the format of raw Apple Events in AppleScript is to first use Script Editor to create a script containing complex commands (including parameters) from one or more scripting additions such as the Standard Additions OSAX. Then, save the script, quit Script Editor, and temporarily remove all the OSAXen from your System Folder's "Scripting Additions" folder. When you relaunch Script Editor and open the saved script again, you'll see the raw class codes for all the events and their parameters (however, note that AppleScript's built-in syntactic tokens will still be displayed normally, e.g., words like "given", or the '{' and '}' list delimiters, etc.).
If you want to be able to actually run the script for testing, but still wish to see the raw codes, you could create "raw" OSAXen that lack terminology resources but are otherwise intact. I.e., first make *copies* of all your OSAXen, and strip out their 'aete' resources (via ResEdit or any other resource editor). Then, back up your existing OSAXen to a safe place, and install the new "raw" copies.
The above approaches would also work for seeing/testing raw commands from applications instead of OSAXen. The only difference is that it's not so easy to temporarily uninstall or override an application. However, after creating the "raw" copy of an application (by stripping out that copy's 'aete' resource), you could either delete the original application from your hard disk (after backing it up of course!), or temporarily change it into a "non-application" (by compressing it, or changing its type-code to 'TEXT', etc.). With any luck, you won't need to rebuild the Desktop DB to get AppleScript to recognise the new raw copy; and, if it displays the "Where is application...?" prompt, just choose the raw copy.
I'm a little unclear about your overall task, but if you're using Mac OS 9.x, there might be a way to get the two script applets to talk with each other using normal terminology instead of raw AE codes. The Mac OS 9 version of AppleScript has a 'using terms from' clause which allows you to target a remote or unknown application while using the (hopefully compatible) command-syntax from a local application. (It's equivalent to the "double tell" technique that some people used before.) I guess you'll also need to turn on 'Program Linking' in the File Sharing CP of the remote machine, and set up the appropriate privileges for both the sending & the receiving applets, etc.?
Regards,
--Paul