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、Desktop、Coworkなどのサンドボックス環境では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より小さい場合は、単一の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 |
ハーネス・チェックに失敗なし——ok_cliはfalseの場合がある |
1 |
ハーネス・チェックが失敗——checks[]を読む |
2 |
doctorが実行できない；標準出力は空、理由は標準エラーに出力 |
warn（警告）は失敗ではなく、終了コードを変更しません：doctorは何かをチェックできなかったと言っているのであって、それが壊れていると言っているのではありません。登録に関する警告で、詳細がキーが読み取り不可またはベリファイ（確認）されなかったと言う場合、キーは存在するがdoctorはその値をテストできなかった——すべてのCodexインストール、およびヘッダーを隠す設定を持つハーネスに該当します。警告に基づいて修復しないでください。ステップ2でそれを証明してください。
--prettyは人間に情報を表示するときだけ使用してください。報告に--debug出力を含めないでください——生のスタックトレースと絶対パスを含む唯一のチャネルです。
harnesses[].proves_harness_reachは、doctorがこのハーネスが認証することを証明できなかった場合、常にfalseです。ハーネス自身のクライアントがライブな接続を報告するか、doctorが読むことができたキーが通信線上でベリファイされた場合のみtrueになります——CLIはOAuthトークンを借りることができないため、接続状態を報告しないすべてのハーネスはその穴埋めをあなたに任せます。
--harness claude-codeはharnesses[]を正確に1つのエントリに限定するため、どのハーネスについて説明しているかに曖昧さがありません。
最初にTinyFishサーバーを数えてください。 プラグイン、CLI書き込みエントリ、およびアカウントレベルのコネクター（接続設定）がすべて同時に登録され、すべて同じエンドポイントをポイントすることができます。doctorはtinyfishという名前のもののみを検査し、その兄弟姉妹は見えません。どのサーバーについて報告したかをメモしてください。
次に、低コストのクエリ（問い合わせ）でsearchを1回呼び出し、どのサーバーが応答したかをメモしてください——ツール名前空間がそれを示しています。
| 何が起こったか | 意味 |
|---|---|
| 結果が、doctorが報告したサーバーから返された | セットアップは端から端まで機能する、auth_modeが何だろうと |
| 結果が返されたが、異なる TinyFishサーバーから | フラグが立てられた登録についての証明なし。機能しているサーバーと、フラグが立てられたサーバーの両方を未確認として報告してください |
認証エラー、ただしdoctorはregistered: yesと言っている |
登録は存在する；その背後にある認証情報は壊れている |
| TinyFishツールが完全に不在 | サーバーがこのセッションで読み込まれていない——ユーザーはエージェントを再起動する必要があります |
registration: passが何を証明するかはschema_versionに依存します。2と3ではAPIキー登録は通信線上でテストされたため、古いキーヘッダーはすでにconnect修復を伴うfailです。proves_harness_reach: trueを持つpassing（成功）はハーネス自身のクライアントがライブな接続を報告する——どのバージョンでも、auth_modeが何だろうと通信線での証拠です。その他のpassingはプレゼンス（存在）のみ：doctorは設定を読みましたが、通信線は読んでおらず、古いキーはpassの状態で、すべての呼び出しが401エラー（認証失敗）を返す可能性があります。どのバージョンも兄弟姉妹については何も言いません。健全な兄弟姉妹は陽気に応答する一方で、壊れたものは壊れたままです。
repairs[]に表示されるコマンドのみを実行し、実行前にcommandを表示してください。これらはtinyfish …として到着します。グローバルインストールがない場合、先頭の単語をnpx -y @tiny-fish/cli@latestに置き換えてください。到着した順序を保ってください：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は常にそうで、connect <harness>はCursor以外のすべてのハーネスで安全ではありません——2と3ではCursorのみ、CLI自身の認証済み呼び出しがpassingする場合。フィールドを読み、推測しないでください。/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. It is true only where the harness's own client reports a live
connection, or where a key doctor could read verified on the wire — the CLI cannot borrow an
OAuth token, so every harness that reports no connection state leaves the gap to you.
--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. A pass carrying proves_harness_reach: true is the harness's own
client reporting a live connection — wire evidence at any version, whatever auth_mode says.
Every other pass is presence only: doctor read config, not the wire, and a stale key still
passes while every call 401s. No 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. They
arrive as bare tinyfish …, which is not on PATH under npx — swap that leading word for
npx -y @tiny-fish/cli@latest when there is no global install. 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 and 3 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 による自動翻訳です。