Tenzir MCP Server
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": true
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| make_ocsf_mappingA | Add OCSF mapping to a TQL parsing pipeline. Use this tool when:
Follow the workflow instructions provided in the response. |
| make_parserA | Generate a TQL parser for the given log format. Use this tool when:
This tool provides a complete workflow with step-by-step instructions for:
Follow the workflow instructions provided in the response. |
| docs_readA | Read documentation content from the embedded Tenzir documentation. Use this tool to:
|
| docs_searchA | Search documentation by keyword or retrieve specific paths with 'See Also' expansion. Use this tool to:
The depth parameter traverses cross-references, helping you discover operators and functions you might not have known about. |
| run_pipelineA | Execute a TQL pipeline through the local Use this tool to:
The pipeline runs with diagnostics enabled, providing detailed error messages and warnings to help troubleshoot issues. |
| run_testA | Run tests for TQL pipelines using the tenzir-test framework. Use this tool to:
Tests can include fixtures like embedded Tenzir nodes for integration testing.
The |
| ocsf_get_classA | Get the complete definition of a specific OCSF event class including all fields and metadata. Use this tool to:
This returns the complete class definition including all attributes, types, and constraints needed to create accurate OCSF mappings. |
| ocsf_get_classesA | Get all OCSF event classes and their descriptions for a specific schema version. Use this tool to:
Once you identify a candidate class, use |
| ocsf_get_versionsA | List all bundled OCSF schema versions. Use this tool to:
Typically you'll want to use |
| ocsf_get_latest_versionA | Return the latest stable OCSF schema version. Use this tool to:
This filters out development versions (alpha, beta, rc) and returns only stable releases. |
| ocsf_get_objectA | Get the complete definition of an OCSF object type including all fields and metadata. Use this tool to:
Objects are reusable components within OCSF event classes, defining standard structures like endpoints, files, processes, etc. |
| package_add_changelogA | Add a changelog entry to a package. Use this tool to:
Changelog entries are timestamped and categorized. They help users understand what changed between package versions. |
| package_add_operatorA | Add a user-defined operator (UDO) to a package. Use this tool to:
Operators become available as package_id::operator_name in TQL pipelines after the package is installed. |
| package_add_testA | Add a test to a package. Use this tool to:
Tests use the tenzir-test framework. Provide input/output when known,
or omit output and use the |
| package_createA | Create a new Tenzir package scaffold. Use this tool to:
This creates the foundation for building custom TQL operators, parsers,
and OCSF mappings. After creation, use |
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 15 tools
Every tool has a distinct purpose: parsing, mapping, documentation lookup, pipeline execution, testing, OCSF schema access, and package management. The five ocsf_get_* tools are clearly differentiated by what they retrieve (classes, class, object, versions, latest version), and the docs_* and package_* tools have non-overlapping roles.
All tool names follow a consistent verb_noun pattern in snake_case: make_parser, make_ocsf_mapping, docs_read, docs_search, run_pipeline, run_test, ocsf_get_class, package_create, etc. Domain prefixes (docs_, ocsf_, package_) are used uniformly, making the naming predictable and easy to navigate.
15 tools is well within the ideal 3-15 range and matches the server's broad scope of documentation, OCSF schema exploration, package scaffolding, pipeline execution, and testing. Each tool earns its place without redundancy or bloat.
The tool set covers the full development lifecycle: create a package, add operators, tests, and changelogs, parse and map data, run pipelines, run tests, and consult documentation. Minor gaps exist for package management operations like listing or deleting existing components, and there is no tool to edit an existing operator directly, but these are not dead ends for the main workflow.