What the Knack MCP Server Can and Can't Do

The Knack MCP Server manages your app's structure, not its records. Here is exactly what it can change, what it cannot, and which of its actions cannot be undone.

What You'll Learn

The Knack MCP Server lets an AI tool like Claude, Lovable, or Base44 work directly with your Knack app. This article covers what the server can change, what it can't, which actions are permanent, and how to keep your app safe while an AI tool works on it.

What the Knack MCP Server Is For

The Knack MCP Server manages your app's backend: its tables, fields, connections, records, user roles, sign-in settings, and access rules. You describe what you want in plain language, and your AI tool uses the server to make the change in Knack.

It signs in as your Knack account and reaches the apps that account can open in the Builder, and no others.

It doesn't build Knack pages, elements, or themes. If you're building a custom frontend, your finished app reads and writes records through the Runtime Data API as whoever is signed in. The MCP Server is for building and managing the app, not for your users.

What It Can Do

AreaWhat your AI tool can do
AppsList, create, rename, and delete apps on your Knack account
TablesCreate, rename, and delete tables. Set a table's display field and default sort order.
FieldsCreate, update, and delete fields, including connection, formula, and equation fields. Mark fields as required or unique.
RecordsAdd, update, or delete one record at a time, and look up records with a read-only query
Sample recordsAdd realistic test records, up to 10 per table per request
User rolesCreate user role tables and choose which role new users get by default
Sign-upTurn sign-up on or off for a user role, or require admin approval for new users
Sign-inRegister the sign-in connection for a custom frontend, update its redirect addresses, and brand the hosted sign-in screen
Two-factor authenticationTurn 2FA on or off for the whole app or for one user
Single sign-onSet up Google, OAuth2, or SAML sign-in providers and choose which roles can use them
Data access controlTurn enforcement on or off and set what each role can view, edit, and delete in each table

What It Can't Do

  • Build Knack pages, elements, or themes
  • Change an existing field's type
  • Convert a table between a standard table and a user role table
  • Set up or change Knack Flows. You'll configure triggers and actions in Knack yourself.
  • Enter single sign-on credentials like client IDs, secrets, or certificates. You add those in the Knack Builder.
  • Change a single sign-on provider after its credentials are entered. Make further changes in the Builder.
  • Look up fields marked as sensitive (PHI or PII) with a record query
  • Return more than 1,000 records from a single query
  • Load custom fonts on the hosted sign-in screen. Only system fonts display.
  • Work with apps on other Knack accounts

Branded sign-in screens require a Pro plan or higher.

Actions You Can't Undo

A few MCP actions are permanent. Ask your AI tool to confirm with you before any of these.

  • Changing a field's type. The only way is to delete the field and create a new one, which deletes the data in it.
  • Choosing a table type. A table can't be switched between standard and user role later. Decide which tables hold signed-in users before you build.
  • Deleting all records in a table. The bulk delete removes every record in the table. There's no partial delete and no undo.
  • Deleting a single record. Record deletes are permanent.
  • Deleting a table or an app. Everything in it goes with it.
  • Turning off 2FA for a user. Their authenticator setup is cleared, so they'll need to set it up again if 2FA is turned back on.
⚠️

"Clear out the test records" deletes real ones too

If a table holds real data and test data, asking your AI tool to clear the test records can run the bulk delete and empty the whole table. Delete test records one at a time, or in the Knack Builder.

Who Owns Records the MCP Server Creates

Records created through the MCP Server are owned by the App Builder system user, not by a signed-in user. If your access rules depend on who owns a record, those records won't show up for the right users until you update their Owned By value.

See Who Owns a Record Created from a Custom Frontend for how to fix ownership after records are added.

Keeping Your App Safe

  • Keep tool permissions on "ask each time" for any app with real data. You'll see each change before it runs.
  • Verify every change in the Knack Builder. AI tools sometimes report a change as done when it didn't happen.
  • Double-check when your AI tool says it can't do something. It may have checked the wrong app or setting. Confirm against this article before accepting it.
  • Use sample records for testing, not your real data.
  • Never paste a private API key into a chat or into frontend code. It bypasses every access rule in your app.
📘

Building a HIPAA app?

Use test data while you build. Bring real data in through the Knack Builder's import rather than through your AI tool. See HIPAA Compliance Overview.

Common Mistakes

  • Trusting a success message. Open the Builder and confirm the table, field, record, or setting is actually there.
  • Assuming access rules are on. Setting permissions and turning on enforcement are separate steps. Check both.
  • Picking the wrong table type. If people will sign in, they need a user role table from the start.
  • Using record tools to import real data. Use the Builder's import, so you control ownership and avoid sending sensitive data through an AI tool.
📘

For developers

Record tools are manageKnackRecord (create, update, or delete one record by ID) and queryDatabase (read-only SQL SELECT, up to 1,000 rows per query, rejects fields classified as PHI or PII, returns 400 if the app isn't SQL-backed). deleteKnackRecords deletes every record in a table. createKnackApplicationSampleRecords adds up to 10 sample records per table per call. Sign-in and security tools are registerLiveAppOAuthClient (pass an existing client ID to replace its redirect URIs), setLiveAppLoginBranding, manageKnack2FA, and manageSsoProvider. Sign-up type and allowed SSO providers are set with updateKnackObject. Access rules use manageKnackAccessControl.

Next Steps


Did this page help you?