Code Snippets MCP: write, lint and switch on snippets safely

Reading an inherited snippet library before trusting it

Agencies often take over sites where years of fixes live in Code Snippets rather than in a child theme. The first job is an inventory, and it is entirely read-only. code-snippets-list-snippets returns id, name, type, scope, tags, priority and active flag without the code, up to five hundred rows a page, and its search matches inside the code body as well as names and descriptions. That makes targeted questions cheap: which active snippets call wp_schedule_event, which ones mention a payment gateway, which ones load a script from an outside domain.

Names are not unique in Code Snippets, so two snippets called Tracking can both exist and both be active. Work by id from the first listing onwards. For each snippet that matters, code-snippets-get-snippet returns the full body with its type, scope, priority and any condition id, and an agent can summarise what it hooks into and flag anything that duplicates a plugin the site already runs. On multisite, network-shared snippets are kept in a separate table these abilities do not read, so an audit of a network site is incomplete until those are checked in the network admin.

Editing a snippet that is already running

Changing an active snippet is the moment a site is most likely to break, which is why editing its code, type, scope or condition needs confirmation. Lint the new body first by passing it as code to code-snippets-validate-snippet, which parses it without saving or running it. Then read the current snippet and keep its body, because the change log records snippet writes but cannot restore them; that saved body is the only undo.

When the edit is saved, Code Snippets re-validates the PHP itself, and if the new code errors it switches the snippet off. The response then carries deactivated_on_save and code_error. Treat that as a signal, not a failure to retry: the old behaviour has stopped along with the new code, so either fix the body and re-enable it, or write the previous body back. Change type and scope together when changing either, since most mismatched pairs are invalid.

Retiring a snippet that left things behind

Deleting a snippet removes its row and stops its code, and that is all. Anything the code created while it ran survives: scheduled WP-Cron events keep firing with nothing listening, tables made with dbDelta stay, and options it wrote stay in wp_options. For a snippet that set any of that up, disable it first, then clean up, then delete.

GoBuildWP Free's cron-list helps with the cron part. It lists every scheduled event with its next run and says whether anything is hooked to it, and an event with no callbacks after the snippet is disabled is usually the snippet's leftover. cron-delete unschedules one occurrence and can be undone from the change log. Leftover options and tables need a person to decide, because the agent cannot always tell whether another plugin also reads them.

• Search the snippet body for wp_schedule_event, add_option, update_option and dbDelta before deleting it.
• Keep the deleted body somewhere; there is no trash.
• On Pro, a condition snippet with currentDate between two dates is a cleaner way to run seasonal code than remembering to disable it.