Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@filemaker-mcp show me the schema for the Customers table"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Connect Claude (or any MCP client) to a FileMaker database — read-only queries, schema discovery, and pandas-powered analytics.
filemaker-mcp is an MCP server that gives AI assistants live access to your FileMaker data via OData v4. Load it in Claude Desktop or Claude Code and ask questions about your data in plain English.
Tools provided:
fm_query_records — Search and filter records with OData expressions
fm_get_record — Fetch a single record by primary key
fm_count_records — Count records with optional filters
fm_list_tables — List available tables
fm_get_schema — Discover field names, types, and keys
fm_load_dataset — Pull records into memory for analytics
fm_analyze — Run groupby/sum/count/mean/min/max on loaded data
fm_list_datasets — See what datasets are loaded
Related MCP server: filemaker-odata-mcp
Python 3.12+
uv package manager
FileMaker Server with OData v4 enabled
An FM account with fmodata extended privilege
git clone https://github.com/nietsneuah/filemaker-mcp.git
cd filemaker-mcp
cp .env.example .env
# Edit .env with your FileMaker server details
uv syncAdd to your Claude Desktop MCP config
(~/Library/Application Support/Claude/claude_desktop_config.json on macOS):
{
"mcpServers": {
"filemaker": {
"command": "uv",
"args": ["run", "--directory", "/path/to/filemaker-mcp", "filemaker-mcp"],
"env": {
"FM_HOST": "your-server.example.com",
"FM_DATABASE": "your_database",
"FM_USERNAME": "mcp_agent",
"FM_PASSWORD": "your_password"
}
}
}
}uv run filemaker-mcpOn startup, the server auto-discovers your tables from the OData service
document. For richer schema (field types, primary keys, tiers), install the
optional GetTableDDL FileMaker script — see docs/FM_ACCOUNT_SETUP.md.
For reports and summaries, use the analytics tools instead of raw queries:
fm_load_dataset — Fetch records into a pandas DataFrame (auto-paginates)
fm_analyze — Run aggregations instantly (no additional FM round trips)
This returns ~200 tokens instead of ~400K for raw records — much more efficient for dashboards and trend analysis.
Architecture — System design and security model
FM Account Setup — FileMaker privilege configuration
Tool Reference — Detailed parameter docs
GPL-3.0 — see LICENSE
Doug Hauenstein / FM Rug Software
Analyze a loaded dataset with groupby/aggregation. No FM round trip.
Runs pandas aggregation on a previously loaded dataset OR a table from the auto-populated table cache (from query_records). Returns compact summary tables instead of raw records — ~200 tokens vs ~400K tokens.
Behavior by parameter combination:
groupby + aggregate: Grouped aggregation (most common)
aggregate only: Scalar aggregation across all rows
groupby only: Group counts (value_counts)
neither: Summary statistics (describe)
period: Time-series resampling (week/month/quarter)
pivot_column: Cross-tabulation pivot table
Supported aggregate functions: sum, count, mean, min, max, median, nunique, std
Args: dataset: Name of a previously loaded dataset (from fm_load_dataset), or a table name from the auto-populated table cache. groupby: Comma-separated field names to group by. Example: "Technician,Region" aggregate: Comma-separated function:field pairs. Example: "sum:Amount,count:Amount,mean:Amount" filter: Pandas query expression to narrow data before aggregating. Example: "Region == 'A'" or "Amount > 500" sort: Sort result by column name with optional direction. Example: "Amount_sum desc" limit: Maximum rows in output (default 50). period: Time-series resampling — "week", "month", or "quarter". First groupby field must be a datetime column. Example: groupby="ServiceDate", period="month" pivot_column: Cross-tabulate by this column (pivot table). Requires groupby for row index and aggregate for values. Example: groupby="Technician", pivot_column="Region", aggregate="sum:Amount"
Returns: Formatted summary table with aggregation results.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | ||
| limit | No | ||
| filter | No | ||
| period | No | ||
| dataset | Yes | ||
| groupby | No | ||
| aggregate | No | ||
| pivot_column | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It comprehensively discloses behavior: it performs pandas aggregation, returns compact summary tables, details behavior by parameter combination (groupby+aggregate, etc.), and notes no FM round trip. This is highly transparent for a read-only analysis tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with a clear summary, followed by efficiency note, detailed parameter combination behaviors, and then bullet-pointed args. However, it is somewhat lengthy and could be more concise (e.g., 'No FM round trip' appears twice). Still, it earns its sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (8 parameters, detailed combinations), the description is very complete. It covers all parameter behaviors, supported aggregate functions, examples, and return type. An output schema exists (mentioned in context), so the description need not detail return values. It is sufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does so excellently by documenting each parameter with format, examples, and constraints (e.g., 'groupby: Comma-separated field names', 'aggregate: Comma-separated function:field pairs', 'filter: Pandas query expression'). This adds significant meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it analyzes a loaded dataset with groupby/aggregation, distinguishing itself from siblings like fm_query_records by emphasizing it returns compact summary tables (~200 tokens vs ~400K tokens) and mentions 'No FM round trip'. This is a specific verb-resource combination that differentiates it well.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool: for aggregation/summarization instead of raw records. It also notes it works on previously loaded datasets or auto-populated table cache from query_records. However, it does not explicitly list when not to use it or provide alternative tool names, though the contrast with fm_query_records implies it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the total record count for an FileMaker table, optionally filtered.
Quick way to check data volume or validate filter expressions before running a full query.
Args: table: Table name (see fm_query_records for available tables). filter: Optional OData $filter expression to count matching records.
Returns: The record count as a text message.
| Name | Required | Description | Default |
|---|---|---|---|
| table | Yes | ||
| filter | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It explains that the tool returns a count as a text message, which is a key behavioral detail. However, it does not mention potential side effects, authentication needs, or performance implications. Given the simplicity of the tool, the coverage is adequate but not extensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with a brief introductory sentence, a usage hint, and an Args section. It is well-structured and front-loaded with the purpose. Each part serves a clear function, but the overall length is appropriate for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the description is complete. It covers the purpose, parameters, return value (count as text message), and usage context. The presence of an output schema (not shown but indicated) further reduces the need for detailed return value explanation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, leaving the description to explain parameters. The description provides clear semantics for both parameters: 'table' is explained with a cross-reference to fm_query_records for available tables, and 'filter' is described as an 'OData $filter expression.' This adds meaningful context beyond the schema's type and default.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get the total record count'), the resource ('FileMaker table'), and the optional filtering. It differentiates from siblings like fm_query_records, which returns individual records.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description suggests using this tool as a 'quick way to check data volume or validate filter expressions before running a full query.' It references fm_query_records in the Args section, providing context for when to use it. However, it does not explicitly state when not to use it or list alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete an operational learning about a FileMaker field or table.
Call this to remove stale or incorrect context entries — for example, when a table or field has been renamed/deleted, or when a previously saved hint is no longer accurate.
The record is deleted from FM and removed from the local cache immediately.
Args: table_name: Table this applies to (e.g., "Invoices"). field_name: Specific field name, or empty for table-level context. context_type: Category — "field_values", "syntax_rule", "query_pattern", "relationship".
Returns: Confirmation message or error description.
| Name | Required | Description | Default |
|---|---|---|---|
| field_name | No | ||
| table_name | Yes | ||
| context_type | No | field_values |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It discloses that the record is deleted from FM and removed from local cache immediately. It does not mention authorization or potential side effects, but for a delete operation this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is clear and well-structured, with separate paragraphs for purpose, usage, and parameters. However, the Args section could be streamlined into a more concise format without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (3 parameters, no annotations, output schema exists), the description covers all aspects: what it does, when to use, the effect (immediate deletion), and return type (confirmation/error). It is complete for an AI agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description explains each parameter with examples: table_name (e.g., 'Invoices'), field_name (empty for table-level), context_type (lists categories like field_values, syntax_rule). This adds significant meaning beyond the schema, which only has defaults and types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it deletes an operational learning context entry for a FileMaker field or table. The verb 'delete' and resource are specific, and it is easily distinguished from siblings like fm_save_context (which saves) and query tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies when to use: removing stale or incorrect context entries, with concrete examples (renamed/deleted fields, inaccurate hints). It implies when not to use (when context is accurate) but lacks explicit when-not or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Flush cached table data from session memory.
The MCP server auto-caches query results per table for fast repeat access. Use this to force a fresh fetch from FileMaker — for example, after data has been modified, or to free memory.
Args: table: Specific table to flush (e.g., "Invoices"). Leave empty to flush ALL cached tables.
Returns: Confirmation with number of rows/tables flushed.
| Name | Required | Description | Default |
|---|---|---|---|
| table | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes caching behavior and effect of flushing, including return confirmation. Without annotations, it covers main points, though it doesn't detail all side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise, well-structured with title, explanation, args, returns. No waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Completes the tool picture: explains when to use, what it does, parameter semantics, and return value. Output schema exists so return details are adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds meaning to the only parameter 'table': explains default flushes all, and gives example. Compensates for 0% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it flushes cached table data from session memory. The verb 'flush' and resource 'cached table data' are specific. It distinguishes from query and load tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly suggests use after data modification or to free memory. Does not state exclusions but context makes them clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a single FileMaker record by its primary key.
Use this when you know the specific record ID and want full details.
Args: table: Table name (use fm_list_tables for available tables). record_id: The primary key value to look up. id_field: The primary key field name (use fm_get_schema to find PKs).
Returns: Formatted text with all fields for the matching record.
| Name | Required | Description | Default |
|---|---|---|---|
| table | Yes | ||
| id_field | No | ||
| record_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It describes the return as 'Formatted text with all fields for the matching record' but does not disclose error handling (e.g., lookup failure) or authentication needs. Adequate for a simple getter but slightly incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (8 lines plus Args) and well-structured: a clear summary sentence, usage guidance, and parameter explanations. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (get by PK) and the presence of an output schema (context confirms), the description adequately covers usage context, parameter sources, and return format. No gaps for this use case.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description fully compensates by explaining each parameter in the Args section: table (use fm_list_tables), record_id (primary key value), id_field (use fm_get_schema to find PKs). This adds significant value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get a single FileMaker record by its primary key,' specifying the verb (get), resource (FileMaker record), and method (by primary key). It distinguishes from sibling tools like fm_query_records, which likely handles complex queries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit guidance on when to use ('when you know the specific record ID and want full details') and how to find valid table names and primary key fields via fm_list_tables and fm_get_schema. Lacks explicit exclusions or alternatives for when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the database schema (field names and types) from FileMaker.
Use this to discover exact field names, their types, and primary keys before constructing queries. Essential for building accurate filter and select expressions.
IMPORTANT: Always call this with a specific table name before querying that table for the first time — many field names contain spaces.
Schema is cached in memory for the session. If you need a table not in the standard list, just request it — the server will auto-discover it from FileMaker.
Args: table: Table name to get fields for (e.g., "Customers", "Orders"). Leave empty to list all available tables. You can request any table that exists in FileMaker — not just the standard list. Unknown tables are auto-discovered. refresh: Force re-fetch from live FM server. Use when you suspect the schema has changed (e.g., new fields added in FileMaker). Default uses cached DDL (instant, no API call). show_all: Show all fields including internal/system fields. Default hides internal fields (globals, speed fields, etc.) to keep schema output concise.
Returns: Formatted listing of fields with names, types, and annotations.
| Name | Required | Description | Default |
|---|---|---|---|
| table | No | ||
| refresh | No | ||
| show_all | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses caching, auto-discovery of tables, and refresh behavior. No annotations exist, so description carries full burden; it covers non-destructive nature and return format but could mention any authorization requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear paragraphs, front-loaded purpose, and no wasted words. Efficiently conveys all necessary information in a digestible format.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description sufficiently explains returns. It covers all 3 parameters, usage context, and caching behavior. No gaps for typical agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description thoroughly explains each parameter: table (name/empty behavior), refresh (force re-fetch), show_all (internal fields). Adds meaning like auto-discovery and caching details not in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the FileMaker database schema (field names and types). It differentiates from sibling tools by emphasizing schema discovery for query construction, and explicitly links to usage before querying tables.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance to call with a specific table before first query, mentions caching, and refresh for stale schema. Does not directly contrast with fm_list_tables, but the context is clear enough for proper use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all datasets currently loaded in session memory.
Shows what's available for analysis with fm_analyze. Includes dataset name, source table, row count, columns, and load time.
Returns: Formatted list of loaded datasets, or message if none loaded.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description accurately describes tool as a read operation listing datasets with details. No hidden side effects or contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four concise sentences with each sentence adding value: purpose, usage context, included fields, return type. Front-loaded and no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no parameters and description fully explains what it returns (formatted list or message). Given simplicity and sibling tools, description is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters, so baseline 4 per rules. Description adds no parameter info, but none needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb 'list' with specific resource 'datasets currently loaded in session memory'. Differentiates from siblings like fm_list_tables (DB tables) and fm_query_records (querying records).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
States this tool shows what's available for analysis with fm_analyze, indicating when to use it. No explicit exclusion but context is clear given sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available FileMaker tables and their descriptions.
Use this to understand what data is available before querying. Always start here if unsure which table to query.
Returns: List of table names with descriptions of what each contains.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It mentions the return type but does not disclose additional traits like side effects, permissions, or error states. Adequate for a simple listing tool but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences, each serving a distinct purpose: purpose, usage guidance, and output summary. Front-loaded and no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and an output schema existing, the description adequately explains the return format and complements the structured fields. Complete for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters in the schema (100% coverage), so the description need not add param meaning. Baseline 4 is appropriate; the description effectively explains the return value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'FileMaker tables and their descriptions', distinguishing it from sibling tools that query records or schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance on when to use ('understand what data is available before querying') and a recommendation ('Always start here if unsure which table to query'). No explicit exclusions, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all configured FileMaker tenants and show which is active.
Shows tenant names, hosts, and databases. Use fm_use_tenant() to switch to a different tenant.
Returns: Formatted list of tenants with the active one marked.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description covers basic behavior (lists tenants, shows active) but doesn't explicitly state read-only nature or other traits. Adequate for a list tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: 3 sentences plus a 'Returns:' line. Front-loaded with main purpose, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no parameters and an output schema existing, description covers the return format adequately. Could mention if limits exist, but sufficient for a simple list.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Zero parameters, so schema coverage is vacuously 100%. Description adds no param-level meaning but correctly describes output, meeting baseline for no params.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'List all configured FileMaker tenants and show which is active.' It distinguishes from siblings like fm_use_tenant, which is for switching, and other query tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use fm_use_tenant() to switch to a different tenant,' providing an alternative. Lacks explicit when-not but context with siblings makes it clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Load FileMaker records into a named dataset for fast analytics.
Fetches records from FM and stores them as a pandas DataFrame in session memory. Load once, then run multiple analyses with fm_analyze — no additional FM round trips needed.
Auto-paginates if more than 10,000 records match. Loading a dataset with an existing name replaces it (refresh).
IMPORTANT: Call fm_get_schema(table) first to discover field names.
Args: name: Your chosen identifier for this dataset (e.g., "inv25", "customers"). table: FM table to query (see fm_list_tables for available tables). filter: OData $filter expression. Use exact field names from get_schema. Example: "ServiceDate ge 2025-01-01 and ServiceDate lt 2026-01-01" select: Comma-separated fields to fetch. Leave empty for all fields. TIP: Select only the fields you need — reduces memory and speeds loading. Example: "Technician,Region,Amount,ServiceDate"
Returns: Summary with row count, columns, and memory usage.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| table | Yes | ||
| filter | No | ||
| select | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses replacement behavior, auto-pagination, and in-memory storage. No annotations provided, so description carries burden; it covers key behaviors but could mention error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with sections, no fluff, every sentence adds value. Purpose is front-loaded, followed by details and examples.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given complexity, sibling tools, and presence of output schema, the description is complete. It explains return summary, prerequisites, and examples.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% coverage, so description must define parameters. It explains each parameter clearly: name as identifier, table as FM table, filter with OData example, select with memory-saving tip.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it loads FM records into a named dataset for analytics, stores as DataFrame, and distinguishes from siblings like fm_query_records and fm_analyze.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit prerequisite (call fm_get_schema first), tips on select field, and context for auto-pagination and dataset replacement. Clear guidance on when and how to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Query FileMaker records from a FileMaker table using OData v4.
Use this tool to search, filter, and retrieve records from your FileMaker database.
Args: table: Table name (use fm_list_tables to see available tables). filter: OData $filter expression. ALWAYS call fm_get_schema(table) first — field names vary by table. Examples (use exact names from get_schema): - "City eq 'Springfield'" - "ServiceDate ge 2026-01-01" - "Amount gt 500" - "Region eq 'A' and Status eq 'Open'" select: Comma-separated field names to return. Leave empty for all fields. Example: "Company Name,Phone,City,Email" top: Maximum records to return (default 20, max 10000). skip: Number of records to skip (for pagination). orderby: OData $orderby expression. Example: "ServiceDate desc" or "Company Name asc" count: Include total record count in response (default True).
Returns: Formatted text with matching records and field values.
| Name | Required | Description | Default |
|---|---|---|---|
| top | No | ||
| skip | No | ||
| count | No | ||
| table | Yes | ||
| filter | No | ||
| select | No | ||
| orderby | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses default top (20), max records (10000), pagination via skip, count parameter, and return type (formatted text). Lacks explicit statement that it's read-only, but no contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with Args section, examples, and return value. Slightly verbose but each sentence adds value; no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all parameters, return format, and usage prerequisites. Could mention error scenarios, but overall sufficient for a complex tool with 7 parameters and no annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema coverage, the description explains every parameter in detail with examples and defaults, adding significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it queries FileMaker records using OData v4, distinguishing from sibling tools like fm_get_record (single record) and fm_count_records (count).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides excellent usage guidance: references fm_list_tables for table names, instructs to call fm_get_schema first, and gives detailed filter examples. However, does not explicitly state when not to use this tool (e.g., for single record use fm_get_record).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Save an operational learning about a FileMaker field or table.
Call this when you discover useful information during queries:
Field value mappings (e.g., Commercial field uses "1" not "Yes")
OData syntax rules (e.g., "ne" operator not supported)
Query patterns (e.g., how to join two tables)
Relationships (e.g., FK between Invoices and Customers)
Value normalization maps (e.g., "Jake" and "Jacob Owens" are the same person)
The learning is saved to FM and loaded automatically at next startup, so future sessions benefit immediately.
Args: table_name: Table this applies to (e.g., "Invoices"). context: What you learned. For most types, free text (e.g., "Boolean: 1=yes, empty/0=no"). For "value_map" type, MUST be a JSON object mapping variant values to their canonical form, e.g. '{"Jake": "Jacob Owens", "Bob": "Robert Smith"}'. field_name: Specific field name, or empty for table-level context. context_type: Category — "field_values", "syntax_rule", "query_pattern", "relationship", or "value_map". Use "value_map" when the user identifies that two field values represent the same entity (e.g., nicknames, abbreviations, data entry variants). Value maps are applied automatically during fm_analyze groupby. source: How this was discovered — "auto", "auto:filter_discovery", "manual".
Returns: Confirmation message or error description.
| Name | Required | Description | Default |
|---|---|---|---|
| source | No | auto | |
| context | Yes | ||
| field_name | No | ||
| table_name | Yes | ||
| context_type | No | field_values |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility. It discloses that learning is 'saved to FM and loaded automatically at next startup' and that future sessions benefit immediately. Return type is stated as 'Confirmation message or error description.' It could mention persistence details (e.g., append vs. overwrite), but it covers key side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: a concise opening sentence, bullet points for use cases, a persistence note, then an Args section. It is front-loaded and every sentence adds value, though it is slightly longer than necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the number of parameters and presence of output schema, the description covers purpose, usage, all parameters, and return type. It could be more specific about error handling or overwrite behavior, but overall it provides sufficient context for an AI agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description fully compensates. Each parameter is explained in detail (table_name, context, field_name, context_type, source) with examples, valid values for context_type, and special formatting requirements for 'value_map'. This adds meaning far beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Save an operational learning about a FileMaker field or table.' This distinguishes it from sibling tools like fm_query_records or fm_analyze, which are for reading or analyzing data, not saving learned context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly calls out when to use: 'Call this when you discover useful information during queries:' and lists specific scenarios (value mappings, syntax rules, etc.). It does not mention explicit alternatives or when not to use, but the use cases are clear and distinct from siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Switch to a different FileMaker tenant.
Connects to the named tenant's FM server and discovers its schema. First switch triggers full bootstrap (may take a few seconds). All subsequent queries go to this tenant.
Args: name: Tenant name as configured (e.g., "production", "staging"). Case-insensitive. Use fm_list_tenants() to see available names.
Returns: Connection summary with host, database, and table count.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully explains behavioral traits: first switch is slow, subsequent queries target the new tenant, and it returns a connection summary.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is reasonably concise, but the return value section could be more integrated; overall it is well-organized and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the description covers the core behavior and parameter sufficiently, though it could mention potential side effects like losing unsaved context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description adds essential meaning for the 'name' parameter, including examples, case-insensitivity, and reference to fm_list_tenants() for available names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Switch to a different FileMaker tenant' clearly states the specific verb and resource, and distinguishes the tool from sibling tools that query or manipulate records.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions that the first switch triggers a slower bootstrap and advises using fm_list_tenants() to discover valid names, providing clear context for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0fm_analyzefm_count_recordsfm_delete_contextfm_flush_datasetsfm_get_recordfm_get_schemafm_list_datasetsfm_list_tablesfm_list_tenantsfm_load_datasetfm_query_recordsfm_save_contextfm_use_tenantEach tool has a clearly distinct purpose: querying records, fetching single records, counting, listing tables, fetching schema, loading datasets, analyzing, managing datasets, switching tenants, and managing context. No overlapping functionality.
All tools follow the consistent 'fm_verb_noun' pattern (e.g., fm_query_records, fm_list_tables, fm_get_schema). The naming is uniform and predictable.
13 tools is well-scoped for the server's purpose of querying, analyzing, and managing FileMaker data across tenants with context saving. Each tool earns its place.
The tool set covers read operations and analytics well, but lacks write capabilities (no create, update, or delete records). This is a notable gap for a database interaction server.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Connect your AI assistants to Keboola and expose your data, transformations, SQL queries, ...
The all-in-one data stack for agents. Upload files, run SQL, evolve tables, and render charts.
Query your team's drift, vulnerability, and upgrade data from any AI assistant. OAuth 2.1, 51 tools.
Generate realistic, FK-consistent synthetic test data for your databases from your AI assistant.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/nietsneuah/filemaker-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
