fix: return success response from void operations (AI-164)

[Rodriguespn]

Problem

Some tool operations (e.g., pauseProject, restoreProject, deleteBranch, etc.) currently return Promise<void>, providing no feedback to LLMs about whether operations succeeded. This causes LLM clients to think operations failed when they actually succeeded, leading to unnecessary retries and additional errors.

Solution

• Created a SuccessResponse type: { success: true }
• Updated all void operations to return SuccessResponse instead of Promise<void>
• Added a SUCCESS_RESPONSE constant with documentation explaining error handling behavior

Affected Operations

Account Operations:

• pauseProject
• restoreProject

Branching Operations:

• deleteBranch
• mergeBranch
• resetBranch
• rebaseBranch

Database Operations:

• applyMigration

Storage Operations:

• updateStorageConfig

Notes

• If an operation fails, assertSuccess() throws an error, so the success response only indicates successful completion
• This provides explicit confirmation to LLMs that operations completed successfully
• Follows the same pattern already used by some tools (e.g., storage config updates)

Fixes https://linear.app/supabase/issue/AI-164

[mattrossman]

On second thought maybe it'd be easier to keep the Promise<void> type in the platform abstraction, but return that SUCCESS_RESPONSE inside the execute body of the affected tools (e.g. here)?

pause_project: tool({
      ...
      execute: async ({ project_id }) => {
        ...
        
-       return await account.pauseProject(project_id);
+       await account.pauseProject(project_id);
+.      return SUCCESS_RESPONSE;
      },

That way we don't have to make additional PRs to update the hosted and self-hosted remote MCP implementations. I don't imagine the success value needs to vary per-platform.

[Rodriguespn]

@mattrossman I've implemented your suggested changes!

The platform abstraction now keeps Promise<void> return types, and the SUCCESS_RESPONSE is returned in the tool layer's execute functions instead. This applies to all the affected operations:

• pauseProject, restoreProject
• deleteBranch, mergeBranch, resetBranch, rebaseBranch
• applyMigration
• updateStorageConfig

This approach avoids needing additional PRs for the hosted and self-hosted remote MCP implementations. Ready for another review when you have a chance!

[mattrossman]

Sweet, sanity checked this with pause_project and it correctly understood the operation success. LGTM 👍

[mattrossman]

Not necessary for this PR, but in the future maybe we can explore richer responses for the unpause tool to clarify that projects don't unpause immediately (when the tool succeeds, agents tend to say that the project is unpaused and ready to go when often it's pending for several minutes).

[Rodriguespn]

Not necessary for this PR, but in the future maybe we can explore richer responses for the unpause tool to clarify that projects don't unpause immediately (when the tool succeeds, agents tend to say that the project is unpaused and ready to go when often it's pending for several minutes).

Agree. I've created a Linear issue to track that AI-185