Keep up to date with the latest news and thought leadership.
AI can be useful inside a FileMaker system, but the safest approach is not to let an AI assistant freely change records, rewrite logic, or make business decisions on its own.
A better approach is to expose specific, approved FileMaker actions.
In this guide, we will walk through a simple example: allowing an AI assistant to help complete a job and notify accounting when the job is ready for invoicing.
The goal is not to replace FileMaker’s business logic. The goal is to make an existing FileMaker workflow easier to access.
A user should be able to ask something like:
“Mark job 10482 complete and let accounting know it is ready for invoicing.”
Behind the scenes, the AI assistant should not invent the process. It should call a FileMaker script that already knows how to handle the workflow safely.
That script should:
The important design principle is simple: AI can request the action, but FileMaker performs the action.
For a basic version, you might already have a Jobs table. If not, this example assumes something like the following.
Jobs table:
You may also want an audit table.
AI_ActionLog table:
This log table is important. If an AI assistant is going to request actions inside FileMaker, you should be able to review what was requested, what script was called, which record was affected, and what result was returned.
Start inside FileMaker.
Create a script called something like:
AI | Complete Job and Notify Accounting
This script should not assume the request is valid. It should validate everything.
A simple script flow might look like this:
A script parameter might look like this:
{
“jobNumber”: “10482”,
“requestedBy”: “jane@example.com”,
“requestText”: “Mark job 10482 complete and let accounting know it is ready for invoicing.”
}
A successful script result might look like this:
{
“success”: true,
“jobNumber”: “10482”,
“status”: “Ready for Invoicing”,
“message”: “Job 10482 has been marked complete and accounting has been notified.”
}
An error result might look like this:
{
“success”: false,
“jobNumber”: “10482”,
“error”: “Missing required fields”,
“missingFields”: [“Completed Quantity”, “Final Inspection Date”],
“message”: “Job 10482 cannot be completed until the missing fields are filled in.”
}
This result is what allows the AI assistant to respond clearly to the user.
This is the most important part of the implementation.
Do not expose a script to an AI assistant until the script can safely handle invalid, incomplete, or unexpected requests.
At minimum, the script should check:
The script should also commit changes before returning a success result.
If something fails, return a controlled error message. Do not leave the AI assistant guessing.
For workflows that may be run from outside the normal FileMaker interface, create dedicated layouts for automation or API-style access.
For example:
These layouts should include only the fields needed for the workflow.
This helps keep the integration cleaner. It also reduces the chance that future layout changes made for human users will accidentally affect an automation workflow.
Use a dedicated account or privilege set for the MCP connection.
That account should only have access to what the workflow requires. In many cases, that means limited access to the relevant tables and scripts, not full access to the entire file.
The script itself may need elevated privileges in specific cases, but that should be handled intentionally. The goal is to let users complete approved actions without giving the AI assistant broad access to the whole system.
A good rule of thumb:
Give the AI assistant access to tools, not the entire workshop.
Once the FileMaker workflow is ready, configure the Claris MCP connection.
In Claris MCP, select only the tables and scripts required for this use case.
For this example, you might expose:
You may not need to expose create, update, or delete tools for Jobs if the script handles the action. If those tools are generated, review whether they should be turned off.
This is where the implementation becomes safer. The AI assistant does not need permission to update any job field directly. It only needs permission to call a controlled FileMaker script that knows how to validate and complete the workflow.
The tool name and description matter because they help the AI assistant understand when to use the tool.
Instead of leaving a generic script description, write something clear.
Example tool title:
Complete Job and Notify Accounting
Example tool description:
Use this tool only when a user asks to mark a job complete and send it to accounting for invoicing. Requires a job number. The FileMaker script will validate required fields, update the job status, notify accounting, and return a success or error message.
The input schema should also be clear.
Suggested input fields:
The more specific the tool is, the more predictable the assistant’s behavior will be.
Test the workflow with both normal and messy requests.
Examples:
Then test failure cases:
The script should return clear results in every case.
This pattern works best when the AI assistant is treated as an interface layer.
The AI can understand the request, collect the required input, and call the approved tool. But FileMaker should remain responsible for the actual business rules.
That includes:
This keeps the implementation practical and safer.
Claris MCP introduces a new way for AI assistants to interact with FileMaker systems, but the best use cases are controlled.
Start with one small workflow. Build the FileMaker script first. Make it safe. Return clear JSON results. Expose only the tools the assistant needs. Test failure cases carefully.
The goal is not to let AI take over your FileMaker solution. The goal is to make trusted FileMaker workflows easier for users to access.
For many businesses, that is the right balance: a conversational front end with FileMaker still providing the structure, security, and reliability behind the scenes.
Let’s talk about how we can help you streamline, scale, or innovate—on your terms.
Start the Conversation
