mcpField
U
Uiuc Airfoils

Uiuc Airfoils

リモート
pipeworx.io科学・教育01 週間前に更新
リポジトリ公式サイト

Uiuc Airfoils について

Uiuc Airfoils は、空力研究や設計向けに UIUC データベースの翼型座標を検索できるようにします。リクエストごとに座標を取得し、最大厚さと最大キャンバーを算出します。

主な機能

  1. 01翼型名または系列で検索
  2. 02座標ファイルを都度取得
  3. 03最大厚さとキャンバーを算出
  4. 04翼面座標の任意取得

活用シーン

  1. 01系列や設計者から翼型を検索
  2. 02翼型の座標形状を確認
  3. 03最大厚さとキャンバーを比較

MCP 対応

`uiuc_airfoil_search` と `uiuc_airfoil_geometry` を提供する MCP サーバーです。stdio でローカル実行するか、Pipeworx ゲートウェイ経由で接続できます。

設定

リモートサーバーはインストール不要です。クライアントを選んで設定をコピーするか、ワンクリックで導入できます。

エンドポイントhttps://gateway.pipeworx.io/uiuc-airfoils/mcp
インストールコマンドをコピー
Claude CodeTerminal
Cursor.cursor/mcp.json
VS Code.vscode/mcp.json
Claude Desktopclaude_desktop_config.json
Windsurf~/.codeium/windsurf/mcp_config.json

コマンドはターミナルで実行し、JSON は各クライアントの MCP 設定に貼り付けて再起動します。認可が必要なサーバーは初回接続時にログインを求めます。

ツール

詳細

@pipeworx/uiuc-airfoils

約1,600種類の翼型の形状座標(NACA、Eppler、Selig、Wortmann、Goettingen、Drela AG、Clark Y、Wright Brothers、および設計者名が付けられたその他の翼型)を、名称または系列で検索できます。最大厚みと最大キャンバーは、元の座標からリアルタイムで算出されます。

Pipeworx の一部です。Pipeworx は、AI エージェントを1,851以上の稼働中データソースに接続する MCP ゲートウェイです。これは独立した非公式の連携であり、上流のプロバイダーとは提携、承認、公開のいずれもしていません。

ツール

  • uiuc_airfoil_search(query?, family?, limit?) — 名称、キーワード、または正確な系列(例:"naca"、"eppler"、"goe"、"2412"、family: "Wortmann")で検索します。フィルターを指定しない場合は、カタログの総数と既知の系列一覧を返します。常に一致件数を最初に返し、一致するものがない場合は、試したフィルターを示します。
  • uiuc_airfoil_geometry(name, include_coordinates?) — 1種類の翼型の座標ファイルをその場で取得し、点の数、座標形式、最大厚み、最大キャンバー(いずれも翼弦長に対する割合と、その値が発生する翼弦方向位置)、および算出方法を返します。生の上面・下面の点配列も取得するには、include_coordinates: true を指定します。

認証

キー不要です。

データソース

  • University of Illinois Urbana-Champaign, Applied Aerodynamics Group、UIUC Airfoil Coordinates Database — 翼型の形状座標と1行の説明。ここにはルートやファイル名を記載していません。ルートについては src/index.ts と scripts/bake-index.mjs を参照してください。CLAUDE.md のステップ9bに従い、公開用の文章には記載しません。

ライセンス — ビルド前に確認し、不明な点は問題として明示

コードを書く前に、データベースの一覧ページ、その親ページ、サイトの robots.txt(404で、こちらにも制限の記載はありません)を確認し、明記されたライセンスまたは再配布ポリシーがないことを確認しました。どちらもありません。サイト内で著作権に関連する唯一の記載は、サイト共通の一般的なフッター(「© 1994 - 2026 UIUC Applied Aerodynamics Group」)であり、座標データ自体に対する許諾や禁止事項は併記されていません。

恒常ルールに従い(リクエストごとに公開されているキー不要の上流サービスをプロキシする場合は明示的な許諾は不要、データセットの同梱は再配布にあたり許諾が必要、利用条件が明記されていない場合は保留せずビルドしてその旨を明示):

  • 実際の座標の値は同梱しません。uiuc_airfoil_geometry は呼び出しごとに、毎回、各翼型の .dat ファイルをその場で取得します。ファイル1つをリクエストごとにそのままプロキシします。
  • uiuc_airfoil_search は、名称、1行の説明、および大まかな系列分類をまとめた小規模な同梱テーブル(src/uiuc-index-data.ts、約1,587行。scripts/bake-index.mjs で再生成)を読み込みます。座標は含みません。この部分は明示的な許諾ではなく、ルールの「利用条件が明記されていない場合はビルドしてその旨を明示」という方針に基づいています。
  • 次にレビューする方への注意: UIUC が座標データの再配布に関する明示的な条件を公開した場合、この名称・説明・系列のインデックスでさえ、その条件に適合するか再確認してください。

座標形式と厚さ/キャンバーの算出方法

UIUC の .dat ファイルには 2 種類のレイアウトがあり、どちらも src/index.ts のパーサーで処理されます。

  • Selig 形式 — 1 つの連続した点のループです。後縁の上面から始まり、 前縁まで進んだ後、下面に沿って後縁まで戻ります。ヘッダーに個数の記載はありません。パーサーは ループを最小の x 値を持つ点(前縁)で分割します。
  • Lednicer 形式 — (upperCount, lowerCount) を示すヘッダー行の後に、 前縁から後縁までの上面が続き、空行を挟んで、 前縁から後縁までの下面が続きます。

形式はファイルごとに検出されます(Lednicer ヘッダーは最初のデータ行にある 2 つの小さな整数らしい値で判別します。それ以外は Selig として扱います)。 上面と下面をそれぞれ upper(x) と lower(x) に分割した後、どちらも コード長全体を覆う共通の 101 点のコサイン間隔グリッド(x は 0..1 — UIUC の座標はすでにコード長で正規化されています)に線形補間されます。このグリッドから次を求めます。

  • thickness(x) = upper(x) - lower(x)
  • camber(x) = (upper(x) + lower(x)) / 2

最大厚さと最大(符号付き)キャンバーは、このグリッド上の最大値です。 コード長に対する割合と、その値が生じる x の位置とともに報告されます — NACA 独自の 4 桁命名規則と同じ慣習です。NACA 2412 自体で検証済みです。このツールは コード長の 30% の位置で最大厚さ 12.0%、コード長の約 40% の位置で最大キャンバー 2.0% を返します。これは「2-4-12」の意味(コード長の 40% の位置でキャンバー 2%、厚さ 12%)と一致し、NACA 4 桁系列で最大厚さが コード長の 30% の位置にくるよう設計されていることとも完全に一致します — 偶然ではなく、正しさを強く裏付ける検証結果です。

既知の制限

  • ファミリー分類は、ファイル名や説明に対する大まかなヒューリスティック (scripts/bake-index.mjs のキーワード規則)であり、UIUC 自身が公開している 権威ある分類体系ではありません。既知の設計者名やシリーズ名のキーワードに一致しない翼型は "Other" に分類されます(現在はカタログの約 1/3)。これは想定どおりで、バグではありません。
  • サイト上の一部の .dat ファイルでは、標準外の空白や末尾の注釈が使われており、 パーサーで解釈できません。その場合、uiuc_airfoil_geometry は 推測した数値ではなく、生の解析失敗情報とともに geometry_error を返します。
  • 焼き込み済みの名前インデックスは、scripts/bake-index.mjs を手動で再実行した場合にのみ更新されます (UIUC は「Update Directory」セクションを通じて、1〜2 年ごとに翼型をいくつか追加します) — 現時点では自動更新の方法はありません。

クイックスタート

MCP クライアント(Claude Desktop、Cursor、Windsurf など)に追加します。

{
  "mcpServers": {
    "uiuc-airfoils": {
      "url": "https://gateway.pipeworx.io/uiuc-airfoils/mcp"
    }
  }
}
このエンドポイントが実際に提供するもの

https://gateway.pipeworx.io/uiuc-airfoils/mcp の tools/list は、上の表にあるツールに加えて 共通の Pipeworx メタツール — ask_pipeworx、 discover_tools、search_within、remember/recall など、ゲートウェイ全体で共通の ツール一式を返します。そのため、表示されるツール数はこの表より多くなります。現在、単一パックのエンドポイントには、その パック独自のツールとともに、共通ツールがおよそ 30 個表示されます。接続の initialize 応答には対象範囲が正確に記載されており、その日の状況を確認するための 正式な情報源です。

これは意図的な設計であり、偶然の多重化ではありません。メタツールを使うと、このパックが扱わない質問にも、 カタログ全体を横断してルーティングする ask_pipeworx を通じて回答できます — MCP サーバーをもう 1 つ追加する必要はありません。現時点では、メタツールなしで パックのエンドポイントを接続する方法はありません。追加のスキーマによるコンテキスト消費がルーティングの利点を上回る場合は、 複数のパックエンドポイントではなく、完全なゲートウェイに一度だけ接続してください。

または、Pipeworx の完全なゲートウェイに接続すると、このパックだけでなく、 すべてのパックのツールが直接一覧表示されます。

{
  "mcpServers": {
    "pipeworx": {
      "url": "https://gateway.pipeworx.io/mcp"
    }
  }
}

どちらの URL も、同じゲートウェイと同じ 1851 以上のデータソースに接続します。 唯一の違いは、どのパックのツールが直接一覧表示されるかです。ask_pipeworx を使えば、どちらからでも すべてのツールにアクセスできます。

MCP クライアントがない場合は、HTTP 経由で呼び出せます

curl -X POST https://gateway.pipeworx.io/v1/tools/uiuc_airfoil_search \
  -H 'Content-Type: application/json' \
  -d '{"query":"naca24"}'

最初の呼び出しではアカウントは不要です。任意のツールを確認するには、GET https://gateway.pipeworx.io/v1/tools/uiuc_airfoil_search を実行します。ツールを探すには、{"query":"..."} を指定して POST https://gateway.pipeworx.io/v1/tools/search_packs を実行します。

スタンドアロン(ゲートウェイアカウント不要)

このパッケージは、ローカルの stdio MCP サーバーとしても実行できます。Pipeworx アカウントも、ゲートウェイへの往復通信も不要です。

{
  "mcpServers": {
    "uiuc-airfoils": {
      "command": "npx",
      "args": ["-y", "@pipeworx/mcp-uiuc-airfoils"]
    }
  }
}

または、直接実行して起動を確認します。

npx -y @pipeworx/mcp-uiuc-airfoils

stdin/stdout 経由で MCP を通信し、このパックのツールのみを対象に initialize/tools/list/tools/call に応答します。上記のゲートウェイ接続で追加される共有メタツールは含まれません。同じソース、同じツールで、ask_pipeworx によるルーティングはありません。

ask_pipeworx の使用

ツールを直接呼び出す代わりに、平易な英語で質問できます。この機能は、上記のパックのエンドポイントでも、ゲートウェイ全体でも使えます。

ask_pipeworx({ question: "your question about Uiuc Airfoils data" })

ゲートウェイが適切なツールを選び、引数を自動的に入力します。

詳細

ライセンス

MIT

コメント

MCP は初めてですか?

プロトコルの概要から最初のサーバーの導入まで、よくある疑問にまとめて答えます。

AI アプリケーションが外部のツールやデータソースに統一的な方法で接続するためのオープンなプロトコルです。クライアントはモデルとの対話を担い、MCP サーバーはツール・リソース・プロンプトテンプレートを提供します。標準メッセージでやり取りするため、1 つのサーバーを複数のクライアントで再利用できます。