data-filter-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| register_filterA | Validate and register a restricted Python filter for later execution on a local file. Use this tool first when you want to run custom filtering or transformation logic against a local document. The submitted source code must define exactly one top-level function with this exact signature: The server loads the target file before execution and passes the loaded document into filter_item(data). Input document types:
The function must return a text result (str). The returned text may contain any format you want, such as plain text, YAML, CSV-like text, or a custom report. Preloaded standard-library modules (don't try to import them in your functions):
Safety rules:
Forbidden:
Args: code: Python source code that defines exactly one function named filter_item(data). Returns: A structured object containing the new filter identifier, expiration timestamp, TTL in seconds, and validation policy version. Raises: ValueError: If the code is invalid, unsafe, or does not match the required function signature. |
| run_filterA | Run a previously registered filter on a local file and return its text output. Use this tool after register_filter. The server resolves the registered filter, loads the file from the local filesystem, converts it into an in-memory document, calls filter_item(data), and returns the exact text produced by the filter. Supported file types:
If file_type is omitted, the server tries to detect the type from the file extension. File loading behavior:
Args: filter_id: Identifier returned earlier by register_filter. file_path: Path to the local file that should be loaded and passed into the filter. file_type: Optional explicit file type override. Use this when extension-based detection is missing or ambiguous. Returns: A structured object containing the filter identifier, resolved file path, effective file type, filter expiration time, and result_text. Raises: ValueError: If the filter does not exist, has expired, returns a non-string result, or the file type is unsupported. FileNotFoundError: If the file does not exist. |
| convert_fileA | Apply a registered filter to a source file and save the text output. Use this tool after register_filter when you want to transform a local json, yaml, or txt file and persist the returned string as UTF-8 text. The destination path must be inside a configured --workdir; unlike run_filter, convert_file refuses to write when no --workdir is configured. Missing destination parent directories are created automatically. Existing destination files are rejected unless overwrite is true. Args: filter_id: Identifier returned earlier by register_filter. source_file_path: Absolute path to the source file to load. destination_file_path: Absolute path where result text is saved. file_type: Optional explicit source file type override. overwrite: Whether to replace an existing destination file. Returns: A structured object describing the written file and filter metadata. Raises: ValueError: If paths are invalid, workdir is missing, the filter is unknown or expired, destination exists without overwrite, or the filter returns a non-string result. FileNotFoundError: If the source file does not exist. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 3 tools
Each tool has a unique and clearly defined purpose: register_filter validates and stores a filter, run_filter executes it on a file and returns text, and convert_file executes and saves the result to a file. There is no overlap or ambiguity.
All tool names follow a consistent verb_noun pattern in snake_case (register_filter, run_filter, convert_file), making the API predictable and easy to navigate.
With only 3 tools, the server is minimal but well-scoped for its purpose of applying custom filters to files. The count is appropriate for a focused utility, though additional management tools (e.g., list_filters) could be added without bloat.
The tools cover the essential workflow: register a filter, run it (in-memory output), and convert it (persisted output). Missing are filter listing, deletion, or inspection, but the automatic expiration mitigates the need for explicit management.