What the Knack MCP Server Can and Can't Do

What you'll learn

The Knack MCP Server manages your app's structure: tables, fields, connections, user roles, and access control. It does not read or change individual records. Knowing where that line falls explains most of the surprises people hit when building a custom front end.

What it's for

The MCP Server is the connection your AI builder uses to work on your app while you build. It signs in as your Knack Builder account and reaches the apps that account can open in the Builder, and no others.

Think of it as the tool that shapes the container. Your finished app uses a different interface, the Runtime Data API, to move data in and out of that container while people use it.

What it can do

• Read your tables, fields, connections, and user roles
• Create tables and fields, and update existing ones
• Create connection fields between tables
• Configure Data Access Control, including turning enforcement on
• Set which user role new signups land in
• Create sample records for testing
• Register the OAuth client your front end signs users in through
• Brand the hosted sign-in screen

What it can't do

• Read, create, or update individual records
• Build Knack's own pages, elements, or themes
• Change the type of an existing field
• Change a table between a standard table and a user role table
• Reach apps on any Knack account other than the one you signed in with

It cannot read your records, and does not need to

This is the most common surprise. Your AI builder can see that you have a Patients table with a phone field, and it cannot see anyone's phone number.

That is deliberate. Records belong to the people using your app, and access to them is governed by the rules you set. A build-time connection signed in as your Builder account is the wrong thing to be reading customer data with.

It also does not need to. Your field names, types, and connections describe the shape of your data completely, which is what a builder needs in order to build. Your finished app reads the actual records later, as whoever is signed in.

Three choices you cannot undo

Most of what the MCP Server does can be adjusted later. These three cannot.

Field types are permanent. Changing a field from text to number means deleting it and creating a new one, which loses the data in it. Get the type right when the field is created.

Table types are permanent. A table is either a standard table or a user role table, and it cannot be converted. If people will sign in as that role, say so before it gets built. Rebuilding means deleting the table and everything in it.

Deleting records deletes all of them. The record deletion tool removes every record in a table. There is no option to delete some, and no undo.

Sample records are for testing, and capped

The MCP Server can generate sample records so you have something to build against. Two limits apply.

You get a maximum of 10 records per table per call. More than that means several calls.

They are sample data, not a data import. If you need to load real records, that is a different job and the MCP Server is not the tool for it.

Keep permissions on "ask each time"

Your AI builder asks permission before using each tool. You can set some tools to run without asking.

For any app with real data in it, leave permissions on "ask each time". The reason is the deletion tool above: it is one tool call away from emptying a table, and the prompt is the only thing standing between a misread instruction and your records.

"Always allow" is reasonable on a throwaway app you would not mind losing.

Two things to do differently because of these limits

Verify structural changes in the Builder. An AI builder can report that it created a table or changed a permission when it did not. After it says something changed in Knack, open the Builder and look.

Say what your tables are for before they get built. Which tables hold people who sign in is the single most expensive thing to get wrong, because it cannot be corrected without starting that table again.

Common mistakes

Expecting your builder to show you your data. It cannot. Check records in the Builder.

Sharing a private API key so it can. That key bypasses every access rule in your app. It should never go into front-end code or a chat window.

Asking it to delete "just the test records". Deletion is all or nothing.

Assuming a field type can be corrected later. It cannot, and fixing it loses the column's data.

Next steps

• Knack MCP Server vs. Runtime Data API covers which interface handles what, and why most projects use both.
• Connecting Claude Code to Knack covers setting the connection up.
• Knack MCP Server covers connecting the server to other AI development tools.