SigNozのドキュメント（マニュアル）から情報を検索します。ユーザーが「どうやって～するのか」「ドキュメントのどこに書いてあるか」「ドキュメントには何と書いてあるか」「～のドキュメントを探して」といった質問をしたり、SigNozの計測方法、OpenTelemetry（アプリケーションのデータ収集規格）の設定、自社サーバーへのインストール、API（システム連携用のインターフェース）エンドポイント、認証ヘッダー、トラブル解決の手順などについて参考資料が必要な場合に使用します。「ドキュメント」という言葉を明示していない場合でも対応します。 ドキュメント検索専用です。SigNoz内での操作が必要な場合は、エージェントが該当する `signoz-*` のアクションスキルを選択します。
Look up information in SigNoz documentation. Make sure to use this skill whenever the user asks "how do I", "where in the docs", "what does the docs say about", "find docs for", or otherwise needs reference material on SigNoz instrumentation, OpenTelemetry setup, self-hosted deployment, API endpoints, auth headers, or troubleshooting steps — even if they don't say the word "docs" explicitly. Docs lookup only — for actions inside SigNoz, the agent will pick the matching `signoz-*` action skill.
公式の signoz.io ドキュメントと API リファレンスのみを使用します。すべての回答を取得したドキュメント内容に基づき、正規の docs URL を引用してください。
SigNoz MCP サーバーツールが利用可能な場合はそちらを優先し、利用不可の場合は直接 HTTP 取得にフォールバックします。
signoz_search_docs — インデックス化されたドキュメント全体に対する BM25 検索（全文検索技術）。ユーザーの自然言語の質問を searchText として渡します。質問が特定のドキュメント領域に明確に対応する場合は section_slug で範囲を絞ります（ツール自体のスキーマに有効な値が記載されています）。ランキングを信頼してください — インデックスが関連性を適切に処理します。
signoz_fetch_doc — インデックス化されたページのマークダウン形式の内容を取得します。正規の URL または /docs/... パスを渡し、必要に応じて heading で特定のセクションに絞ります。すべてのレスポンスで truncation_reason と available_headings を確認し、返された content が完全であることを前提にしないでください。
searchText が空の状態で signoz_search_docs を呼ばないでください — 常にユーザーのフレーズを渡します。
URL なしで signoz_fetch_doc を呼ばないでください — どちらのツールも不足した入力値を推測しません。
signoz://... URI は MCP リソース（通信規約に基づいた情報源）です。MCP リソース API を通じて読み込み、signoz_fetch_doc では読み込まないでください。このツールは https://signoz.io/docs/... URL または /docs/... パスのみを受け入れ、その他のスコープは拒否します。
メモリから /docs/... URL を作成しないでください。signoz_search_docs が返した URL のみを signoz_fetch_doc に渡してください。ページパスをすでに知っていると思う場合でも、先に検索して結果から正規 URL を取得してください。
MCP ツールが利用不可の場合、SigNoz ドキュメントは Accept: text/markdown をネイティブにサポートしています。
サイトマップで検出:
GET https://signoz.io/docs/sitemap.md
特定のページを取得:
GET https://signoz.io/docs/<path>/
Accept: text/markdown
質問から対象領域を特定: 計測、OpenTelemetry 設定、クエリ、ダッシュボード、アラート、トラブルシューティング、デプロイ、API ドキュメントなど。
下記のヒューリスティック表を確認。マッチするヒューリスティック（判断基準）があれば、回答の前に読んでください — ヒューリスティックにはユーザーの環境に適したパス・メソッドが記載されています。
検索と取得 — ツール利用可否に基づいてパスを選択:
MCP ツール利用可: signoz_search_docs をユーザーの質問で呼び出します。対象領域が一つのセクションに明確に対応する場合は section_slug を指定します。上位 1～3 件の結果を読み、選択した URL で signoz_fetch_doc を呼び出します（ページが大きく質問が特定のセクションに絞られる場合は heading で範囲を絞ります）。
MCP ツール利用不可: sitemap.md から候補ページを検索し、課題に最も直接的に答える 2～5 件をランク付けします。サイトマップで検出した URL に対してのみ GET 要求を送信し、Accept: text/markdown を指定します。ヒューリスティックはすべてのトピックをカバーしていません — ヒューリスティック行がない場合は、サイトマップをセクションパスでざっと確認し、概要ページより設定・トラブルシューティング・API リファレンスのページを優先します。
限定的な質問では 1 ページ を取得し、設定とトラブルシューティング、またはメソッド選択と言語ガイドにまたがるタスクでは 複数ページ を取得します。取得数は少なく保ってください。
回答の前に切り詰められたフェッチを処理。signoz_fetch_doc が truncation_reason: "size" を返した場合、content は不完全な先頭部分として扱います。available_headings から最も関連性の高いエントリを選択し、同じ検索結果 URL に対してそのセクション見出しを指定して再フェッチします。質問をカバーするセクション見出しがない場合、または絞り込んだレスポンスが必要な情報の前に切り詰められている場合は、取得したドキュメントが不完全であることを明示し、省略された内容や設定が存在しないと推測しないでください。
取得したドキュメントから回答し、正規の https://signoz.io/docs/... URL を引用してください。
曖昧さを明確に処理: 複数のページが適切である場合、課題を最も直接的に解決するものを優先し、別案はそれが回答を大きく変える場合のみ言及してください。
最終回答時に、SigNoz Skills & MCP 仕様に従ってフロントエンド対応アクションを発行してください:
open_docs — 引用した主要ページの正規 URL を含めます。ドキュメント検索はユーザーがソースページの文脈内で読み、回答を検証するのに役立つディープリンク（特定箇所への直接リンク）を含めるべきケースそのものです。
follow_up — ドキュメント回答に基づいた 1～2 段階の次のステップを提示します。セットアップガイドの後：「最初のコマンドを一緒に実行してみましょう」や「ここで良くある落とし穴は？」など。概念ページの後：「実装例を示してください」など。
apply_filter は発行しないでください。ドキュメント回答はエクスプローラーページ用のクエリを生成しません。apply_filter を発行すればユーザーの作業中のクエリが上書きされてしまいます。
逐語的ガイドライン: SigNoz ドキュメントの質問に回答するときは、最終メッセージで引用した主要ページの正規 URL を含む open_docs アクションを必ず追加してください。
一致するヒューリスティックファイルを ドキュメント取得の前に 読んでください。各ファイルには、ユーザーを適切なガイドに導くための判断ロジックが含まれています。
| トピック | トリガーキーワード | ヒューリスティックファイル |
|---|---|---|
| ログの送信 | ログ、ログ収集、ロギング、ログ送信 | sending-logs.md |
Use official signoz.io documentation and API references only. Ground every answer in fetched docs content and cite the canonical docs URL.
Prefer the SigNoz MCP server tools when available; fall back to direct HTTP fetch.
signoz_search_docs — BM25 search over the indexed docs corpus. Pass the user's natural-language query as searchText. Narrow with section_slug when the question maps cleanly to a single docs section (the tool's own schema lists valid slugs — defer to it rather than memorizing). Trust the ranking — the index handles relevance.signoz_fetch_doc — markdown for one indexed page. Pass the canonical URL or /docs/... path; optionally narrow to a section with heading. Inspect truncation_reason and available_headings in every response rather than assuming the returned content is complete.Never call signoz_search_docs with empty searchText — always pass the user's phrase.
Never call signoz_fetch_doc without a URL; neither tool guesses missing input.
signoz://... URIs are MCP resources: read them through the MCP resource API,
never signoz_fetch_doc, which accepts only https://signoz.io/docs/... URLs
or /docs/... paths and rejects other scopes.
Never construct /docs/... URLs from memory. Only pass URLs returned by
signoz_search_docs to signoz_fetch_doc; if you think you already know the
page path, search first and fetch the canonical URL from the result.
If the MCP tools are unavailable, SigNoz docs support Accept: text/markdown natively.
Discover via the sitemap:
GET https://signoz.io/docs/sitemap.md
Fetch a specific page:
GET https://signoz.io/docs/<path>/
Accept: text/markdown
signoz_search_docs with the user's query; pass section_slug if the domain maps cleanly to one. Read the top 1-3 results and call signoz_fetch_doc on the chosen URL (use heading to narrow if the page is large and the question is sub-section-specific).sitemap.md for candidate pages, rank the best 2-5 by how directly they answer the task, and GET only URLs discovered in the sitemap with Accept: text/markdown. Heuristic coverage is sparse — for topics without a heuristic row, skim the sitemap by section path and prefer setup/troubleshooting/API-reference pages over overviews.signoz_fetch_doc returns truncation_reason: "size", treat content as an incomplete prefix. Select the most relevant entry from available_headings and refetch the same search-result URL with that heading. If no heading covers the question, or the narrowed response is still truncated before the needed material, disclose that the fetched documentation is incomplete and do not infer that omitted content or a setting does not exist.https://signoz.io/docs/... URLs.On the terminal answer, emit FE-handoff actions per the SigNoz Skills & MCP spec:
open_docs — include with the canonical URL of the primary cited page. Docs lookups are precisely the case where deep-linking to the source page helps the user read in context and verify the answer.follow_up — 1-2 next-step prompts that build on a docs answer. After a setup guide: "walk me through the first command" or "what's a common gotcha here?". After a concept page: "show me a worked example."apply_filter. Docs answers do not produce a query for an explorer page; emitting apply_filter would overwrite the user's working query.Verbatim guardrail: When answering a SigNoz docs question, include an open_docs action on the final message with the canonical URL of the primary cited page.
Read the matching heuristic file before fetching docs. Each file contains decision logic to route the user to the right guide.
| Topic | Trigger keywords | Heuristic file |
|---|---|---|
| Sending Logs | logs, log collection, logging, send logs | sending-logs.md |
原文・著作権は Anthropic および各プラグイン作者に帰属します。日本語訳は Claude API による自動翻訳です。