Early Preview: 🚧 These docs are still a work in progress. 🚧 Keep checking back for updates!
ProofKit

Architecture

How ProofKit connects agents, local tools, FileMaker, and Web Viewer apps.

ProofKit has two related architectures: the development loop that lets an agent build the app, and the runtime loop that lets the deployed Web Viewer app talk to FileMaker.

Development architecture

MCP Local API Script calls Coding agent ProofKit MCP server FileMaker plug-in ProofKit add-on Your FileMaker file Web project Web Viewer bundle

Connection labels

  • MCP: Model Context Protocol, the tool protocol the coding agent uses to talk to the ProofKit MCP server.
  • Local API: The local bridge between the ProofKit MCP server and the FileMaker plug-in.
  • Script calls: FileMaker script execution used by the plug-in and add-on to work with your FileMaker file.

Runtime architecture

ProofKit type safeclient fmFetch() Web Viewer app Execute DataAPI Step FileMaker scripts FileMaker database External APIs File system Printing and PDF

Connection labels

  • ProofKit type safe client: Generated client code that calls FileMaker's Data API through the Execute Data API script step.
  • fmFetch(): A lightweight script bridge for calling FileMaker scripts from the Web Viewer app.

How to think about it

  • During development, the agent uses ProofKit tools to understand the FileMaker file and deploy bundles.
  • At runtime, the deployed web app talks to FileMaker through fmFetch scripts and the type-safe Data API path.
  • FileMaker scripts remain the secure place for privileged operations, external API secrets, filesystem work, and print/PDF flows.

On this page