Loading ToolBench
MCP server for interacting with Tecton feature platform, providing tools to query workspaces, feature views, feature services, transformations, and execute Tecton CLI commands
The server defines 9 tools with basic descriptions and some parameter schemas, but falls short of production-grade quality across multiple dimensions. Tool names follow verb-noun convention (list_, get_, tecton_cli_), which is good. However, descriptions are sparse and generic for several tools (avg ~80 chars, well below the 194-char production baseline). Parameter descriptions are almost entirely missing, most tools have parameters with no explanation of what they control or expected formats. Output schemas are not documented; many tools return dicts/lists with undocumented fields (e.g., list_feature_views returns 'tags': dict(...) without explaining what tags contain or how the LLM should use them). Error handling is minimal, most functions catch exceptions and call _err() but provide no recovery guidance. The two CLI tools (tecton_cli_help, tecton_cli_execute) present a security anti-pattern by exposing command execution without constraints.
Get the entire definition of a feature service from the Tecton cluster.
Get the code definition of a feature view from the Tecton cluster. This essentially gets the transformation using the feature view name and assumes its the same name as transformation name which works in most cases.
Get the entire definition of a feature view from the Tecton cluster.
List all feature services in the currently connected tecton cluster
List all feature views in the currently connected tecton cluster
List all transformations in the currently connected tecton cluster
Output schemas are not documented. Tools like list_feature_views return complex dicts with fields 'name', 'description', 'workspace', 'tags', but LLMs cannot infer field semantics or types from code inspection. The docstring only says 'A list of dictionaries containing name, description, workspace, and tags' without specifying types or what 'tags' actually contains (dict of strings? nested structure?).
Parameter descriptions are missing or trivial for all tools. The 'command' parameter in tecton_cli_execute has no description of valid syntax, required format, or examples. The 'name' and 'workspace' parameters in get_feature_service_configuration have minimal descriptions ('The name of the feature service to retrieve') but no guidance on valid values, required format, or what to do if the name doesn't exist.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 47 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 42 | - | v1 |
List all workspaces in the currently connected Tecton cluster.
Execute a tecton cli command Use the tecton_cli_help tool to figure out which commands you have at your disposal
Query the tecton CLI to get a structured representation of all available commands and their options. Can be used to explore the CLI's functionality, including commands for checking user identity, managing workspaces, and cluster connectivity.
The tecton_cli_execute tool exposes raw command-line execution without input validation or constraints. An LLM could pass any tecton CLI command, including destructive operations (delete, drop). This violates the principle of constrained input and presents a security risk. No error messages guide recovery, a failed command just returns stderr.
Error handling is minimal and non-actionable. Most tools catch exceptions and return _err(message) without categorizing errors as retryable, user-fixable, or fatal. For example, if get_feature_service_configuration fails, there is no guidance: 'Try list_feature_services() first to verify the name exists' or 'Check that you are connected to the correct workspace'.
get_feature_view_code docstring acknowledges a limitation ('assumes its the same name as transformation name which works in most cases') but does not expose an alternative tool or parameter to handle the case where the transformation name differs from the feature view name.
No pagination support. list_feature_views, list_feature_services, and list_transformations return unbounded lists. If a Tecton workspace contains thousands of feature views, the response could exhaust context windows or hit timeout limits. Baseline pattern requires page/offset + limit parameters and result counts.
Tools return raw API responses with minimal stripping. list_feature_views returns 'tags': dict(...) which could be arbitrarily large; get_feature_service_configuration and get_feature_view_configuration likely return verbose metadata. No documentation of what fields are included or what the LLM should extract. This wastes tokens and risks context explosion.