How to Use Claris MCP to Connect FileMaker to AI Assistants

FileMaker data is becoming more accessible to AI workflows

For years, connecting FileMaker to external tools usually meant building integrations through APIs, middleware, custom scripts, or third-party services.

Claris MCP introduces a different pattern.

Claris describes MCP as a server that connects FileMaker databases to AI assistants and other MCP-compatible hosts. It acts as a bridge between Claris data and AI tools, letting you create connections, select tables and scripts, configure database tools, and generate configuration snippets for integration.

That makes it one of the more important recent developments for FileMaker teams exploring AI.

What MCP changes conceptually

The traditional integration question is:

“How do we build an API so another system can use FileMaker data?”

The MCP question is different:

“What tools should an AI assistant be allowed to use against this FileMaker system?”

That is a major shift.

Instead of exposing everything, you define controlled capabilities. Those capabilities may include access to selected tables, selected fields, and selected scripts.

That creates a more practical and safer path for AI-assisted work.

A simple architecture

A basic Claris MCP setup looks like this:

AI assistant or MCP-compatible client

       ↓

Claris MCP server

       ↓

Configured FileMaker connection

       ↓

Selected tables, fields, and scripts

       ↓

FileMaker database

The key point is that MCP is not magic access to everything. It is a configured bridge.

Claris’s getting started documentation describes the basic flow as creating a context, adding a connection to your FileMaker database, and generating a configuration snippet for the AI client.

Start with a read-only use case

The safest first use case is not “let AI update my database.”

A better first use case is controlled query and analysis.

For example:

• summarize open support cases
• find overdue project tasks
• list customers with upcoming renewals
• answer questions about current inventory
• retrieve recent activity for a client
• summarize records matching a specific condition

This lets the team learn how MCP behaves without giving the assistant permission to make operational changes too early.

Choose the right tables and fields

The most important implementation decision is what to expose.

Do not start by exposing the whole database. Start with a narrow business question.

For example, if the goal is to let an assistant answer questions about open service tickets, the MCP-accessible data might be limited to:

Tickets

– TicketID

– CustomerName

– Status

– Priority

– CreatedDate

– DueDate

– AssignedTo

– Summary

TicketNotes

– TicketID

– NoteDate

– NoteAuthor

– NoteText

You may not need billing fields, internal margin data, private employee notes, or unrelated customer tables.

Claris notes that FileMaker file accounts need access to the connected tables and fields intended to be available to the MCP client.

That means standard FileMaker privilege design still matters.

Use scripts as controlled actions

Tables let an assistant retrieve data. Scripts can let it do work.

This is where MCP becomes powerful, but also where discipline matters.

Instead of exposing broad write access, expose carefully designed scripts that perform specific operations.

For example:

Get Customer Renewal Summary

Create Follow-Up Task

Mark Ticket as Ready for Review

Add Note to Project

Generate Open Issues Report

Each script should validate its inputs, enforce business rules, and return clear results.

A good MCP-facing script should behave like a small internal API endpoint:

Input: structured JSON

Process: validate, act, log

Output: structured JSON result

That makes the AI assistant easier to control because it can only take actions through scripts you intentionally provide.

Privileges and extended privileges matter

MCP is not a reason to ignore FileMaker security. It depends on it.

Claris documents that accounts used for MCP connections must have both fmrest and fmodata extended privileges enabled. It also notes that field access must be available for the tables and fields you intend to expose.

That means MCP setup should involve a dedicated privilege set, not a full-access developer account.

A practical starting approach:

Create a dedicated MCP account

Create a dedicated privilege set

Expose only required layouts, tables, and fields

Enable only required extended privileges

Limit scripts to MCP-safe operations

Test with read-only workflows first

This keeps the integration more controlled.

Be careful with value lists on FileMaker Server 22.0.2

Claris notes a system limitation in FileMaker Server 22.0.2 where value list access should be disabled to prevent errors with the MCP connection.

That kind of detail matters in a real setup guide because it can save developers from chasing confusing connection issues.

Generate and use the client configuration

After configuring the MCP context and connection, Claris MCP can generate a configuration snippet for the MCP client. Claris’s integration documentation says you copy the JSON configuration and paste it into the MCP client settings so the assistant can access FileMaker data through the configured tools.

A typical implementation flow looks like this:

1. Install and configure Claris MCP
2. Create a context
3. Add a FileMaker database connection
4. Select approved tables and scripts
5. Generate the MCP configuration snippet
6. Add the snippet to the MCP-compatible AI client
7. Test with low-risk prompts
8. Review logs, permissions, and returned results

The important part is not the snippet itself. It is the preparation before the snippet is generated.

Design prompts around allowed tools

Once MCP is configured, users may be able to ask natural-language questions that invoke the configured tools.

For example:

Show me all open high-priority tickets assigned to Mark.

or:

Summarize overdue renewal follow-ups for this week.

For action-oriented workflows, keep prompts clear and constrained:

Create a follow-up task for customer ABC Manufacturing about their renewal.

But again, the assistant should only be able to do this if you exposed a safe script for creating follow-up tasks.

Add logging and review

AI-assisted access to FileMaker should be observable.

For any MCP-enabled workflow, consider logging:

• Who used the assistant
• What tool was called
• What inputs were passed
• What script ran
• What record was affected
• Whether the action succeeded or failed

This is especially important once you allow script-based actions.

A good internal log table might include:

MCPLog

– LogID

– Timestamp

– User

– ToolName

– InputJSON

– ResultJSON

– RelatedRecordID

– Status

That gives administrators a way to review behavior and troubleshoot unexpected results.

Where Claris MCP fits best

Good early use cases include:

• Internal data lookup
• Operational summaries
• Task creation through controlled scripts
• Customer or project brief generation
• Support case review
• Management reporting prompts

Riskier use cases include:

• Financial updates
• Compliance decisions
• Mass record changes
• Anything involving sensitive data without strict privilege design
• Any action that bypasses existing FileMaker validation

MCP is strongest when it gives AI a controlled way to interact with FileMaker, not when it opens the database broadly.

Final thought

Claris MCP is not just another integration option. It changes the interface between FileMaker and AI systems.

Instead of building one-off API endpoints for every assistant-driven use case, developers can expose selected FileMaker data and scripts as controlled tools.

That is powerful, but it should be approached carefully.

Start read-only.
Expose less than you think you need.
Use scripts for controlled actions.
Keep FileMaker privileges tight.
Log what the assistant does.

That is how MCP becomes useful without turning into a governance problem.