ツール概要
Linkly AI は MCP(Model Context Protocol)を通じて AI アシスタントに9 つのツールを公開しています。中心にあるのは、段階的なドキュメントアクセスワークフローです:list_libraries(ナレッジライブラリの一覧表示)、explore(ドキュメントコレクションの概要表示)、find_paths(キーワードでフォルダパスを特定し、search の path_glob に渡す)——に加えて、list(コンテナの列挙:フォルダ内のファイル、ライブラリ、またはノート)と、唯一のノート書き込みツール note_save(ノートの作成 / 編集)があります。
search
ドキュメントを検索し、関連する結果を取得
outline
ドキュメントのアウトラインを表示し、構造を把握
grep
正規表現で特定のテキストパターンを検索
read
ドキュメントの内容を読み取り、詳細情報を取得
list_libraries
ナレッジライブラリとそのドキュメント数を一覧表示
explore
ドキュメントコレクションのテーマと構造の概要を表示
find_paths
キーワードでフォルダパスを特定し、
search の path_glob に渡すlist
コンテナ内の項目を列挙する——フォルダ、ライブラリ、またはノート
note_save
ノートを作成・編集する。唯一の書き込みツール
note_save を除くすべてが読み取り専用です——ドキュメントを読むだけで、内容を書き換えることはありません。note_save はノートのディレクトリにしか書き込めず、しかも削除ツールは存在しません。ノートの削除はアプリ上でご自身が行う必要があります。
検索(search)
インデックス済みのローカルドキュメントを検索し、最も関連性の高い結果リストを返します。パラメータ
時間フィルターと並べ替えについて:
- ユーザーが明確な期間を指定する場合(「先月」「2024 年中」「直近 3 ヶ月」)は、
modified_after/modified_beforeを使います。 - ユーザーが「最近」「最新」「最古」のように具体的な期間を指定しない場合は、
time_sort=newestまたはoldestを使います。 - 両者は組み合わせ可能:「2024 年で最も古いもの」は
modified_after=2024-01-01+modified_before=2024-12-31+time_sort=oldestです。 - 「先月」のような相対日付を計算するには、まず任意のツール応答末尾の
[meta] now=...フィールドから現在の UTC 時刻を読み取り、そこから日付を算出してください。詳しくは下記の レスポンスメタデータ を参照。
返却フィールド
各検索結果には以下の情報が含まれます:使用例
アウトライン(outline)
1 つまたは複数のドキュメントの構造化されたアウトラインとメタデータを取得し、ドキュメント構造の迅速な把握と対象セクションの特定に役立ちます。パラメータ
アウトラインを使うべきタイミング
アウトライン機能はブックマーク付きの PDF、Markdown、DOCX、PowerPoint (PPTX)、EPUB のドキュメントで最も効果的です。長いドキュメントや書籍を読む際に特に有効です。 プレーンテキストやブックマークのない PDF へのアウトラインサポートは、今後のイテレーションで追加予定です。
使用例
Grep
単一のドキュメント内で正規表現パターンにより特定の行を検索します。アウトラインが利用できないhas_outline=false のドキュメントに最適です。search の後に使用して、名前、日付、用語、識別子、その他のパターンの正確な位置を特定し、read で offset を指定して前後の文脈を確認します。すべてのドキュメントタイプ(PDF、Markdown、DOCX、PPTX、EPUB、TXT、HTML)で動作します。複数のドキュメントを検索する場合は、ドキュメントごとに grep を 1 回呼び出してください。
パラメータ
Grep とアウトラインの使い分け
使用例
読み取り(read)
ドキュメントの内容を行番号での位置指定とページネーションで読み取ります。長いドキュメントの特定部分の読み取りに適しています。Read ツールは Claude AI SDK と一貫した動作をするため、各種 Agentic AI モデルで最適な結果が得られます。パラメータ
画像とテキストが混在するドキュメントを読む
多くのドキュメント(とくに Markdown のノートや技術文書)では、肝心な情報が図の中にあります。read は、いま読んでいる行範囲の中に現れた画像参照を、対応するインデックス済みの画像ドキュメントとして解決し、結果の末尾に添えます。どこまで添えるかは image_text で決めます:
full には予算の上限があります:画像 1 枚につき最大 2000 文字、1 回の呼び出し全体で 20000 文字まで。予算を超えた画像は自動的に abstract へ格下げされ、その画像を単独で読むための案内が示されます。
コンテンツ形式
Read ツールは行番号付きの内容を返し、参照と位置特定が容易です:
ページネーション戦略
長いドキュメントの場合、分割して読み取ることをお勧めします:read でその範囲の内容を正確に読み取れます。
使用例
ライブラリ一覧(list_libraries)
ユーザーが設定したすべてのナレッジライブラリを、説明とドキュメント数とともに一覧表示します。パラメータ
パラメータは不要です。ユースケース
- ユーザーが「どんなライブラリがありますか?」と質問した場合
searchのlibraryパラメータを使用する前に、ライブラリ名を確認する場合
探索(explore)
インデックス済みの全ドキュメントまたは特定のライブラリの鳥瞰的な概要を取得します。ドキュメントタイプの分布、ディレクトリ構造(ファイル数と語数の中央値付き)、上位キーワード(出典の帰属付き)を返します。パラメータ
ユースケース
- ユーザーがナレッジベースやドキュメントコレクションの内容を知りたい場合
- ユーザーに特定の検索トピックがなく、利用可能なテーマや方向性を発見したい場合
- AI アシスタントが効果的な検索戦略を策定するために、規模とトピック分布を把握する必要がある場合
search クエリに活用します。
パス特定(find_paths)
インデックス済みドキュメントのファイルパスフィールドに対してキーワードで曖昧マッチングを行い、フォルダ単位で集約して上位の候補ディレクトリを返します。search の補助ツールとして位置づけられており、ユーザーがコンテナを名前で示しているのに(「Notion ノートの中で」「Dropbox の論文フォルダで」)その実際のディスク上のパスがわからないとき、まず find_paths で実際のパスを探し、それを search の path_glob パラメータに渡します。
ディスク上の実際のフォルダ名は、ユーザーの口語表現と一致しないことが多く(例:エクスポートが Notion-Export-c58e430f... のような名前で保存される)、path_glob を直接推測するのは脆弱です。
パラメータ
返却フィールド(JSON モード)
集約の挙動
- パターンがファイル名セグメントにしかマッチしないファイル(ディレクトリセグメントにマッチがない)は静かに破棄されます。これは「フォルダを探す」ツールであり、「ファイルを探す」ツールではないためです。マッチするファイルがあるはずなのに候補ディレクトリが 0 件返る場合は、
searchを直接呼び出すフォールバックを検討してください。 - 各マッチは、パス内で最も浅い位置にあるパターン出現を基準に、次の
/で切り詰められて集約されます。例:local:///Users/me/Documents/Notion-Export-abc/workspace/page.mdがキーワードNotionでヒットすると、ファイルがどれだけ深くても.../Documents/Notion-Export-abcに集約されます。
使用すべきとき
- ユーザーが曖昧または異言語の語でコンテナを表現しており(「Notion ノートの中で」「Dropbox の論文フォルダで」「ワークバックアップで」)、実際のパスがわからないとき
searchを呼び出す前に、path_globの値を決定するため
使用すべきでないとき
- 内容/トピックそのものを探すクエリ(「履歴書を探す」「AI 論文を探す」)—— 直接
searchを呼ぶ。混合検索はすでにタイトル/ファイル名/本文/パスをカバー - ファイルタイプのみでフィルター(「すべての PDF」)——
searchにpath_glob="*.pdf"を直接渡す - コンテナ意図のない漠然としたクエリ(「最近のもの」)——
searchを直接
使用例
列挙(list)
あるコンテナ内の項目を列挙します。全文マッチングは行いません——キーワードや意味で内容を探したい場合はsearch を使ってください。3 種類のコンテナに対応しています:folder(ディスク上のディレクトリ配下のインデックス済みファイル)、library(1 つのライブラリのファイル)、notes(ローカルのカード型ノート)。
ツールの役割分担:explore = 全体の概観 → find_paths = ディレクトリを見つける → list = 既知のコンテナ内のファイルを列挙する → outline / read = 内容を読む。列挙はサブツリー全体をフラットに再帰走査します——ディレクトリツリーは返しません。掘り下げるには項目内の絶対パスをたどるか、find_paths を使ってください。
パラメータ
返却フィールド
folder / library の項目には次が含まれます:doc_id、title、絶対 path、doc_type、word_count、total_lines、has_outline、modified_at(Unix ミリ秒、ファイルシステムの mtime)、keywords、snippet(抜粋が無効のときは null)、そして skip_reason——skip_reason が非 null の場合、その内容は読み取れないため read / grep しないでください。outline と read のどちらを使うかは total_lines + has_outline で判断します。ローカル scope の total はフィルター後の全集合の件数です。クラウドライブラリでは総数が不明な場合に total: null が返ることがあります——いずれの場合も offset + has_more でページ送りしてください。
notes の項目には次が含まれます:doc_id(read / grep / outline にそのまま渡せます)、note_id と最新の version(この 2 つは note_save で編集する際の楽観ロックの資格情報です)、title、絶対パス、created_at / modified_at(Unix ミリ秒)、tags、出典情報、そしてデフォルトで付く snippet。レスポンスにはさらに available_tags が含まれます——現在のすべてのノートのタグのうち、使用頻度が高い上位 50 件で、そのまま次回の tags フィルターに使えます。
README ポインタ:
path を明示的に渡し(scope が folder またはローカル library)、かつ README 系のファイルがそのディレクトリの直下にある(サブディレクトリではない)場合にのみ、レスポンスにトップレベルの readme ポインタが付きます。クラウドライブラリでは返りません。それが存在し、かつフォルダの目的を理解する必要があるときは、まずそのドキュメントを読んでください。ファイルシステム優先(notes):書いたばかりのノートはすぐ一覧に現れますが、その時点では
doc_id は null、indexed は false です(文字数や行数もまだ空です)。インデックスが終わってから埋まります。つまり「書いたばかりのノートは一覧には出るが検索では出てこない」のは正常な挙動で、失われたわけではありません。title も null になることがあります——ファイル名が機械的に生成されたノートには使えるタイトルがないためです。その場合は抜粋、タグ、日時で見分けてください。クラウドライブラリ
folder が扱えるのはローカルのディスクパスだけです。クラウドライブラリを列挙するには、scope="library" に library="cloud://<owner>/<slug>" を組み合わせ(--remote で利用可能)、path には相対ディレクトリプレフィックス——まさにクラウドの find_paths が返す形式——を渡します。プレフィックスはそのライブラリの全ソースの和集合に適用されます。「プレフィックスが存在しない」と「ディレクトリが空」は区別できず、最初のページ(offset=0)ではどちらも total: 0 で返ります(path を渡していた場合はヒントも付きます)。
クラウドの列挙はローカルといくつか異なります:sort="name" は非対応;skip_reason は常に null;抜粋は約 120 文字で切り詰め;最初のページ以降は total が null になることがあります——ページ送りは has_more で判断してください。
使用例
ノートの保存(note_save)
ローカルの Markdown カード型ノートを 1 件作成または編集します。これは唯一の書き込みツールで、書き込めるのはノートのディレクトリだけです。YAML のメタデータはすべてサーバー側で生成されるため、呼び出し側が用意する必要はありません。パラメータ
押さえておくべき 2 つのルール
編集は必ず楽観ロック(CAS)のループで行います
編集は必ず楽観ロック(CAS)のループで行います
正しい編集の順序は次のとおりです:
list(scope="notes")でnote_idとversionを取得するread(doc_id)で現在の完全な本文を読むnote_saveにmode="edit"、note_id、base_version=<いま取得した version>、そして修正後の完全な本文を渡す——残したい#タグはそのまま残し、消したいものは削除します
base_version が古い場合(その間にノートが変更された場合)は NOTE_VERSION_CONFLICT が実際のバージョン番号とともに返ります。読み直し、マージし、再試行してください。そのまま上書きしてはいけません。成功したレスポンスは毎回、ノートの実際の content(サーバーが #タグ を補っている場合があります)と新しい version を返します——以降の編集は必ず返ってきた content を土台にし、自分が送ったほうを使ってはいけません。まだインデックスされていないノートは doc_id が null ですが、作ったばかりのノートを編集できるのも、まさにこの戻り値のおかげです。抜粋だけを頼りにノート全体を書き直すことは絶対に避けてください。レスポンスメタデータ
成功した各ツール応答には現在の UTC 時刻が付加され、呼び出し側がモデルの学習データのカットオフに依存せずに「先月」「今年」「過去 30 日間」などの相対日付を計算できるようになっています。-
Markdown 出力:応答末尾に区切りブロックが追加されます:
-
JSON 出力:トップレベルに
_metaオブジェクトが追加されます:
isError: true)にはメタデータが付加されません —— エラー本体がすでに失敗の原因を伝えており、タイムスタンプを付加するとシグナルが希薄になるためです。
ユーザーが相対日付を使う場合は、最新のツール応答から now を読み取り、対応する ISO 8601 日付を計算してから search の modified_after / modified_before に渡します。
ワークフロー例
完全なワークフロー:CLI 方式
以下の例は、CLI を使って完全なドキュメント検索を行う方法を示しています:完全なワークフロー:MCP 方式
AI アシスタントが MCP プロトコルでツールを呼び出す場合、リクエスト形式は以下の通りです:よくある質問
どのドキュメント形式に対応していますか?
どのドキュメント形式に対応していますか?
Linkly AI は現在、以下の形式に対応しています:
音声・動画の文字起こしはデフォルトで無効です——これらのファイルもインデックスには登録されるためファイル名では検索できますが、「中で何が話されているか」を検索するには、先に 設定 → インデックス で「音声解析」と「動画解析」を有効にする必要があります。詳しくはインデックスの設定をご覧ください。
アウトラインが利用できない場合はどうすればよいですか?
アウトラインが利用できない場合はどうすればよいですか?
ドキュメントに利用可能なアウトラインがない場合(
has_outline: false)、以下の方法があります:readツールを直接使用して、ドキュメントの内容をページごとに閲覧します- まずドキュメントの冒頭(デフォルト 200 行)を読み取り、大まかな内容を把握してから続きを読むか判断します
長いドキュメントはどのように処理すればよいですか?
長いドキュメントはどのように処理すればよいですか?
推奨フロー:
- まず
outlineでドキュメントの構造を把握します(アウトラインがある場合) - アウトライン内の行範囲に基づいて、
readのoffsetとlimitパラメータで対象セクションを正確に読み取ります - 1 回の読み取りは最大 500 行です。
offsetを調整してページごとに読み取ります
MCP サービスのデフォルトポートは何番ですか?
MCP サービスのデフォルトポートは何番ですか?
デフォルトポートは 60606 です。このポートが使用中の場合、アプリは自動的に他のポートを試行します。Linkly AI Desktop の設定で実際に使用されているポートを確認できます。
検索結果が不正確な場合はどうすればよいですか?
検索結果が不正確な場合はどうすればよいですか?
以下をお試しください:
- より正確なキーワードを使用する
- 自然言語での記述を使用する(ベクトルセマンティックマッチングを活用)
- キーワードと同義語を組み合わせる(例:
"authentication auth login sign-in") --typeで特定のドキュメントタイプをフィルターし、検索範囲を絞り込む

