(Edit: I realize now that I'm just repeating more verbosely what The Pixie already said, but I'll leave it anyway, in case it's helpful.)
As a possible alternative, depending on your design, you might be better off without a script dictionary at all. I'm not sure about the semantics of these script in relation to the object being passed, but if you're calling behaviors on an object, then you might be better off putting the scripts either onto the object directly (if for a single object) or into a type you inherit from (if shared across multiple objects).
The underlying idea is that a Quest object is effectively a dictionary anyway. And if you use "do" instead of "invoke", then you get a built-in "this" pointer. So moving the scripts onto the object (or an inherited type) means you can simply do:
do (npc, itemX)
to run your script. And you'd have (roughly - fix the syntax as needed, as I'm at work and going from memory):
<object name="npc">
<item1 type="script">
// stuff goes here
</item1>
<item2 type="script">
// stuff goes here
</item2>
</object>
Or you could encode it a bit and have
do (npc, "handle_" + itemX)
<object name="npc">
<handle_item1 type="script">
// stuff goes here
</handle_item1>
<handle_item2 type="script">
// stuff goes here
</handle_item2>
</object>
That might not work with your design, but I'm throwing it out there, just in case. (And if you did go the "do" route, it also has a variant that takes an arguments dictionary, in case you needed additional parameters beyond "this".)
In the entire time I've been using Quest, in all the various bits of coding I've done, I've never used a script dictionary. Using an object to hold the scripts has always been easier and more meaningful from a design point of view. Your mileage may vary.