--- name: retool-app-build-review description: Audit an existing Retool app's build history and current state before anyone changes it, inspecting the app, reviewing agent and build activity, and reporting what is live versus failed or incomplete. Use when the user asks what state an app is in, why an app build failed or stalled, what an agent changed, or whether an app is safe to touch. Read-only; separate from creating or importing apps. --- # Audit a Retool app's build and current state This job answers: **what does this app look like right now, how did it get there, and is anything half-finished or broken?** It is an audit, not a build. Do not create, import, continue or cancel a build as part of it. Those are different jobs with different risk, and the person asking usually wants to understand before deciding. ## 1. Pin down which app and which organization Before reading anything, confirm the organization the connector is authenticated against and the exact app. App names repeat across folders and environments. Ask for the app id or the URL if the name is ambiguous. If the connection is to a different organization than the user expects, stop and say so; do not guess. Fetch the app with `retool_get_app`. Record: - its id, name and folder, - when it was last changed and by whom, if the response says so, - whether it is the live version or a draft, if the response distinguishes them. Then check the folder with `retool_get_folder` if the app's location matters to the question (a stale app sitting in an archive folder is a different finding from one in the live folder). ## 2. Establish current state before history Describe what exists now. This is the baseline the history is compared against. Note whether the app loads, which resources it references (from the app detail only, not by querying data), and whether anything is marked as unfinished. Do not infer health from the app existing. ## 3. Review build and agent activity Use the activity tools to reconstruct how the app got here. Work newest-first, then look backwards only as far as needed to explain the current state. - Check for any build that is still running or stuck. A build that has not progressed for a long time is a finding in itself. - Check for a failed build. Read the failure reason as given. Do not paraphrase it into a cause you have not verified. - Check for agent-made changes. For each one, note what it touched and whether the result is what is live now. - Compare the last successful state with the last attempted state. A failure after a success means something regressed or was half-applied. Say which of the two is live. If the activity tools return nothing for this app, say that. An empty history is not evidence of a clean build. ## 4. Separate live from failed This is the central distinction. Keep three buckets and never merge them: - **Live and working:** the version users reach, confirmed by the app detail. - **Failed or partial:** an attempt that did not complete. It may have left traces, but it is not what users get. Say explicitly whether any partial output reached the live version. - **Unknown:** anything you could not confirm. Put it here rather than guessing. ## 5. Check the things that are easy to miss - **A build that succeeded but the app is still a draft.** The work exists but nobody can use it. Report it as draft, not as broken. - **Agent edits made outside the reviewed scope.** If the user asked about one part, note changes elsewhere. - **Stale references.** A reference to a resource or workflow that the app detail shows but you cannot confirm still exists is an open question, not a broken app. - **Recent activity by an unexpected account.** Report it neutrally; do not treat it as a security finding without evidence. ## 6. Recommend, but do not act End with what the user could do next, phrased as options. If the right next step is a change (re-run a build, cancel a stuck one, roll back, edit the app), name it and wait for the user's explicit yes before any such tool is used. This audit itself makes no changes. ## Common patterns and traps - **Mistaking "exists" for "works".** An app can be present, last edited recently and still broken. Check the state and the activity, not the existence. - **Trusting the last-modified time alone.** A recent edit may be a failed attempt. Pair the timestamp with the build outcome. - **Reporting a failure without its scope.** "The build failed" is less useful than "the build failed after the data view was updated, so the data view is in an unknown state". Say what the failure covered. - **Over-reading an empty history.** Pagination, permission limits or a wrong app id all produce empty results. Confirm the id before concluding there was no activity. - **Turning an audit into a fix.** The user asked what is wrong, not for it to be repaired. Keep the two separate in the report. - **Confusing the MCP server with the MCP resource.** This audit covers Retool's own app build records through the server. It is not about third-party MCP resources wired into the app. ## Output ``` App: (), folder , organization Current state: , Live and working - Failed or partial - : , live impact: Unknown - : Agent and build activity (newest first) - : → Recommended next steps (none taken yet) 1.