Build with AI on SashiDo

An AI assistant writes better backend code when it can see the backend: the real schema, the real errors, the code that actually runs. The MCP server gives it that. This page is about using it well.

Give it context once

Assistants read a project instructions file at the start of every session: CLAUDE.md for Claude Code, AGENTS.md for many others, .cursor/rules for Cursor. Put your backend there, so you don't explain it in every chat:

## Backend
- SashiDo app "my-app" (objectId AbC123xYz), Parse Server 6, region EU.
- Use the sashido MCP tools for the schema, data, logs and deploys.
  Read the schema before writing queries; don't guess field names.
- Clients use the Parse JS SDK with the app ID and JavaScript key only.
  Never put the master key in client code, a repository or a prompt.
- Anything privileged (payments, roles, other users' data) goes in cloud
  code, in the app's GitHub repo under cloud/. Push to deploy, then wait
  for the deployment and check the app's health and errors.
- Every new class gets class-level permissions; objects that belong to
  a user get an ACL.
- Types: src/types/parse.ts, regenerated with generate_types after a
  schema change.

The assistant can also read these docs: every page is available as Markdown (add .md to the URL), and llms.txt lists them.

Workflows that work

Build a feature end to end

"Add comments to posts: a Comment class with the text, the author and the post, readable by everyone, writable only by its author. Then the React component."

A good assistant will read the schema, create the class and its fields, set the class-level permissions, write a beforeSave in your cloud code that sets the ACL, regenerate the types and write the component against them. Ask it to show the schema and permissions before it creates them.

Debug from the real errors

"Signup fails for some users since this morning. Find out why."

It reads the error logs, finds the cloud code that throws, reads that file, and proposes a fix. Once you push it, ask it to wait for the deployment and check the errors again. Real logs beat guessing from a stack trace pasted out of context.

Review security

"Check my-app for security problems and fix the first three with me."

get_app_advice checks class-level permissions (public writes, user listing, fields added by clients) and, on Parse Server 6.5.11 and newer, client push, class creation, social logins, users and sessions, and the database. It says what to do for each problem. Ask the assistant to explain each fix before it applies it: a permission change can break a client that relied on it.

Upgrade Parse Server safely

"Plan the move of my-app to the newest Parse Server."

plan_parse_server_upgrade reads your cloud code and lists what breaks on the new version, by file and line, with the fix and the source in Parse Server's migration guides. It then gives the steps: fix the code, try it on a test app with the new version, switch, wait for the deployment, check health and errors, and the way back.

Type your clients

"Generate Swift types for my classes."

generate_types turns the live schema into TypeScript, Swift, Kotlin or Dart classes. Typed fields catch the misspelled createdBy before your users do.

Ask what happened

"Who changed the environment variables of my-app this week, and from where?"

The Activity records every change with the person or token behind it and the client: the dashboard, the API, or an assistant through MCP, with the tool it used.

Frontends built with AI

Lovable, v0, Bolt and similar tools generate the frontend; SashiDo is the backend behind it. Or start from a starter app (React, React Native, Flutter) and let your assistant build on it. Give the tool:

• the Parse JS SDK setup from Get started, with your app ID, JavaScript key and API URL;
• your types from generate_types, so it uses your real classes and fields;
• the rule that anything privileged goes in cloud code.

The client keys are public by design. What protects your data is class-level permissions and ACLs, so run get_app_advice before you share the app.

Keep it safe

• One token per assistant and machine, named after it, so the Activity tells them apart and revoking one breaks nothing else.
• Start read-only. Most questions need no changes. Use a second, broader connection when you mean to change things, and limit it to the apps involved.
• Read what it's about to change. Clients ask before calling tools that change or delete: approve them one by one, especially schema, permission and version changes.
• Treat data as untrusted. Text stored in your app can contain instructions aimed at assistants. An assistant reading user-generated content should have a read-only token.
• Never paste keys into a chat. The assistant doesn't need the master key: the token and the MCP server do the work without it.