Sasha MCP reference

checkApp

Validate a Sasha App you manage

Re-validate the whole package and report whether it is live, with file/line diagnostics when it is not. The result carries status: when status.ok is false the app is NOT usable until the listed diagnostics are fixed. Each names the package file, the line when known, the error code and a reason token. Fix the file and check again; the app is live as soon as it validates.

Arguments

Scopes

apps:invoke, apps:write

Annotations

• Read only: yes
• Destructive: no

When to use

Call checkApp after you fix the diagnostics that a change reported, or when you want to know if an app is live now. It changes nothing.

The tool needs the same access as listAppFiles: the scopes apps:invoke and apps:write, an admin or staff user, and manage access on the app.

The result has status:

• status.ok is true when the package validates. The app is live at status.revision.
• When status.ok is false, the app cannot be used until you fix each entry in status.diagnostics. Each entry has file (a package path), line when it is known, code and reason. status.revision can be null.
• A diagnostic with reason migration_already_applied_here:… means that a migration this instance already applied was changed. Put the old text back, and add a new migrations/NNN-*.sql file for the change.

The text part of the result is one sentence when the app validates, or one line per problem in the form <file>:<line> <code> <reason>.

Example

{ "app": "timesheet" }

The structured result (structuredContent) for a package with a mistake in APP.md:

{
  "app": "timesheet",
  "status": {
    "ok": false,
    "revision": null,
    "diagnostics": [
      { "file": "APP.md", "code": "APP_MANIFEST_INVALID", "reason": "unknown_field:colour" }
    ]
  }
}

The text part of the result:

App does NOT validate yet (1 problem):
- APP.md APP_MANIFEST_INVALID unknown_field:colour
Fix the named file, then call checkApp.

Read APP.md with readAppFile, remove or rename the field with editAppFile, then call checkApp again.

Refusals and what to do

The error result's text is the message. structuredContent.error holds code, message, retryable and diagnosticId.

• APP_ACCESS_DENIED (app_access_denied): this person does not have manage access on the app, or is not an admin or staff user. An app id that does not exist gets the same answer.
• APP_INPUT_INVALID (app_input_invalid): the arguments do not match the schema. Send only app, in lowercase kebab-case.
• If the connection does not hold both apps:invoke and apps:write, the tool is not in your tool list, and a call to it returns MCP error -32602: Tool checkApp not found. Read the permissions section of getDocs. The person must reconnect, or mint a new token, with apps:write. Only admin and staff can hold it.
• A status.ok of false is not a refusal. It is the answer.

Related

• listAppFiles returns the same status with the file list.
• readAppFile and editAppFile fix the file that a diagnostic names.
• writeAppFile adds a new migration.
• deleteAppFile removes a file that the app no longer needs.