The API is Event Driven. Every script gets executed precisely one time, during which it must register for events with functions that will be called when they occur. This works great for doing things when users do things. API commands in chat (!summon FooBar-Bazqux) cause a chat:message event, which is processed by whatever function scripts have registered. Where this breaks down is when it isn't a User doing something. API scripts don't cause most events to be spawned. (This was likely to prevent infinite loops.) That means that when the Summon script gets its command and creates new graphic objects, there aren't the add:graphic events spawning to tell other scripts the new graphics exist, as there would be if you drag things into the table as a User. There are several ways around this: Polling -- you could write an API script that just looks to see if there are more graphic tokens than it was previously aware of, and takes actions based on that fact. This is almost always the wrong solution, but might be the only solution available in some situations. Direct Coupling -- you could write your API script to call out to the functions of other API scripts and directly cause them to do things. This is only the right choice in very tight knit collections of scripts that you expect to be installed together. Generally, this would only go one direction, as you'd have one script relying on the existence of some base script. Often a script that provides some specific behavior and relies on a script that provides a generic library of functionality. The down side of this is the tight coupling between scripts, and the direction of dependence. In the specific -> general dependency of a client depending on a library, this isn't a big deal. When you start talking about two specific scripts, then it starts to be a problem because they need to know about something that is out of the scope of their intent. The Observer Pattern -- this is what I use in my scripts. It's basically the same as the event model in miniature. TokenMod is a good example of something that is Observable, and Bump is a good example of an Observer. An Observable script provides a function which other scripts can call which takes a function to be called when some event occurs. In the case of TokenMod, the function is called ObserveTokenChange() and is passed a function to be called when TokenMod changes a token. (You can find the functionality on line 722-731, the data structure on line 615, the notify event on line 2271, and the exported interface on line 2479.) On the other side of the equation, Bump observes GroupInitiative so that it can take tokens that are invisible and exchange them for their GM Layer equivalents. (This happens on line 578-580, note the check for if the other script is actually installed.) The above is basically a survey of what techniques are available. The nitty-gritty details are a bit harder to deal with. Here's basically what you've got above: Summon creates [Tokens] TokenNameNumber numbers [Tokens] TokenMod manipulates [Tokens] Bump manipulates [Tokens] 5e Companion manipulates [Tokens] To get that to work, you'll need the bottom 4 to react to the event that the first one creates. That's going to require modifying pretty much all of them, even with !delay. They expect to operate on selected tokens (TokenMod, Bump), or on token creation events (TokenNameNumber, 5e Companion). None of them are really set up to be activated by other scripts.