Liquid

Liquid

コネクターの作成や保守は不要です。Liquid で AI エージェントをあらゆるものにつなげられます。

Liquid に URL またはデータベースを指定すると、インターフェースを自動的に見つけます。 構造を検出し、指定したフィールドにマッピングし、認証、ページネーション、正規化を処理します。型付きレコードが返されるため、クライアントコードは不要です。上流の構造が変わると、マッピングをやり直して処理を継続します。同じシンプルな API、fetch · query · write · sense で、Web API、データベース、他のエージェント（MCP/A2A）、メール、 さらには IoT や産業システム（MQTT、Modbus、OPC UA、BACnet）にもアクセスできます。LLM はセットアップ時（および構造の変更時）に学習し、データパス自体ではモデル呼び出しは行いません。

---

Liquid を通じてエージェントがアクセスできるもの

エージェントが必要とするあらゆるものに、エージェント向けの単一 API（fetch · query · write · sense）でアクセスできます。エージェントに代わって Liquid が 接続方法 を判断するため、エージェントがその方法を考える必要はありません。Liquid はエージェントの感覚 と 手です。fetch/query は調査し、sense はリアルタイムのイベントストリームを知覚し、write は現実世界に働きかけます。

• Web API とメッセージング — REST/JSON、GraphQL、SOAP/WSDL、gRPC、WebSocket、 SSE/NDJSON ストリーム、MQTT（IoT のパブリッシュ／サブスクライブ — sense でサブスクライブし、公開して動作を起こします）
• メール — IMAP/SMTP（あらゆるプロバイダー、アプリパスワードまたは OAuth2 XOAUTH2）と Gmail API（OAuth2）：メールボックスを読み取り、新着メールを sense で受信し、メールを送信できます
• 産業／OT — 工場現場向けの Modbus（PLC、センサー）および OPC UA（Industry-4.0 ノード、 ネイティブサブスクリプション）、建物向けの BACnet（HVAC/BMS）に対応し、読み取り、書き込み、状況の検知ができます
• Android デバイス — ADB 経由で、スマートフォン、TV ボックス、キオスクに対応します。logcat を検知し、shell を読み取り、 input/am で操作できます
• 他のエージェントとツール — あらゆる MCP サーバー、A2A エージェント、ChatGPT プラグインのマニフェスト
• データベース — Postgres（+ pgvector）、MySQL/MariaDB、SQLite、DuckDB、SQL Server、 Neo4j（グラフ）、MongoDB（ドキュメント）、Redis（キーと値）
• 人、場所、モノ — connectors を介して、人、家、自動車をノードとして扱えます。Telegram（メッセージを知覚し、返信を send）、Home Assistant（スマートホーム全体の状態変化を知覚し、call_service で操作 — 照明、 ロック、メディア）、Smartcar（約 30 ブランドのコネクテッドカーの位置／バッテリー／燃料を知覚し、 lock/unlock や充電を実行）

https://… エンドポイント、postgres://… / mongodb://… / redis://… DSN、grpc://… ターゲット、または別の MCP サーバーを指定すると、検出によってインターフェースを特定し、 その構造を学習して、型付きレコードをエージェントに渡します。基盤が何であっても、同じ fetch/query/write が使えます。サービスごとにコネクターを手書きする必要はありません。上流が 変更されても、インテグレーションが自動で維持されます。

# A web API it has never seen — no spec, no connector, no auth
adapter = await liquid.get_or_create(
    "https://api.openbrewerydb.org/v1/breweries",
    target_model={"name": "str", "city": "str", "country": "str"},
    auto_approve=True,
)
breweries = await liquid.fetch(adapter)            # typed records

# A database is just another interface — same API, and it writes too
db = await liquid.get_or_create("postgresql://reader@host/shop",
                                target_model={"id": "int", "email": "str"},
                                auto_approve=True)
orders = await liquid.fetch(db, "/public/orders")
await liquid.write(db, "/public/orders", op="insert",
                   values={"email": "[email protected]", "total_cents": 9900},
                   allow_write=True)               # opt-in; mutates the store

コネクターもスキーマも手書きする必要はありません。LLM がセットアップ時にインターフェースを一度学習します （データベースは自動でイントロスペクションするため、学習も不要です）。上流の構造が変化した場合も、インテグレーションは自動で修復されます。ランタイムは単純で決定論的な トランスポートです。コストは予測可能で、動作を再現でき、常時監視も不要です。

実際のエージェントが直面する制約に対応

あらゆるものにアクセスできることは、全体の半分にすぎません。もう半分の課題は、エージェントはトークンごとにコストがかかり、一貫性のない形式に混乱し、エラーの説明文を解析できないことです。Liquid は、それぞれに具体的なプリミティブで対応します。すべて実装済みで、すべて PyPI から利用できます。

コンテキスト予算の制御

# Search / aggregate server-side instead of fetch-then-filter — 10-100x fewer tokens
orders = await liquid.search(adapter, "/orders",
    where={"total_cents": {"$gt": 10000}, "status": "paid"}, limit=20)

stats = await liquid.aggregate(adapter, "/orders",
    group_by="status", agg={"total_cents": "sum", "id": "count"})

hits = await liquid.text_search(adapter, "/tickets", "shipping delay")  # BM25-lite

data = await liquid.fetch(adapter, "/orders", max_tokens=2000)      # budget cap
data = await liquid.fetch(adapter, "/customers", verbosity="terse") # id + 1-2 fields

ソースをまたいだ正規化

liquid = Liquid(..., normalize_output=True)
# Stripe {amount:1000,currency:"usd"} · PayPal {value:"10.00",currency_code:"USD"}
#   → Money(amount_cents=1000, currency="USD", amount_decimal=Decimal("10.00"))

タイムスタンプ（Unix / ISO 8601 / RFC 2822）は UTC の datetime に統一され、ページネーションの エンベロープ（{data:[…]} / {results:[…]} / Link ヘッダー）はフラット化されます。ID フィールドは id / _id / uuid / *_id の形式をまたいで正規化されます。

正規化されたインテント — サービスをまたいで共通の考え方

await liquid.execute_intent(adapter, "charge_customer",
    {"customer_id": "cus_xyz", "amount_cents": 9999, "currency": "USD"})
# Same intent on Stripe / Braintree / Square / Adyen — 71 canonical intents

構造化リカバリー — テキストを解析せずにエージェントが自己修復

try:
    await liquid.fetch(adapter, "/orders")
except LiquidError as e:
    if e.recovery and e.recovery.next_action:
        await agent.call_tool(e.recovery.next_action.tool, e.recovery.next_action.args)

すべてのエラーには、next_action: ToolCall、retry_safe、retry_after_seconds を含む Recovery が付属します。401 → store_credentials。404/410 → repair_adapter。429 → 指定された遅延時間の後に再試行します。また、上流のスキーマが変化した場合、アダプターは自己修復し（repair_adapter）、エージェントは作業を続けられます。

予測可能なコスト — 呼び出す前に把握

est = await liquid.estimate_fetch(adapter, "/orders")
# FetchEstimate(expected_items=250, expected_tokens=52_000, confidence="high", …)
if est.expected_tokens < my_budget:
    data = await liquid.fetch(adapter, "/orders")

to_tools() が出力するツールには metadata ブロック（cost_credits、typical_latency_ms、cached、idempotent、side_effects、related_tools）が付属するため、エージェントはどのツールを選ぶべきか判断できます。また、アンビエントツール（liquid_check_quota、liquid_list_adapters、…）を使えば、状態を記憶する代わりに、その場で確認できます。

---

測定された効果

現実的なエージェントタスク（500件の注文、200件のチケットのフィクスチャー、HTTPのモック）における決定論的ベンチマークです。python -m benchmarks.run で再現できます。

タスク	指標	ベースライン	Liquid 使用時	差分
100ドルを超える注文を10件検索	トークン数	75,482	1,519	−98%
ステータス別の売上（集計）	トークン数	75,482	115	−100%
顧客情報を取得（ID＋メールのみ）	トークン数	424	12	−97%
401 から復旧	構造化された next_action	いいえ	はい	—
配送に関するチケットを検索	トークン数	14,588	154	−99%
Stripe↔PayPal の整合性	フィールドの重複率	0.11	1.00	+9×
見積もりで無駄な呼び出しを回避	トークン数	14,943	0	−100%
max_tokens=2000 の予算上限	トークン数	14,943	1,999	−87%

方法の詳細とタスクごとの内訳は benchmarks/RESULTS.md をご覧ください。

インストール

pip install liquid-api                 # core + bundled MCP server (the `liquid-mcp` command)
pip install 'liquid-api[discovery]'    # + an LLM for discovering spec-less REST APIs & field mapping

LLM の追加パッケージは必要ですか？ OpenAPI、GraphQL、gRPC、MCP、A2A、WSDL などの自己記述型インターフェースと、すべてのデータベース（イントロスペクション）は、LLM なしで検出できます。また、ランタイム全体（fetch／query／write／sense）でモデルが呼び出されることはありません。LLM バックエンドが必要なのは、機械可読な仕様がない REST API を検出する場合（ヒューリスティック＋LLM）と、そのフィールドをマッピングする場合だけです。[discovery] を指定すると LiteLLM がインストールされ、OpenAI／Gemini／Anthropic／ローカルモデル／100 以上のプロバイダーを利用できます。または、次のいずれかを直接選べます。

pip install 'liquid-api[gemini]'     # Google Gemini   (or [anthropic]; OpenAI/local work with no extra via base_url)
pip install 'liquid-api[grpc]'       # gRPC transport (reflection)
pip install 'liquid-api[ws]'         # WebSocket transport
pip install 'liquid-api[pg]'         # Postgres / pgvector (asyncpg)
pip install 'liquid-api[mysql]'      # MySQL / MariaDB (aiomysql); SQLite needs no extra
pip install 'liquid-api[neo4j]'      # Neo4j graph (Bolt / Cypher)
pip install 'liquid-api[duckdb]'     # DuckDB (embedded analytics)
pip install 'liquid-api[mssql]'      # SQL Server (ODBC; needs a system ODBC driver)
pip install 'liquid-api[mongodb]'    # MongoDB (collections as endpoints)
pip install 'liquid-api[redis]'      # Redis (keyspace namespaces as endpoints)
pip install 'liquid-api[mqtt]'       # MQTT (IoT pub/sub)
pip install 'liquid-api[modbus]'     # Modbus (industrial registers)
pip install 'liquid-api[opcua]'      # OPC UA (Industry-4.0 nodes + subscriptions)
pip install 'liquid-api[bacnet]'     # BACnet (building automation; ADB needs the system `adb` binary)
# Framework integration (LangChain / OpenAI / Anthropic / MCP) is built in — no extra package.

コアに依存関係はありません。各バックエンドのライブラリはオプションの追加パッケージで、使用時にのみインポートされます。

動作を確認 — 事前設定なしですぐに実行

Liquid を、これまで扱ったことのない API（アダプターなし、OpenAPI 仕様なし、認証なし）に接続すると、型付きレコードを取得できます。コネクターを書く必要はありません。モデルが実行されるのは検出とマッピングの部分だけです。examples/live_quickstart.py で、最初から最後まで実行できます。

Connecting to an API Liquid has never seen:
  https://api.openbrewerydb.org/v1/breweries

  discovery method : rest_heuristic
  mapped fields    : ['name', 'city', 'state', 'country']
  LLM calls so far : 2  (discovery + mapping)

fetch() -> 50 typed records; first 3:
   {'name': '(405) Brewing Co', 'city': 'Norman', 'state': 'Oklahoma', 'country': 'United States'}
   {'name': '(512) Brewing Co', 'city': 'Austin', 'state': 'Texas', 'country': 'United States'}
   {'name': '1 of Us Brewing Company', 'city': 'Mount Pleasant', 'state': 'Wisconsin', 'country': 'United States'}

  LLM calls during fetch : 0
  LLM calls on 2nd fetch : 0

コネクターも、スキーマも、認証をつなぐコードも必要ありません。Liquid がインターフェースを学習し、変更があれば再学習します。これが目指すところです。自分で構築したり、付きっきりで管理したりする必要のないインテグレーションです。

MCP サーバーとして実行（オープンソース、セルフホスト可能）

エンジンをあらゆる MCP クライアント（Claude Desktop、Cursor、Claude Code）に公開できます。独自のプロセス内で実行されるため、クラウドもアカウントもベンダーロックインもありません。

Cursor ならワンクリックで設定できます（ボタンによってサーバーが mcp.json に書き込まれます。その後、Cursor の MCP 設定で OPENAI_API_KEY を追加してください）。または、手動で設定できます。

pip install liquid-api
export OPENAI_API_KEY=sk-...        # or GEMINI_API_KEY / ANTHROPIC_API_KEY,
                                    # or OPENAI_BASE_URL=http://localhost:11434/v1 for local (Ollama/vLLM)
liquid-mcp                          # or: python -m liquid.mcp_server

uvx を使えばインストール不要です（liquid-mcp パッケージにより、コマンドを名前で実行できます）。Claude Code の場合：

claude mcp add liquid --scope user -e OPENAI_API_KEY=sk-... -- uvx liquid-mcp

Claude Desktop／その他の MCP クライアントの場合：

{ "mcpServers": { "liquid": {
  "command": "uvx",
  "args": ["liquid-mcp"],
  "env": { "OPENAI_API_KEY": "sk-..." }
} } }

（または、pip install liquid-api の後に uvx を削除し、直接 "command": "liquid-mcp" を使用できます。）

Claude Desktop でワンクリック設定： .mcpb バンドルをインストールしてください。インストール時にモデルキーの入力を求められ（OS のキーチェーンに保存されます）、JSON を編集する必要はありません。マシンに uv が必要です。

ツール：liquid_connect（あらゆるインターフェースを検出してマッピング）、liquid_fetch、liquid_query（サーバー側での検索／集計）、liquid_estimate（呼び出し前のコスト／サイズ見積もり、呼び出しなし）、liquid_list_adapters、liquid_discover。インターフェースはデフォルトで読み取り専用です。LIQUID_ALLOW_WRITES=1 を設定してサーバーを起動すると、liquid_execute（データベースへの挿入／更新／削除）も公開されます。アダプターと認証情報は ~/.liquid に保存されます。あらゆる LLM に対応しています。OpenAI、Gemini、Anthropic、base_url 経由の OpenAI 互換／ローカルエンドポイント、LiteLLM 経由の 100 以上のプロバイダー、または CallableBackend を通じた独自関数を利用できます。

クイックスタート — LangGraph エージェント

from liquid import Liquid, InMemoryCache, RateLimiter
from liquid._defaults import InMemoryVault, InMemoryAdapterRegistry, CollectorSink
from liquid_langchain import LiquidToolkit
from langgraph.prebuilt import create_react_agent
from langchain_openai import ChatOpenAI

liquid = Liquid(
    llm=my_llm, vault=InMemoryVault(), sink=CollectorSink(),
    registry=InMemoryAdapterRegistry(), cache=InMemoryCache(), rate_limiter=RateLimiter(),
    normalize_output=True,    # cross-source canonical shapes
    include_meta=True,        # _meta block on every response
)

adapter = await liquid.get_or_create(
    "https://api.shopify.com",
    target_model={"id": "str", "total_cents": "int", "customer_email": "str"},
    credentials={"access_token": "shpat_..."},
    auto_approve=True,
)

tools = LiquidToolkit(adapter, liquid).get_tools()
agent = create_react_agent(ChatOpenAI(model="gpt-4o-mini"), tools)
result = await agent.ainvoke(
    {"messages": [("user", "Find 5 recent orders over $100 from VIP customers")]}
)

エージェントのツールには、WHEN に使うか、何に使わないか、戻り値の形式、コストなどの詳細な説明が付いています。すべてのエラーで構造化された復旧情報が提供され、サーバー側検索により、5 件を見つけるために 500 件の注文を取得することもありません。

あらゆるインターフェースに、ひとつの API

検出処理で対象を特定し、各エンドポイントにプロトコルのタグを付けます。プラグイン可能なトランスポートドライバーが実行しますが、エージェント向け API（fetch、query、write、マッピング、復旧、キャッシュ、レート制限）はすべてのインターフェースで共通です。

インターフェース	ランタイム	書き込み	インストール
REST / HTTP+JSON	✅	✅ アクション（POST/PUT/PATCH/DELETE）	—
GraphQL	✅ クエリ + Relay ページネーション	✅ ミューテーション	—
SOAP / WSDL	✅ 標準ライブラリの XML	—	—
gRPC	✅ 単項 + サーバーストリーミング（リフレクション）	—	liquid-api[grpc]
WebSocket	✅ 件数制限付きバッチ読み取り + サブスクライブ + ライブ sense	—	liquid-api[ws]
SSE / NDJSON（HTTP サーバープッシュ）	✅ 件数制限付きバッチ読み取り + ライブ sense	—	—
MCP（エージェント）	✅ ツールの呼び出し / リソースの読み取り + 通知 sense	✅ ツール呼び出し	—
A2A（エージェント）	✅ AgentCard スキルへの JSON-RPC message/send	—	—
Postgres（+pgvector）	✅ テーブル/ビュー、フィルター、ページネーション、ベクトル検索	✅	liquid-api[pg]
MySQL / MariaDB	✅ テーブル/ビュー、フィルター、ページネーション	✅	liquid-api[mysql]
SQLite	✅ テーブル/ビュー、フィルター、ページネーション	✅	—（標準ライブラリ）
DuckDB	✅ テーブル/ビュー、フィルター、ページネーション	✅	liquid-api[duckdb]
SQL Server	✅ テーブル/ビュー、OFFSET/FETCH ページネーション	✅	liquid-api[mssql]
Neo4j（グラフ）	✅ ラベル/リレーションシップタイプ、プロパティフィルター	✅ ノード CRUD	liquid-api[neo4j]
MongoDB（ドキュメント）	✅ コレクション、フィールドフィルター、ページネーション	✅	liquid-api[mongodb]
Redis（キー・バリュー）	✅ キースペースの名前空間、型付き値、SCAN ページング	✅ SET/HSET/DEL	liquid-api[redis]
MQTT（IoT pub/sub）	✅ サブスクライブ → バッチ + ライブ sense	✅ パブリッシュ	liquid-api[mqtt]
Modbus（産業用）	✅ レジスター/コイルの読み取り + 差分ポーリング sense	✅ レジスター/コイルの書き込み	liquid-api[modbus]
OPC UA（産業用）	✅ ノードの読み取り + ネイティブサブスクリプション sense	✅ ノードの書き込み	liquid-api[opcua]
BACnet（ビル）	✅ オブジェクトプロパティの読み取り + 差分ポーリング sense	✅ プロパティの書き込み	liquid-api[bacnet]
ADB（Android）	✅ シェルの読み取り + logcat sense	✅ シェルアクション（input/am）	—（システムの adb）
メール — IMAP/SMTP	✅ UID によるメールボックスの読み取り + 新着メール sense	✅ 送信（MIME）	—（標準ライブラリ）
メール — Gmail API	✅ 一覧表示/取得 + history sense	✅ messages.send	—（OAuth2）

読み取りと書き込み。 liquid.write(adapter, endpoint, op="insert", values={...}, allow_write=True) は、あらゆるデータベース（SQL の INSERT/UPDATE/DELETE、Mongo の insert/update/delete、Redis の SET/HSET/DEL、Neo4j のノード CRUD）を変更します。Web/エージェントへの書き込みは、検証済みアクションを通じて行われます。識別子はイントロスペクションから取得され、値はパラメーター化されます。update/delete には where が必須です（無条件の変更はできません）。allow_write=True で明示的に有効にするまで、書き込みは無効です。

Sense — 求心器官。 liquid.sense(adapter, endpoint) は、ライブイベントストリームが存在する場所からイベントを認識します。SQL の行差分（および Postgres の LISTEN/NOTIFY）、Redis pub/sub、WebSocket フレーム、HTTP サーバープッシュ（SSE/NDJSON）、MCP 通知などを、それぞれモダリティに依存しないイベントとして生成します。内側に向ける場合は、liquid.sense_webhook(port=…, verifier=…) が受信エンドポイントをホストするため、サービス（または人間）が webhook 経由で POST すると、それも認識可能なシグナルになります。いずれも max_events / max_seconds で制限されるため、エージェントはプル方式ですべてのイベントを取得できます。

感覚運動ループ。 react(stream, handler) は、認識した各イベントに対してハンドラーを実行します。エラー分離と同時実行数の制限があるため、ホストは認識 → エージェントを起動 → 動作を実現できます。merge_senses(*streams) は複数の感覚入力を1つのループにまとめるため、1つのエージェントでデータベース、キュー、webhookを同時に監視できます。

events = merge_senses(
    await liquid.sense(orders, "/orders"),
    await liquid.sense_webhook(port=8088, verifier=stripe_verifier),
)
await react(events, on_event, max_concurrency=4)

検出は自動で行われ、その場で識別します。 パイプラインの実行前に、フィンガープリント処理で対象に名前を付けます。ポート番号だけの host:port は、既知のポートに基づいて正規化されます（db:5432 → postgresql://db:5432）。また、liquid.identify(url) は「これは何で、そのドライバーはインストールされているか」を回答し、バックエンドが見つからない場合はインストール方法を提示します。（プロトコルをその場で識別することは可能ですが、新しい認証済みバイナリプロトコルをその場で話すことはできません。そのため、不明なものには推測で名前を付けず、判明したものだけを示します。）

検出対象	探索先	コスト
データベース	カタログのイントロスペクション（postgres://、mysql://、mongodb://、redis://、neo4j://、…）	低
gRPC / WebSocket / SSE	サーバーリフレクション／フレームのサンプリング／Content-Type の判定	低
MCP / A2A / Plugin	/mcp、/.well-known/agent-card.json、/.well-known/ai-plugin.json	低
OpenAPI / GraphQL / SOAP	仕様、イントロスペクション、または WSDL	低
REST ヒューリスティック	一般的なパス＋LLM による解釈	中
ブラウザー	Playwright によるネットワークのキャプチャ	高

コードを書かずにバックエンドを追加できます。 SQL ファミリーのコントラクトは宣言的なため、データとして扱えます。ダイアレクトマニフェスト（引用符、プレースホルダースタイル、ページネーション、イントロスペクション SQL、エラーマップ、DBAPI2 モジュール）を register_sql_manifest({...}) で登録すると、動作するドライバーと検出機能がインストールされます。そのため、新しい SQL／ワイヤー互換ストア（CockroachDB、ClickHouse、任意の DBAPI2 ドライバー）は、ネットワークから JSON として取得したものも含め、リリースなしで接続できます。それ以外の新しいプロトコルは、liquid.transport.ProtocolDriver プロトコルを通じてプラグインできます。SQL バックエンドはダイアレクト対応のコアを共有しているため、新しいものも約 80 行のアダプターで実装できます。

Liquid に新しいプロトコルを追加したいですか？ 完全なトランスポートドライバー（fetch／write／sense）は通常約 150 行です。手順と追加希望リスト（CAN バス、CoAP、KNX、AMQP、NATS、SNMP、…）については、docs/ADDING_A_DRIVER.md をご覧ください。コントリビューションを歓迎します。

2,500 以上の API が事前に検出・マッピングされ、グローバルカタログに登録されています。人気のサービスのほとんどは、検出コストなしで接続できます。

アーキテクチャ

URL / DSN                       Agent
   ↓                              ↑
 FINGERPRINT → DISCOVERY        FETCH · QUERY · WRITE · SEARCH · AGGREGATE
   ↓                              ↑
 one ProtocolDriver per          Deterministic per-protocol transport
 interface:                        • Query DSL (server-side filter)
   REST GraphQL gRPC WS SSE MQTT   • Output normalization
   MCP A2A · SQL graph doc KV ·    • Verbosity / max_tokens / _meta
   Modbus OPC-UA BACnet ADB …      • (full protocol list in the table above)
   ↓                              • Structured recovery + self-heal
 APISchema                        • Rate-limit-aware token bucket
   ↓                              • Response cache (Cache-Control aware)
 AI MAPPING (setup only)          • Empirical probing data (Cloud)
   ↓
 AdapterConfig

AI が関与するのはセットアップ時だけです。 実行時は変換を伴う純粋なトランスポートであり、呼び出しごとに LLM を使用しないため、コストは予測可能で、動作は再現可能です（コンパイル結果をキャッシュする search_nl を除きます）。

差し替え可能なコンポーネント

横断的な関心事はすべて、置き換え可能な Protocol です。

from liquid.protocols import (
    Vault, LLMBackend, DataSink, KnowledgeStore, AdapterRegistry, CacheStore,
)

すべてのコンポーネントについてインメモリー実装が付属しています。liquid-cloud は、ホスト環境へのデプロイ向けに PostgresVault、RedisCache などを提供します。

フレームワークのサポート

adapter.to_tools(format="anthropic")   # Claude tool use
adapter.to_tools(format="openai")      # OpenAI function calling (LangChain/CrewAI consume these)
adapter.to_tools(format="mcp")         # MCP (Claude Desktop, Cursor)

フレームワークとの統合

追加パッケージのインストールは不要です。liquid-api に組み込まれています。 adapter.to_tools(format="anthropic" | "openai" | "mcp") は、Claude のツール使用、OpenAI の関数呼び出し（LangChain／LangGraph および CrewAI が直接利用）、あらゆる MCP クライアント（Claude Desktop、Cursor、…）ですぐに使えるツール定義を出力します。付属の liquid-mcp サーバーを使えば、Liquid を MCP ツールとしてすぐに利用できます。

比較

機能	Liquid	Zapier	LangChain ツール	DIY
あらゆるインターフェースを自動検出（厳選されたコネクター不要）	はい	いいえ	いいえ	いいえ
API＋データベース＋エージェントを単一レイヤーで利用	はい	一部	いいえ	いいえ
単一 API で読み取りと書き込み	はい	はい	一部	いいえ
サーバーサイドでの検索／集計	はい	いいえ	いいえ	一部
ソースをまたいだ出力の正規化	はい	一部	いいえ	いいえ
next_action を伴う構造化された復旧	はい	いいえ	いいえ	いいえ
スキーマのドリフトを自己修復	はい	いいえ	いいえ	いいえ
事前のコスト見積もり	はい	いいえ	いいえ	いいえ
MCP＋A2A＋LangChain＋CrewAI にネイティブ対応	はい	いいえ	一部	いいえ
オープンソース	はい	いいえ	はい	該当なし

ドキュメント

• クイックスタート — 検出 → マッピング → 取得、および LLM を使わない実行時
• OSS と Cloud の比較 — 正直な境界：無料／セルフホストとホスト型
• アーキテクチャ
• 拡張 — 独自の Vault／LLM／Sink を実装する
• 書き込み操作の仕様