However, this also has a number of disadvantages:
1. /SendTo/ does not support subfolders. Thus, all shortcuts are located in it together with other shortcuts, not separated from them in any way. The list can be quite large, and without structuring it can make it difficult to find the right tool. Partially the problem is solved by naming all "PDF-Tools" by a mask, for example, "PDFX (...)".
2. In the general case, it is impossible to understand which of the tools each label refers to. That is, in particular, it is impossible to go from the shortcut to the settings of the tool corresponding to it.
3. If the tool corresponding to the shortcut is removed, this is not reflected in the shortcut view.
4. If the tool corresponding to the shortcut is changed (for example, when working with documents through the "PDF-Tools" interface), the shortcut will perform a different function. It's a feature, but it's also a bug when it's not planned.
5. In the "PDF-Tools" interface, tools with shortcuts look no different from tools without shortcuts. And you can’t hide all the tools with shortcuts with some kind of filter so as not to accidentally change them.
I understand that some of these problems are an integral part of the solution that was chosen for the quick use of presets. However, I think you can discuss with the development team and users the possibility of customizing your own File Explorer context menu for tools. The menu might look something like this:
_
but the setting to turn tools on and off in the menu is similar to Microsoft PowerToys (github.com/microsoft/PowerToys).
A partial solution could be to nest all the settings in the shortcut so that the shortcut becomes independent, not tied to a preset in the application interface. And that shortcuts can be edited in the "PDF-Tools" interface. The limit of 8191 characters per command is large enough to pass both all tool parameters and a list of files with their full paths in most cases.
