Loading ToolBench
Model Context Protocol (MCP) server providing FileMaker Server OData 4.01 API integration with database introspection for AI agents. Compatible with Claude, Windsurf, Cursor, Cline, and other MCP-enabled assistants.
This server demonstrates good overall structure with 29 well-defined tools covering FileMaker OData integration. All tools have descriptions (100-300 chars, well within baselines) and schemas with typed parameters. Naming follows verb_noun conventions consistently (fm_odata_query_*, fm_odata_create_*, etc.). However, several pattern gaps reduce the score: (1) Most parameters lack detailed constraints (ranges, enums, format specifications); (2) No enum constraints on string parameters like authType, fieldType; (3) Output schemas are not documented, descriptions state what tools return but formal schema definitions are absent; (4) Error handling guidance is minimal, tool descriptions don't explain how to recover from failure or what errors might be retryable; (5) No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk stratification in metadata; (6) Batch tools (fm_odata_batch_create, etc.) accept flexible 'records' and 'data' objects without documenting expected structure; (7) Credentials in connection tools, fm_odata_connect and fm_odata_save_connection expose password parameters, violating secret injection pattern; (8) No documented permission model or scope declarations. Strengths: consistent naming, comprehensive descriptions (10 each tool), proper parameter typing for basics (string, number, boolean, array, object), good separation of concerns (separate tools for CRUD, batch, schema, config), and appropriate risk labeling in metadata.
Add a new field to an existing FileMaker table
Create multiple records in a FileMaker table in a single batch operation
Delete multiple records from a FileMaker table in a single batch operation
Update multiple records in a FileMaker table in a single batch operation
Establish a connection to a FileMaker Server OData API using provided credentials
Establish multiple connections to different FileMaker databases in a single operation
Create a new record in a FileMaker table with specified field values
Credentials exposed as tool parameters: fm_odata_connect and fm_odata_save_connection accept 'password' and 'bearerToken' as parameters. These will be logged in agent traces, exposing secrets. Use server-side secret injection via environment variables or vault instead.
No output schemas documented. Descriptions state what tools return (e.g., 'read a single record', 'list available tables') but formal JSON Schema definitions for response objects are missing. LLMs cannot infer field names, types, or availability of chaining IDs without documented schemas.
Missing enum constraints on string parameters. 'authType' accepts 'basic' or 'bearer' but is free-form string without enum. 'fieldType' in fm_odata_add_field lacks enum (NUMERIC, VARCHAR, DATE, etc.). Free-form strings invite LLM hallucination; use JSON Schema enum.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 61 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 44 | - | v1 |
Create a new table in FileMaker with specified fields and configuration
Delete a field from a FileMaker table (requires FM_ALLOW_SCHEMA_EDITS=true)
Delete a record from a FileMaker table by its ID
Delete a table from FileMaker database (requires FM_ALLOW_SCHEMA_EDITS=true)
Get detailed information about active in-memory sessions including server, database, and version info
Get detailed schema information (fields, types, relationships) for a FileMaker table
Get the current server configuration (transport, host, port, and FileMaker defaults)
Get the FileMaker Server version for the active session and feature compatibility matrix
List all active in-memory sessions (connections) currently available in the server
List all saved connection configurations from the local config file
List all available tables in the connected FileMaker database
Retrieve all records from a table, automatically handling pagination with a server-wide cap on returned records
Execute an OData query against a FileMaker table with filtering, sorting, pagination, and field selection
Read a single record by its ID from a FileMaker table
Execute a FileMaker script via the OData API and retrieve its result
Save a FileMaker Server connection configuration to the local config file for future use
Set the maximum number of records allowed per batch operation
Set the server-wide cap on total records returned by queryAllRecords
Set the request timeout for subsequent OData API calls
Switch to an active in-memory session or saved connection by name
Test connectivity to a saved FileMaker Server connection
Update an existing record in a FileMaker table by its ID
No error guidance in tool descriptions. Tools do not explain what errors might occur, whether they are retryable, or what the LLM should do on failure. For example, fm_odata_run_script lacks guidance on script execution failures; fm_odata_connect lacks guidance on SSL/network errors.
No tool annotations despite clear risk stratification. Tools are marked with Risk=DESTRUCTIVE, IRREVERSIBLE, WRITE in metadata but lack MCP tool annotations (readOnlyHint, destructiveHint, idempotentHint). These annotations let agents reason about safety.
Batch tools lack documented input structure. fm_odata_batch_create accepts 'records' as type 'array' with description 'Array of record objects to create' but does not specify the schema for each record object (field names, types, required fields).
No numeric constraints documented. Parameters like 'top' (max records), 'skip' (offset), 'timeout', 'batchMaxItems', and 'maxRecords' lack documented ranges. Unbounded numbers allow LLMs to pass absurd values (timeout=999999, top=1000000).
No permission model or scope declarations. Tools do not declare what permissions they require (e.g., 'read:database', 'write:database', 'admin'). This prevents least-privilege agent configurations and clear audit trails.
No confirmation step for destructive operations. fm_odata_delete_record, fm_odata_delete_table, and fm_odata_batch_delete support immediate deletion without dry-run or confirmation. Agents can make catastrophic mistakes without a safety mechanism.
Connection dependency not documented. Tools like fm_odata_query_table require an active connection (set via fm_odata_connect or fm_odata_switch_connection) but this dependency is not stated in their descriptions. LLMs cannot infer that setup is required.