fix: clarify fixed AI tools and domain object discovery

draft/ai-tools-interaction.md

@@ -20,7 +20,9 @@
 
 これらはProtocol interactionとの一対一対応ではない。特に `inspect` の対象はInterface参照ではなく、Objectを指すpathである。必要な `observe` と複数の `fetch_interface` はClient内部で行う。
 
-Operationを調べた後も、AI向け入口はこの3操作のままでよい。InspectしたOperationごとに新しいToolを登録することは、この利用モデルの前提ではない。
+AI向けの基礎ツールは `tree` / `inspect` / `invoke` の3操作に固定する。Inspectで見つけたOperationも `invoke` から呼び出し、Operationごとに新しいToolを登録しない。
+
+大量のObjectの発見は、各ドメインのObjectが公開する `list` / `search` / `query` 等のOperationで行う。件数制限、検索条件、ページング等は、そのドメインに応じて各Operationが管理する。AIはこれらのOperationも `inspect` で確認し、`invoke` で呼び出す。発見方法が増えても基礎ツールは追加・変更しない。
 
 ## tree: indexableな配置を見る
 
@@ -35,8 +37,6 @@ Operationを調べた後も、AI向け入口はこの3操作のままでよい
 
 浅い位置に大量の要素があれば、小さいdepthでもAIが把握できない出力になる。これはdepth調整やClient側の切り捨てだけで解決する問題ではなく、Hostが何をindexableにするかの問題である。
 
-大量の要素やドメインデータの発見には、Collection Objectの `list` / `search` / `query` 等のOperationを使う。Client独自の全文検索、semantic search、ランキングを基本の3操作に追加する前提にはしない。
-
 ## inspect: 対象の説明とできることを知る
 
 `inspect(path)` は、そのpathで公開されているObjectの説明と操作を返す。