Tecton's Co-Pilot состоит из MCP Server и правил Cursor. Прочтите этот блог , чтобы узнать больше.
ℹ️ Информация : Это руководство поможет вам настроить сервер Tecton MCP с этим репозиторием и настроить репозиторий функций для его использования при разработке функций с помощью Tecton.
Related MCP server: tecton-mcp
Клонируйте этот репозиторий на свой локальный компьютер:
git clone https://github.com/tecton-ai/tecton-mcp.git
cd tecton-mcp
pwdПримечание: Путь к каталогу, в который вы только что клонировали репозиторий, в следующих шагах будет называться <path-to-your-local-clone> . Команда pwd в конце сообщит вам полный путь.
Установите менеджер пакетов uv:
brew install uvПроверьте установку, выполнив следующую команду. Замените <path-to-your-local-clone> на путь, по которому вы клонировали репозиторий на шаге 1:
MCP_SMOKE_TEST=1 uv --directory <path-to-your-local-clone> run mcp run src/tecton_mcp/mcp_server/server.pyКоманда должна завершиться без ошибок и вывести сообщение, похожее на MCP_SMOKE_TEST is set. Exiting after initialization. . Это подтверждает, что ваша локальная настройка работает правильно — Cursor автоматически создаст сервер MCP как подпроцесс при необходимости.
Настройте Cursor (или любой другой клиент MCP) с сервером MCP (см. ниже)
Войдите в свой кластер Tecton:
tecton login yourcluster.tecton.aiЗапустите Cursor и начните разрабатывать функции с помощью Tecton Co-Pilot в Cursor!
Сервер Tecton MCP предоставляет следующие инструменты, которые может использовать клиент MCP (например, Cursor):
Название инструмента | Описание |
| Находит соответствующие примеры кода Tecton с использованием векторной базы данных. Полезно для поиска шаблонов использования перед написанием нового кода Tecton. |
| Извлекает фрагменты документации Tecton на основе запроса. Предоставляет контекст непосредственно из официальной документации Tecton. |
| Извлекает полную справку Tecton SDK, включая все доступные классы и функции. Используйте, когда необходим широкий обзор SDK. |
| Извлекает ссылку на Tecton SDK для указанного списка классов или функций. Идеально подходит для целевой информации о конкретных компонентах SDK. |
Tecton MCP интегрируется с редакторами на базе LLM, такими как Cursor, для предоставления контекста на основе инструментов и помощи в проектировании функций:
Общий процесс создания объектов с помощью Tecton MCP выглядит следующим образом:
Следующее протестировано с Cursor 0.48 и выше
Перейдите в Cursor Settings -> MCP и нажмите кнопку "Add new global MCP server", которая отредактирует файл mcp.json Cursor. Добавьте Tecton в качестве сервера MCP. Вы можете использовать следующую конфигурацию в качестве отправной точки - убедитесь, что вы изменили путь <path-to-your-local-clone> , чтобы он соответствовал каталогу, в который вы клонировали репозиторий:
{
"mcpServers": {
"tecton": {
"command": "uv",
"args": [
"--directory",
"<path-to-your-local-clone>",
"run",
"mcp",
"run",
"src/tecton_mcp/mcp_server/server.py"
]
}
}
}Скопируйте cursorrules из папки .cursor/rules этого репозитория в папку .cursor/rules вашего репозитория функций :
# Create the .cursor/rules directory structure in your feature repository
mkdir -p <path-to-your-feature-repo>/.cursor/rules
# Then copy the rules
cp -r <path-to-your-local-clone>/.cursor/rules/* <path-to-your-feature-repo>/.cursor/rules/Войдите в свой кластер Tecton:
tecton login yourcluster.tecton.aiПо состоянию на 17 апреля ниже представлен ранжированный по стеку список наиболее успешных LLM-программистов Tecton по проектированию объектов в Cursor:
OpenAI o3
Gemini 2.5 pro exp (03-25)
Сонет 3.7
Чтобы убедиться, что ваша интеграция работает так, как и ожидалось, задайте агенту курсора вопрос, подобный следующему, и убедитесь, что он правильно вызывает ваши инструменты Tecton MCP:
Запросите Индекс примеров Tecton и расскажите мне что-нибудь о BatchFeatureViews и чем они отличаются от StreamFeatureViews. Также посмотрите Справочник SDK.
Теперь вы можете перейти в репозиторий функций в Cursor и начать использовать Co-Pilot от Tecton, напрямую интегрированный в Cursor.
Посмотрите этот Loom, чтобы узнать, как можно использовать интеграцию для создания новых функций: https://www.loom.com/share/3658f665668a41d2b0ea2355b433c616
По умолчанию этот инструмент предоставляет руководство для последней предварительной версии Tecton SDK. Если вам нужны инструменты для соответствия определенной выпущенной версии Tecton (например, 1.0.34 или 1.1.10 ), выполните следующие действия:
Закрепить версию в pyproject.toml . Откройте pyproject.toml и замените существующую строку зависимости
dependencies = [
# ... other dependencies ...
"tecton>=0.8.0a0"
]с точной версией, которую вы хотите, например
dependencies = [
# ... other dependencies ...
"tecton==1.1.10"
]Удалите существующий файл блокировки. Поскольку uv.lock записывает график зависимости, вы должны удалить его, чтобы uv мог разрешить новую версию Tecton:
cd <path-to-your-local-clone>
rm uv.lockПовторно сгенерируйте файл блокировки , повторно выполнив шаг 3 (команда MCP_SMOKE_TEST=1 uv --directory ) раздела «Быстрый старт» . (Это загрузит закрепленную версию в изолированную среду для MCP и заново создаст uv.lock .)
Перезапустите Cursor, чтобы новая версия Tecton загрузилась в виртуальную среду MCP.
Поддерживаемые версии: В настоящее время инструменты поддерживают Tecton ≥ 1.0.0. Примеры кода пока не версионированы – они всегда используют последнюю стабильную версию SDK – однако документация и индексы ссылок SDK теперь будут соответствовать версии, которую вы закрепили.
Убедитесь, что Cursor показывает "tecton" как "Enabled" MCP server в "Cursor Settings -> MCP". Если вы не видите "зеленую точку", запустите MCP server в режиме диагностики (см. ниже)
Для отладки сервера Tecton MCP можно выполнить следующую команду. Замените <path-to-your-local-clone> фактическим путем, по которому вы клонировали репозиторий:
uv --directory <path-to-your-local-clone> run mcp dev src/tecton_mcp/mcp_server/server.pyПримечание: запуск сервера MCP Tecton займет несколько секунд, поскольку он загружает в память модель внедрения, которую он использует для поиска соответствующих фрагментов кода.
Подождите несколько секунд, пока stdout не сообщит вам, что MCP Inspector запущен и работает, а затем откройте его по указанному URL-адресу (что-то вроде http://localhost:5173 ).
Нажмите «Подключиться», а затем отобразите список инструментов. Вы должны увидеть инструменты Tecton MCP Server и иметь возможность запрашивать их.
Данный проект лицензирован в соответствии с лицензией MIT .
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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral disclosure burden. 'Fetches' implies a read operation and 'full SDK reference' indicates scope, but the description does not mention possible response size, structure, or any access requirements. This is acceptable but leaves gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences each serve a purpose: what the tool does, when to use it, and when to use the alternative instead. There is minimal redundancy and the main point is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-argument fetch-all tool, the description clearly states the use case and directs subset users to the right sibling. It would be slightly more complete if it noted the likely size or format of the returned reference, but nothing critical is missing for invocation decisions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, so there is nothing for the schema or description to explain about arguments. The description adds useful contextual scope by contrasting full and subset behavior, matching the baseline for zero-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource ('Fetches the full Tecton SDK reference') and clarifies the scope as 'all classes/functions.' It differentiates from the sibling query tool by explicitly contrasting full versus subset access.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says 'Use this only if you need to get the full SDK reference' and names the alternative for subset use, giving an agent a clear decision rule.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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."
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explains that the tool retrieves and formats documentation snippets, enumerates the exact output fields, and instructs the agent to tell the user which documentation URL to open. It does not cover edge cases such as no matches found, but the core behavior is clear and accurate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description front-loads the core behavior and output format before moving to user-facing instructions and examples. The list of examples is long but earns its place by serving as parameter guidance; there is no filler or redundant wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema and annotations, the description covers what the tool returns, how the agent should present the result, and how to phrase queries. The main gap is the lack of explicit guidance for choosing between this tool and its siblings, which is already reflected in the usage guidelines score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no description for the 'query' parameter, so the description must compensate. It does so through a detailed 'Input query examples' section that illustrates the expected natural-language phrasing. For a single parameter, this gives an agent sufficient understanding of what to pass, even though explicit constraints like length or format are not stated.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verbs ('Retrieves and formats') and clearly names the resource ('Tecton documentation snippets'). It also describes exactly what each snippet contains (Source URL, section header, relevant text chunk), which makes the tool's function unambiguous and distinguishable from sibling code-example and SDK-reference tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides ten concrete input query examples that establish when the tool is appropriate, such as 'How do I unit test a Feature View?' and 'Explain Batch Feature Views.' It gives clear context on the kind of natural-language documentation questions to use, but it does not explicitly name alternatives or state when not to use this tool versus its siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the disclosure burden, and it does disclose the retrieval mechanism ('vector database'), the output form ('collection of python code examples'), and the ranking ('ranked by relevance'). It could add failure or freshness caveats, but for a simple retrieval tool the core behavior is transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The main description is front-loaded and the output format is stated in one sentence. The 13 examples are long but earn their place because the schema provides no query guidance; little in the text is redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter retrieval tool with no output schema, the description covers what to send and what will come back. It lacks only edge-case behavior (e.g., empty results or non-Tecton queries), which is minor for this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema gives only a bare 'query' string with no description (0% coverage), so the list of 13 concrete query examples is essential and largely compensates. It shows the expected phrasing and scope of queries, though it does not state an explicit 'describe the Tecton construct you need examples of' rule.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The opening sentence uses a specific verb ('Finds'), a specific resource ('relevant Tecton code examples'), and a mechanism ('vector database'). Paired with sibling names like query_documentation_index_tool, this clearly marks the tool as the code-example retriever rather than a docs or SDK reference lookup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives an explicit condition: query the examples retriever before generating Tecton code. It does not explicitly name when to prefer documentation or SDK-reference siblings, so it stops short of full when-to-use/when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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: Aggregate, AggregationFunction, AggregationLeadingEdge, Array, Attribute, AutoscalingConfig, BatchFeatureView, BatchSource, BatchTriggerType, BigQueryConfig, BigtableConfig, CacheConfig, Calculation, ComputeMode, DataFrame, DataSource, DatabricksClusterConfig, DatabricksJsonClusterConfig, Dataset, DatetimePartitionColumn, DeltaConfig, DynamoConfig, EMRClusterConfig, EMRJsonClusterConfig, Embedding, Entity, FeatureServerGroup, FeatureService, FeatureTable, FeatureVector, FeatureView, Field, FileConfig, FilterContext, HiveConfig, IcebergConfig, KafkaConfig, KafkaOutputStream, KinesisConfig, KinesisOutputStream, LifetimeWindow, Map, MockContext, ModelConfig, OfflineStoreConfig, OnlineServingIndex, PandasBatchConfig, ParquetConfig, ProvisionedScalingConfig, PushConfig, PyArrowBatchConfig, RealtimeContext, RealtimeFeatureView, RedisConfig, RedshiftConfig, RequestSource, RiftBatchConfig, SdkDataType, Secret, SnowflakeConfig, SparkBatchConfig, SparkStreamConfig, StreamFeatureView, StreamProcessingMode, StreamSource, Struct, TectonDataFrame, TectonTimeConstant, TestRepo, TimeWindow, TimeWindowSeries, TransformServerGroup, Transformation, UnityCatalogAccessMode, UnityConfig, Workspace, approx_count_distinct, approx_percentile, batch_feature_view, const, first, first_distinct, last, last_distinct, materialization_context, pandas_batch_config, pyarrow_batch_config, realtime_feature_view, spark_batch_config, spark_stream_config, stream_feature_view, transformation
| Name | Required | Description | Default |
|---|---|---|---|
| class_names | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full burden, and it does this well. It warns that invalid names will 'result in an error or empty output,' and it details exactly what the returned output will include: a bulleted list, type, name, import path, definition header, and full docstring. This makes the tool's behavior predictable to an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The prose is concise and well-structured, with the critical constraint front-loaded and output format clearly sectioned. The description is long because of the extensive allowed classes/functions list, but that list is necessary to prevent invalid calls, so the length is justified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Since there is no output schema, the description appropriately documents the return structure, including details like import path and definition header. It also handles the main failure mode. However, it does not provide any guidance about close alternatives or mention the full-reference sibling, which would have made the context complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides only the parameter name and type, with 0% schema description coverage, so the description must fully explain class_names. It does, by requiring names to come from the provided 'Available classes/functions' list and by describing the consequence of violating that constraint. The exhaustive allowed-value list adds substantial semantic meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Fetches the Tecton SDK reference for a specific list of classes/functions.' This clearly distinguishes it from the sibling get_full_tecton_sdk_reference_tool, since this tool is scoped to a provided list rather than returning the entire reference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use it: 'Use this tool when you need information about specific Tecton components from the allowed list.' It does not explicitly mention when not to use it or name alternatives like query_documentation_index_tool, so it stops short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0get_full_tecton_sdk_reference_toolquery_documentation_index_toolquery_example_code_snippet_index_toolquery_tecton_sdk_reference_toolEach tool targets a distinct retrieval source: code examples, documentation snippets, full SDK reference, and targeted SDK reference lookups. Even the two SDK tools are clearly separated by full vs. specific class/function queries.
Most tools follow a query_<target>_tool pattern, but get_full_tecton_sdk_reference_tool switches from query_ to get_. The names are still readable and predictable overall.
Four tools is a well-scoped set for a documentation/example retrieval server. Each tool has a clear purpose and none are redundant.
The tool surface covers the main knowledge needs for Tecton development: code examples, documentation, and SDK reference, with both full and targeted retrieval options. No significant gaps are apparent.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Read and write Mission Control state via MCP — projects, tasks, subtasks, templates, status updates.
Tailscale device, route, DNS, key, user, and ACL management over MCP and CLI.
Manage CloudPepper servers, Odoo instances, backups, and deployments over MCP.
Manage Jitsu data pipelines: destinations, streams, connections, functions, live events.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/tecton-ai/tecton-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
