TinyFishのセットアップ診断・修復を行います。MCP登録、認証、接続性（つながりの状態）をチェックします。 TinyFish CLI（コマンドラインツール）に組み込まれた診断機能で設定を確認した後、CLI単独ではできない作業を実施します。それは、このシステムが実際にTinyFishに到達できることを確認することです。 次のような場合に使用: - TinyFishのツールが失敗する - 認証エラーが返される - インストール後に検証が正常に完了しなかった
Diagnose and repair your TinyFish setup — MCP registration, auth, and connectivity. Runs the TinyFish CLI's own doctor for the config checks, then does the one thing the CLI cannot — proving this harness can actually reach TinyFish. Run when TinyFish tools fail, return auth errors, or after an install that did not verify cleanly.
tinyfish doctor（CLI 0.22以降）は診断を実行します。あなたの役目は、それを走らせて、構造上CLIができない1つのチェックを手動で行い、結果に対処することです。設定ファイルを直接編集してはいけません。すべての修復はCLIを通じて行います。CLIは自動バックアップとマージの確実性を保証します。
Claude.ai、デスクトップ、コワークスペースなどのサンドボックス環境にはnpxがありません。コマンドが実行できない場合は、ステップ2をスキップして進んでください（そちらの方が価値あるチェックです）。その後、ステップ1のコマンドをユーザーに渡して、自分で実行してもらいます。
npx -y @tiny-fish/cli@latest doctor --harness claude-code
標準出力に返るJSON: schema_version、cli_version、ok_harnesses、ok_cli、checks[]、harnesses[]、repairs[]。
schema_versionを最初に読んでください。本スキルは3（CLI 0.22以降）について説明しています。このコマンドは@latestを指定しているため、より新しいCLIがあなたが知らない形式を返す可能性があります。3より大きい場合は、それ以上フィールドを読まず、代わりに--pretty出力をユーザーに表示して、判断はステップ2に委ねてください。3より小さい場合は、1つのokが2つの判断に置き換わり、checks[]にはscopeがないため、checks[]と終了コードだけを読んでください。
判断は2つあります。1つではありません。 ok_harnessesはユーザーのエージェント（自動操作ツール）がTinyFishに接続できるかを示し、ok_cliはCLI自体の認証情報が機能しているかを示します。checks[].scope（harness、cli、info）はそのチェックがどちらに関わるかを示し、harness スコープのチェックだけが終了コードに影響します。ok_cli: falseで終了0となるのは矛盾ではなく、正当な状態です。これをハーネスの不具合ではなく、「CLIの認証情報に問題がある」と報告してください。
| 終了コード | 意味 |
|---|---|
0 |
harness チェックが失敗していない（ok_cliはfalseのままでもあり得る） |
1 |
harness チェックが失敗している — checks[]を読んでください |
2 |
doctor が実行できなかった；標準出力は空です、理由は標準エラー出力にあります |
警告（warn）は失敗ではなく、終了コードに影響しません。doctorが何かをチェックできなかったということであって、それが壊れているということではありません。登録関連の警告で詳細が「キーが読み取れなかった」または「検証されなかった」と言っている場合、キーは存在しますがdoctorがその値をテストできなかったということです。すべてのCodexインストール、および設定がヘッダーを隠すハーネスがこれに該当します。警告を修復してはいけません。ステップ2で実証してください。
--prettyはユーザーにリストを表示するときだけ使用してください。レポートに--debug出力を含めないでください。生のスタックと絶対パスが含まれるため、唯一推奨されないチャネルです。
harnesses[].proves_harness_reachは、doctorがそのハーネスが認証できたことを実証できなかった場合は常にfalseになります。OAuth ハーネスの場合、CLIがハーネスのトークンを借りられないため、常にfalseです。そのギャップを埋められるのはあなただけです。
--harness claude-codeはharnesses[]を正確に1つのエントリに絞るため、どのハーネスについて説明しているのかに曖昧性はありません。
まずTinyFishサーバー数を数えてください。 プラグイン、CLIで書き込まれたエントリ、アカウントレベルのコネクタが、すべて同じエンドポイントを指して同時に登録されることがあります。doctorが検査するのはtinyfishという名前のものだけで、その姉妹品は見えません。doctorが報告したサーバーをメモしておきます。
次に、安価なクエリで1回searchを呼び出し、どのサーバーが応答したかメモします。ツール名前空間がそれを示します。
| 起こること | 意味 |
|---|---|
| doctorが報告したサーバーからの結果 | セットアップが完全に機能している（auth_modeが何を言っていても） |
| 結果が返ってくるが、別のTinyFish サーバーから | フラグが立てられた登録について何も実証していない。機能しているサーバーと、フラグが立てられたサーバーの両方を未検証として報告してください |
認証エラーだが、doctorがregistered: yesと言っている |
登録は存在する；その裏にある認証情報が壊れている |
| TinyFish ツールがまったくない | サーバーがこのセッションで読み込まれていない — ユーザーはエージェントを再起動する必要があります |
registration: passが実証することの内容はschema_versionによって異なります。バージョン2と3ではAPI キー登録はネットワークでテストされたため、古いキーヘッダーはすでにfailで、その横にconnect修復があります。バージョン1では、すべてのOAuth またはauth_mode: unknown登録（すべてのバージョン）では、passは存在確認のみです。doctorが設定を読んだのであってネットワークを読んだのではなく、古いキーは合格したままですがすべての呼び出しが401を返します。どのバージョンも姉妹品については何も言わず、健全な姉妹品は喜んで応答する一方、壊れたものは壊れたままです。
repairs[]に現れるコマンドだけを実行し、実行前にcommandを表示してください。到着した順序を保ってください。action: auth-loginがaction: connectの前に来るのは、connectが保存されているキーを書き込むため、古いキーはまず置き換える必要があります。
npx -y @tiny-fish/cli@latest doctor --fix --harness claude-codenpx -y @tiny-fish/cli@latest doctor --fix --yes；unattended_safe: trueの修復だけ実行され、残りはスキップされます。スキップされた修復を修正として報告しないでください。unattended_safe: false → ユーザーに渡してください。実行しないでください。ほとんどの修復が false と予想されます。auth loginは常に false ですし、connect <harness>はCursor以外のすべてのハーネスで安全ではありません。Cursorでも、CLI自体の認証済み呼び出しが成功している場合だけです（バージョン2の場合。取り消されたキーも認証情報として解決するため）。フィールドを読んで、推測しないでください。/mcpを実行して、tinyfish を選択してサインインするよう指示してください。修復後、ステップ2を再実行してください。成功とは、実際の検索結果を表示することです。ユーザーは自分のエージェントがライブウェブにアクセスするのを見るべきです。
doctorの標準出力JSONをそのまま添付してください。スキーマバージョン付きで、既に不感情報保護済みです。独自のレポートを作成したり、フィールドを追加したり、設定内容をペーストしたりしないでください。終了コード2の場合JSONはありません。空のレポートを提出するのではなく、そう明記してください。
その後、/tinyfish:feedbackを提供して報告するよう促します。
tinyfish doctor (CLI 0.22+) owns the diagnosis. Your job is to run it, do the one
check it structurally cannot do, and act on what comes back. Never hand-edit config
files — every repair goes through the CLI, which carries backup and merge rigor.
Sandboxed surfaces (Claude.ai, Desktop, Cowork) have no npx. If you cannot run
commands, skip to step 2 — it is the more valuable check anyway — then give the user
the command from step 1 to run themselves.
npx -y @tiny-fish/cli@latest doctor --harness claude-code
JSON on stdout: schema_version, cli_version, ok_harnesses, ok_cli, checks[],
harnesses[], repairs[].
Read schema_version before the fields. This skill describes 3 (CLI 0.22+). The command
pins @latest, so a newer CLI can hand you a shape you do not know: above 3, stop reading
fields, show the user --pretty output instead, and rely on step 2 for the verdict. Below
3 a single ok replaces the two verdicts and checks[] carry no scope, so read only
checks[] and the exit code there.
Two verdicts, not one. ok_harnesses answers whether the user's agents can reach
TinyFish; ok_cli answers whether the CLI's own credential works. checks[].scope
(harness, cli, info) says which one a check counts toward, and only the harness scope
moves the exit code — ok_cli: false beside exit 0 is a real state, not a contradiction.
Report it as the CLI's own credential, not as a broken harness.
| Exit | Meaning |
|---|---|
0 |
no harness check failed — ok_cli can still be false |
1 |
a harness check failed — read checks[] |
2 |
doctor could not run; stdout is empty, the reason is on stderr |
A warn is not a failure and does not move the exit code: doctor is saying it could not
check something, not that it is broken. A registration warn whose detail says the key was
not readable, or was not verified, means the key exists but doctor could not test its value
— every Codex install, and any harness whose config redacts the header. Never repair on a
warn, prove it in step 2.
--pretty only when showing a human the list. Never put --debug output in a report —
it is the one channel carrying raw stacks and absolute paths.
harnesses[].proves_harness_reach is false whenever doctor could not prove that this
harness authenticates. For OAuth harnesses it is always false, because the CLI cannot borrow
the harness's token. You are the only one who can close that gap.
--harness claude-code narrows harnesses[] to exactly one entry, so there is no ambiguity about which harness it describes.
Count the TinyFish servers first. A plugin, a CLI-written entry, and an account-level
connector can all be registered at once, all pointing at the same endpoint. doctor inspects
only the one named tinyfish and cannot see its siblings. Note which server it reported on.
Then call search once with a cheap query, and note which server answered — the tool
namespace names it.
| What happens | What it means |
|---|---|
| Results, from the server doctor reported on | Setup works end to end, whatever auth_mode says |
| Results, but from a different TinyFish server | Proves nothing about the flagged registration. Report the working server and the flagged one as still unverified |
Auth error, but doctor says registered: yes |
Registration exists; the credential behind it is broken |
| TinyFish tools absent entirely | Server not loaded in this session — the user must restart the agent |
What a registration: pass proves depends on schema_version. On 2 and 3 an API-key
registration was tested on the wire, so a stale key header is already a fail with a
connect repair beside it. On 1, and on every OAuth or auth_mode: unknown registration
at any version, pass is presence only: doctor read config, not the wire, and a stale key
still passes while every call 401s. Neither version says anything about siblings, and a
healthy sibling will answer cheerfully while the broken one stays broken.
Run only commands that appear in repairs[], and show command before running it. Keep
the order they arrive in: action: auth-login comes before action: connect because
connect writes whichever key is stored, so a dead one has to be replaced first.
npx -y @tiny-fish/cli@latest doctor --fix --harness claude-codenpx -y @tiny-fish/cli@latest doctor --fix --yes; only unattended_safe: true repairs run and the
rest return as skipped. Never report a skipped repair as a fix.unattended_safe: false → hand it to the user, do not run it. Expect most repairs to be
false: auth login always is, and connect <harness> is unsafe for every harness except
Cursor — and on 2 Cursor only while the CLI's own authenticated call passes, since a
revoked key still resolves as a credential. Read the field, do not infer it./mcp, pick tinyfish, and sign in.Re-run step 2 after any repair. Success means showing the real search result — the user should see their agent touch the live web.
Attach doctor's stdout JSON verbatim. It is schema-versioned and already redaction-safe:
undeclared fields are stripped on parse and every message is authored rather than raw. Do
not build your own report, add fields, or paste config contents. On exit 2 there is no
JSON — say so rather than filing an empty report.
Then offer /tinyfish:feedback to file it.
原文・著作権は Anthropic および各プラグイン作者に帰属します。日本語訳は Claude API による自動翻訳です。