The technique that zellyn describes above for having the Monitor process a command from the input buffer was, as he said, devised for Applesoft. In fact, one of its crucial elements is specific to that language: the "D9C6G" references the Applesoft ROM code. As it happens, the file that was often distributed to provide Integer BASIC for the Language Card had, of course, Integer BASIC itself, plus the mini-assembler and Sweet-16 interpreter, at $E000 to $F7FF, with "Programmer's Aid #1" added at $D000 to $D7FF, and $D800 to $DFFF left with simply a copy of the Applesoft ROM code of the same address space. Thus, the routine at $D9C6 was present, and the above-listed technique would work. However, this would not be reliable -- the $D800-$DFFF space might not have a copy of that portion of Applesoft; and in particular, if the above is tried on an original-model Apple ][, with Integer BASIC itself in ROM and no trace of Applesoft, it definitely won't work. There is an address intrinsic to Integer BASIC that does the same job: E817. Use that in place of D9C6 for something that will reliably work.
A second, minor point is that the "N" just before the D9C6/E817 is used to safely terminate the memory-assignment command. That's usually fine, as it just sets text to "Normal" display mode. However, if one happened to have been using Inverse mode, this would cancel it. A completely generalized method would be to replace the "N" with a "<" directly prefixing the E817G: "<E817G".
More significantly, however, a faster technique for storing the string in the input buffer, compared to a BASIC poke-loop, would be to "trick" Apple's DOS 3.3 into storing the string in the input buffer for you, by PRINTing it as a simulated DOS command. (The bold-italic D is an embedded "ctrl-D"):
In the above line, the PRINT begins with a "ctrl-D" to indicate a DOS command. This causes DOS to store all that is printed in the input buffer, instead of actually printing it. The POKE 513,141 then replaces the second character, which was a SPACE, with a <Return> in the buffer. Then PRINT actually generates a <Return>, to let DOS process the "command". Thanks to the above POKE, DOS sees only a "null" command, and does nothing more. Then the two POKEs and CALL set up the monitor and have it process the printed string as a command.
10 PRINT "D 300:AD 30 C0 60 <E817G";:POKE 513,141:PRINT:
POKE 49,0:POKE 52,2:CALL -123