Userscripts external API rejects put/delete although editor integrations expose them
Tampermonkey 5.5.0 exposes the external userscripts API used by Tampermonkey Editors, but its capability response only includes:
{"allow":["options","list","get","patch"]}The implementation then explicitly returns 405 Method Not Allowed for put and delete.
Observed behavior:
- list succeeds
- patch of an existing script succeeds
- put of a valid userscript fails with {"number":405,"message":"Method Not Allowed"}
- delete is rejected in the same branch
This makes it impossible for MCP/editor integrations to create or delete scripts through the documented userscripts channel. The integrations currently advertise these actions, so users receive a misleading protocol-level capability.
Could the maintainers please clarify whether put/delete are intentionally unsupported? If they are intended to be supported, please add them to the native userscripts external API and the options allow list, with a documented request/response contract. If they are intentionally unsupported, the capability documentation should state that explicitly so integrations can avoid exposing these operations.
Related reports:
Userscripts external API rejects put/delete although editor integrations expose them
Tampermonkey 5.5.0 exposes the external userscripts API used by Tampermonkey Editors, but its capability response only includes:
{"allow":["options","list","get","patch"]}The implementation then explicitly returns 405 Method Not Allowed for put and delete.
Observed behavior:
This makes it impossible for MCP/editor integrations to create or delete scripts through the documented userscripts channel. The integrations currently advertise these actions, so users receive a misleading protocol-level capability.
Could the maintainers please clarify whether put/delete are intentionally unsupported? If they are intended to be supported, please add them to the native userscripts external API and the options allow list, with a documented request/response contract. If they are intentionally unsupported, the capability documentation should state that explicitly so integrations can avoid exposing these operations.
Related reports: