MCP server for FileMaker databases via OData v4 and Data API — works with any MCP client, on-premise, no cloud dependency
FileMaker MCP server has well-structured Zod schemas with type definitions and descriptions for all 19 tools. Tool names follow verb_noun convention (fm_get_*, fm_create_*, fm_update_*, fm_delete_*, fm_run_*, fm_assert_*). Descriptions are present and substantive (avg ~150 chars), explaining WHAT each tool does and WHEN to use it. However, several critical gaps reduce the score: (1) No output schemas documented, LLMs cannot predict return structure; (2) No error handling guidance, tools fail silently without recovery hints; (3) Parameter descriptions lack format constraints (e.g., 'scriptParam' says 'JSON string recommended' but doesn't enforce it); (4) No pagination support for fm_query despite default 100-record limit; (5) Test/assertion tools (fm_create_test_record, fm_cleanup_test_data, fm_assert_*) are specialized and not core CRUD; (6) fm_batch tool accepts only GET, limiting utility. Schemas are comprehensive but descriptions could be more LLM-optimized (shorter, more prescriptive).
Add a new field to an existing FileMaker table. SQL-style field types: VARCHAR(n), INT, NUMERIC, DATE, TIME, TIMESTAMP, BLOB.
Checks whether a query returns the expected number of records. Useful for validating script results.
Validates that a FileMaker record contains the expected field values. Returns PASS/FAIL with diff.
Execute multiple OData GET requests in a single HTTP call (batch). Use individual tools for write operations.
Deletes all test records marked with a specific tag. tagField must be an existing text field in the FM table.
Create a new record in a FileMaker table.
No output schemas documented. LLMs cannot predict return structure (fields, types, pagination). Tools return raw OData/API responses without documented shape.
No error handling guidance. Tools fail without recovery hints (e.g., 'User not found. Try search_users()' or 'Invalid filter syntax. Use OData format: Name eq \'value\'').
fm_query lacks pagination metadata. Default 100-record limit is enforced but no cursor/offset guidance or total count return documented. Large result sets risk context window exhaustion.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 60 | 2026-07-28+ | v2 |
Create a new table in the FileMaker database (schema modification via OData).
Creates a test record with a test tag. tagField must be an existing text field in the FM table. Returns ROWID for later validation and cleanup.
Delete a FileMaker record by ROWID.
Reads the full OData $metadata document of the FileMaker database (EDMX/XML). Contains all tables, fields, types, and relationships.
Read a single FileMaker record by ROWID.
Lists all available EntitySets (tables/layouts) of the FileMaker database.
Analyzes the database structure: lists tables or shows all fields of a table with native FM field types from $metadata.
Query records from a FileMaker table. Supports OData $filter, $select, $top, $skip, $orderby, $expand, $count. Default limit: 100 records (override with $top).
Run a FileMaker script. Returns scriptResult with code and resultParameter.
Runs a FileMaker script and checks whether the result code matches the expected value.
Run a script with globals set (Login → Set Globals → Run Script → Logout)
Sets global fields via FileMaker Data API (not OData). Opens a Data API session, sets the globals, then closes the session. Keys must be fully qualified: 'Table::FieldName_g'.
Update an existing FileMaker record by ROWID (PATCH).
Parameter descriptions lack format constraints. 'scriptParam' says 'JSON string recommended' but doesn't enforce it. 'filter' accepts OData syntax but no examples or validation rules provided.
Test/assertion tools (fm_create_test_record, fm_cleanup_test_data, fm_assert_*) are specialized for testing workflows, not core CRUD. Unclear when agents should use these vs. standard CRUD tools.