TectonのCo-Pilotは、MCPサーバーとカーソルルールで構成されています。詳細については、こちらのブログをご覧ください。
ℹ️情報: このガイドでは、このリポジトリを使用して 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 サーバーをサブプロセスとして自動的に生成します。
MCP サーバーで Cursor (またはその他の MCP クライアント) を設定します (以下を参照)
Tecton クラスターにログインします。
tecton login yourcluster.tecton.aiCursor を起動し、Cursor で Tecton の Co-Pilot を使用して機能の開発を始めましょう。
Tecton MCP サーバーは、MCP クライアント (Cursor など) で使用できる次のツールを公開します。
ツール名 | 説明 |
| ベクターデータベースを使用して、関連するTectonコード例を検索します。新しいTectonコードを書く前に使用パターンを見つけるのに役立ちます。 |
| クエリに基づいてTectonドキュメントのスニペットを取得します。Tectonの公式ドキュメントから直接コンテキストを提供します。 |
| 利用可能なすべてのクラスと関数を含む、完全なTecton SDKリファレンスを取得します。SDKの概要を把握したい場合にご利用ください。 |
| 指定されたクラスまたは関数のリストのTecton SDKリファレンスを取得します。特定のSDKコンポーネントに関する情報を取得するのに最適です。 |
Tecton MCP は、Cursor などの LLM 対応エディターと統合して、ツールベースのコンテキストと機能エンジニアリングの支援を提供します。
Tecton MCP を使用して機能を構築するための全体的なフローは次のようになります。
以下はCursor 0.48以上でテストされています
カーソル設定 -> MCP に移動し、「新しいグローバル MCP サーバーを追加」ボタンをクリックすると、カーソルのmcp.jsonファイルが編集されます。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"
]
}
}
}このリポジトリの.cursor/rulesフォルダから cursorrules を機能リポジトリの.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.ai4 月 17 日現在、Cursor で最高のパフォーマンスを発揮した Tecton 機能エンジニアリング LLM のスタック ランク リストは次のとおりです。
オープンAI o3
ジェミニ 2.5 プロ エクスペディション (03-25)
ソネット3.7
統合が期待どおりに機能することを確認するには、カーソル エージェントに次のような質問をして、Tecton MCP ツールが適切に呼び出されていることを確認します。
TectonのExamples IndexでBatchFeatureViewsについて、またStreamFeatureViewsとの違いについて教えてください。SDKリファレンスもご覧ください。
これで、Cursor の機能リポジトリにアクセスし、Cursor に直接統合された Tecton の Co-Pilot を使い始めることができます。
統合を使用して新しい機能を構築する方法については、この Loom をご覧ください: https://www.loom.com/share/3658f665668a41d2b0ea2355b433c616
このツール1.1.10デフォルトで、Tecton SDKの最新のプレリリース版に関するガイダンスを提供します。特定のリリース版Tecton（例： 1.0.34 ）に合わせてツールを調整する必要がある場合は、以下の手順に従ってください。
pyproject.tomlpyproject.tomlバージョンを固定します。pyproject.tomlを開き、既存の依存関係の行を置き換えます。
dependencies = [
# ... other dependencies ...
"tecton>=0.8.0a0"
]必要なバージョンを正確に入力してください。例:
dependencies = [
# ... other dependencies ...
"tecton==1.1.10"
]既存のロックファイルを削除します。uv.lock uv.lock依存関係グラフを記録するため、 uv新しい Tecton バージョンを解決できるように、これを削除する必要があります。
cd <path-to-your-local-clone>
rm uv.lockクイックスタートセクションのステップ3 （ MCP_SMOKE_TEST=1 uv --directoryコマンド）を再実行して、ロックファイルを再生成します。（これにより、固定バージョンがMCP用の分離された環境にダウンロードされ、 uv.lockが再作成されます。）
新しい Tecton バージョンが MCP 仮想環境にロードされるように、Cursorを再起動します。
サポートされているバージョン:ツールは現在、Tecton 1.0.0 以上をサポートしています。コードサンプルはまだバージョン管理されていません。常に最新の安定したSDKを使用していますが、ドキュメントとSDKリファレンスのインデックスは、ピン留めしたバージョンと一致するようになります。
「カーソル設定 -> MCP」で、カーソルに「tecton」が「有効」なMCPサーバーとして表示されていることを確認してください。「緑のドット」が表示されない場合は、MCPサーバーを診断モードで実行してください（下記参照）。
Tecton MCPサーバーをデバッグするには、次のコマンドを実行します。 <path-to-your-local-clone> 、リポジトリをクローンした実際のパスに置き換えてください。
uv --directory <path-to-your-local-clone> run mcp dev src/tecton_mcp/mcp_server/server.py注: Tecton の MCP サーバーの起動には数秒かかります。これは、関連するコード スニペットの検索に使用する埋め込みモデルをメモリに読み込むためです。
MCP インスペクタが起動して実行中であることが標準出力に表示されるまで数秒待ってから、出力された 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.
v0.1.0get_full_tecton_sdk_reference_toolquery_documentation_index_toolquery_example_code_snippet_index_toolquery_tecton_sdk_reference_toolScored across 4 tools
Each 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.
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.
