[private preview] Tecton MCP - Model Context Protocol server for Tecton feature platform, providing tools for feature engineering, API reference, documentation, and metrics
The Tecton MCP server exposes 6 tools with mixed quality. Tool naming follows verb_noun conventions and is generally clear (query_*, get_*). However, critical gaps exist: 3 of 6 tools have input schemas that include only a generic 'ctx' parameter with minimal description, and parameter documentation is sparse. Description quality varies, some tools (query_example_code_snippet_index_tool, query_documentation_index_tool, query_tecton_metrics_tool) have detailed, multi-line descriptions with examples, while others (get_full_tecton_sdk_reference_tool, dynamic FeatureService tools) lack sufficient detail. No output schemas are documented. Error handling and recovery guidance are absent from descriptions. No evidence of input validation or security patterns (secrets, permission gates, audit trails).
Fetches the full Tecton SDK reference. Use this only if you need to get the full SDK reference for all classes/functions. If you care only about a subset, use the `query_tecton_sdk_reference_tool` tool instead.
Retrieves and formats Tecton documentation snippets based on a query. Each snippet includes the TECTON DOCUMENTATION URL (Source URL), the section header, and the relevant text chunk. Tell the user what documentation URL they can open up to get more information. Input query examples: - "How do I unit test a Feature View?" - "What are Entities in Tecton?" - "Explain Batch Feature Views." - "How to connect to a Kafka data source?" - "Show me how to construct training data." - "Tutorial for building realtime features." - "How does `tecton apply` work?" - "Information about Tecton data types." - "What is a Feature Service?" - "Scaling the online feature server." - "Monitoring materialization jobs."
Finds relevant Tecton code examples using a vector database. It is always helpful to query the examples retriever before generating Tecton code. Input query examples: - "examples of an Entity" - "examples of a KinesisConfig" - "examples of a KafkaConfig" - "examples of a batch feature view" - "examples of a count distinct aggregation feature view" - "examples of a percentile aggregation feature view" - "examples of a stream feature view" - "examples of an aggregation stream feature view" - "examples of a realtime feature view" - "examples of a realtime feature view that transforms data from another feature view" - "examples of a fraud feature" - "examples of a recsys case" - "examples of a test" The output will be a collection of python code examples that use Tecton to implement features, ranked by relevance.
Dynamic FeatureService tool registration lacks explicit visibility in source code. Tool name is templated ({fs_name}_tool), description and schema are dynamically generated from metadata. Schema shows only 'join_keys' and 'request_context' as generic objects without detailed field descriptions.
All tools include a generic 'ctx' parameter (type: object, description: 'MCP context object') with no explanation of what fields it contains or why the LLM needs to provide it. This violates parameter description requirements.
No output schemas documented for any tool. LLMs cannot predict the structure of results or plan downstream calls. For instance, query_example_code_snippet_index_tool returns 'a collection of python code examples', but exact fields (e.g., code, file_path, relevance_score, url) are not specified.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 58 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 42 | - | v1 |
Query current Tecton metrics from the observability endpoint. This tool fetches point-in-time metrics from Tecton's Prometheus-compatible scrape endpoint. It returns current system state, not historical data. Args: metric_filter: Optional regex pattern to filter metrics (e.g., "tecton_feature_store.*") output_format: "raw" for OpenMetrics format, "formatted" for human-readable Returns: String containing the current metrics data Examples: - Get all current metrics: query_tecton_metrics_tool() - Get only feature store metrics: query_tecton_metrics_tool(metric_filter="tecton_feature_store.*") - Get materialization metrics: query_tecton_metrics_tool(metric_filter="tecton_materialization.*") - Get raw OpenMetrics format: query_tecton_metrics_tool(output_format="raw")
Fetches the Tecton SDK reference for a specific list of classes/functions. **IMPORTANT:** The `class_names` list **MUST** only contain names from the 'Available classes/functions' list below. Providing any names *not* in this list will result in an error or empty output. Use this tool when you need information about specific Tecton components from the allowed list. Output Format: - Starts with a bulleted list of the found public classes/functions matching the query. - Followed by details for each item, including: - Type (Class/Function) - Name - Recommended import path (e.g., `tecton` or `tecton.types`) - The definition header (e.g., `class FeatureView(...)` or `def batch_feature_view(...)`) - The full docstring. Available classes/functions: [dynamically generated from SDK definitions]
Call FeatureService {fs_name}. Description dynamically generated from feature service metadata. Features list dynamically generated from feature service features.
get_full_tecton_sdk_reference_tool has a minimal description ('Fetches the full Tecton SDK reference. Use this only if...') that is only ~100 chars. It does not explain what 'full' means, the expected size/token cost, or how results differ from the query variant. Insufficient for LLM tool selection.
No error handling guidance in tool descriptions. If query_tecton_sdk_reference_tool receives a class name not in the 'Available classes/functions' list, the tool states it will error, but provides no recovery hint (e.g., 'Try query_full_tecton_sdk_reference_tool to discover valid names').
No evidence of input validation or security patterns. No mention of secret injection, permission gates, scope declarations, or audit trails. Tools accept user input (queries, metric filters) but no validation strategy is visible.
query_tecton_metrics_tool accepts output_format enum with values 'raw' and 'formatted', but no output schema shows what fields/structure each format returns. LLMs cannot adapt based on the format chosen.