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 modules (no imports needed; redundant import statements for these modules are accepted, including aliases):
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
register_filter clearly creates and validates a new filter, while run_filter and convert_file both execute an existing filter. Their output behaviors (return text vs write a file) are well described, but the shared execution step creates some potential for confusion.
All three tools follow a consistent snake_case verb_noun pattern: register_filter, run_filter, convert_file. The naming is predictable and easy to scan.
Three tools cover the minimal register/run/persist workflow for a custom filter service. The set is tightly scoped, and no tool feels redundant or out of place.
Core lifecycle operations are present: register a filter, execute it read-only, and execute it with file persistence. Missing list/delete/get-filter operations are minor gaps, partly mitigated by server-side TTL, but an agent cannot explicitly inspect or revoke filters.