SPARC上のSolarisが、QEMUの中、さらに別のMacの中にあり、
unameを実行し、 2002年の深淵を一瞬のぞき込んで、こう言ったAIに配線されている：「へえ。変だな。まあいいや、Bashがある。やろうぜ。」
これは、仮想Sun Niagaraラボ向けの特注MCPコントロールプレーンです。
規範仕様書から始めてください。作業は正規のTODOリストで整理され、参加と貢献のガイドは、アイデアがどのようにスコープされたブランチ、テスト済みの変更、そしてきれいにクローズされた作業になるかを説明します。プロジェクトブログは、規範ドキュメントを金曜夜の言葉のサラダに変えることなく、時系列の不遜な物語を保ちます。Codexセットアップは、VMホストへの直接インストールと、別のマシンからのSSH stdioパスをカバーします。
要点は、エージェントにおとなしい小さなリモートシェルを与えて、古のSolarisゲストを普通のクラウドVMだと偽ることではありません。要点は、エージェントにマシンに宿ることを許し、同時にハードウェアやカーネルハッカーが夢見るような不可能なX線視力を与えることです：
Solaris/illumos SPARCゲスト内のシェル；
ゲストネイティブのDTrace：プローブ、集約、syscall/プロバイダの証跡、そしてオペレーティングシステムが自らの母語で自己説明すること；
帯域外のシリアルおよびメンテナンスチャネル；
QEMUモニタとマシン状態へのアクセス；
エミュレートされたCPUを直接見るSPARC対応GDB；
ホスト側のeBPF、perf、syscall、スケジューラ、I/Oの証跡；
VMディスク、スナップショット、ログ、ファームウェア、実行マニフェスト；そして
事実と雰囲気を分離するための証拠台帳。
ゲストネットワーキングは、まさにデバッグ対象のひとつです。したがって、それはデバッグの前提条件になることは決してありません。
その見返りは、歴史的境界と仮想化境界をまたぐ障害に対するタイトな修復ループです。Solarisのifconfigが予期しないioctlでエラーを吐くとしましょう。バグは、ユーザーランドの前提、illumosネットワーキングスタック、RyanのエミュレートされたSolarisデバイスドライバ、QEMUのsun4v/デバイスモデル、あるいはそれらを接続するラボ構成に存在するかもしれません。
このMCPは、推測を拒否するための装置です。症状を再現し、競合するレイヤー固有の仮説を述べ、ゲストDTraceでioctlを観察し、カーネル/ドライバの状態を検査し、QEMUおよびホストのトレースと相関させ、最も可能性の高い所有者にパッチを当て、再ビルドし、意図的に再起動またはリロードし、同じ判別テストを再度実行します。その反復的なクロスレイヤーループこそが成果物です。
-smp 2でもまだ1 CPUのSolarisシステムになる場合も同じです。「他の人たちはSMPを動かせた」を実行可能な診断として扱う代わりに、QEMUのvCPUインベントリ、OpenBootおよびsun4vマシン記述データ、SolarisのCPU検出/アタッチの証跡、デバッガから見えるCPU状態、ホストのスレッドを比較できます。
Related MCP server: anyvm-mcp
ゲストが第一の主体です：
Solaris processes and kernel
↕
SPARC CPU, memory, traps, and devices
↕
QEMU monitor, console, and GDB stub
↕
VM host tracing, networking, and storageエージェントは症状に最も近いレイヤーから始め、判別テストが要求するときはいつでもレイヤーをまたぎます。事実は常に、それがどこから来たのかを述べます。ゲストの観測はQEMUの観測ではなく、QEMUの観測はホストの観測ではなく、ホストのホットスレッドはSolarisが前進している証拠ではありません。
これは「サーバーへのSSH」というより、「仮想化されたベアSPARCメタルとのマインドメルト」に近いものです。
このプロジェクトは、RyanのGilfoyle仮説メソッドに従います：
競合する反証可能な仮説を述べる。
各仮説が何を観測すべきだと述べているかを予測する。
それらを区別する最も安価なテストを実行する。
レイヤーと来歴を含め、証拠をすぐに記録する。
悪い仮説を感傷なしに殺す。
変更前の証拠が安全に確保されて初めて、システムを変更する。
ログファイルによる降霊会はしない。コンソールがピクッと動いたからといって勝利を宣言しない。「わからない」を自信満々のファンフィクションの1ページに変えない。
RyanはJoyentで5年間過ごし、このプロジェクトはmanta-thothから運用上のアイデアを意図的に借用しています。Thothはillumosのコアダンプとクラッシュダンプを受け取り、各ダンプに安定したアイデンティティを与え、そのメタデータを保存し、名前付きアナライザを実行しました。エンジニアは1つのダンプを対話的にデバッグし、そのセッションの有用な部分をアナライザに変え、そのアナライザを後のダンプに適用できました。
ThothはOpenAIより前からあります。その有用なアイデアは運用上のものです：デバッグが復旧を人質にしてはならない。このラボに対応するワークフローは次のとおりです：
wedged VM
-> freeze the exact run
-> capture and hash its diagnostic state
-> verify the capture is durable
-> hand the case to offline debugging and named analyzers
known inputs
-> start a replacement VM
-> prove its identity and boot progress封印されたケースには、元のQEMUプロセスが消えた後でも調査するのに十分な材料が含まれているべきです：実行入力とハッシュ、コンソール履歴、QMP状態、サポートされていればゲストメモリまたはクラッシュダンプ、デバッガキャプチャ、ツールバージョン、証拠の来歴。アナライザの結果は、元の証拠を書き換えることなくケースに属します。
ダンプと置き換えは別々のトランザクションです。ハングした実行は、そのキャプチャが読み取り可能で検証されるまで生存します。ダンプの成功は置き換えがブートしたことを証明せず、ブートする置き換えは、破損または不完全なダンプを正当化しません。
このライフサイクルは計画済みであり、出荷済みではありません。SUN-009はコンテンツアドレス型キャプチャとアナライザを定義します。SUN-010はフリーズ、封印、ハンドオフ、置き換え、ロールバックのステートマシンを定義します。
帯域外を最優先。 シリアルソケット、QEMUモニタ、デバッガアクセスは、壊れたゲストネットワークでも生き残らなければなりません。
正確なターゲットのみ。 かけがえのない実験がいくつも実行されているかもしれないときに、pgrep qemu | head -1のようなカウボーイ的ないい加減な真似をしてはいけません。
すべての変更は告白する。 モニタ制御、シグナル、デバッガ書き込み、確認済みの副作用を伴うレジスタ読み取り、ディスク操作は、状態を変更するものとしてラベル付けされます。
デバッガを切り離せ。 すべてのvCPUを静かに停止させたままにする巧妙な診断は、巧妙ではありません。
書き手は一人だけ。 共有チャネルは、3つの古いブリッジプロセスが奪い合っても、より信頼性が高くなることはありません。
QEMUの制御端末でCtrl-Cを押すな。 その教訓にはすでに学費を払いました。
犯罪の前にスナップショット。 再現可能な犯罪は科学です。
証拠は自信に勝る。 特にその自信がSun MicrosystemsのTシャツを着ているときは。
意図されたツールファミリーは、それらが操作するレイヤーについて明示的です：
lab.* run discovery, intent, health, and manifests
guest.* bounded guest commands, console evidence, and DTrace
qemu.* HMP/QMP queries and deliberate machine control
debugger.* SPARC register, instruction, memory, and backtrace capture
host.trace.* bounded eBPF/perf/process investigations
evidence.* append-only observations and artifact references
hypothesis.* predictions, discriminating tests, and falsification
capture.* planned immutable diagnostic cases and content identity
analyzer.* planned offline metadata extraction and diagnosis
lifecycle.* planned wedge capture and replacement-VM rollover生のエキスパートアクセスは機能であり、恥ずかしいものではありません。危険な力への答えは、正確なターゲティング、制限された実行、可視化された効果、そして回復可能な実験です——すべてのツールをhello worldしか出力できなくなるまで削り落とすことではありません。
ゲスト内のDTraceとQEMU外部のeBPF/perfは、相補的なX線アングルです。どちらも他方のレイヤーからの証拠に昇格しません：DTraceプローブはSolarisを記述し、ホストプローブはエミュレータプロセスを記述します。それらが仮想化境界を越えて一致したとき、これでようやく本領発揮です。
ポータブル0.1コアが実装され、最初のライブプロファイルが実証されました。 厳格な構成、検証済みの実行アイデンティティ、ゲスト/HMP/QMP/ホストアダプタ、不変の証拠と仮説履歴、そしてMCP stdioサーバーは58のテストでカバーされています。CIはmacOSとLinuxでポータブルスイートを実行します。
Niagaraプロファイルは、ライブのQEMU 10.2実行に対しても試されました。正確なPIDを証明し、プライベートUnixソケット経由でQMPにクエリし、gdb-multiarchでSPARC v9のレジスタと命令をキャプチャし、デタッチし、QEMUがrunningに戻ったことを独立に証明しました。VMホスト上の新しいCodex CLIは、その後、MCPツールだけを使って実行を発見し、そのステータスにクエリしました。
ゲストDTraceレシピ、名前付きホストeBPF/perfレシピ、プロジェクトの意味論的クラシファイア、コンテンツアドレス型診断キャプチャ、自動ウェッジロールオーバーは、宣伝された魔法ではなく、追跡中の作業のままです。
ボックスは古い。デバッグ装置は古くない。
かなり！
**私は詩人のふりをするのではなく、AIスロップ的な文体に意図的に寄せています。「精神は捉えられたが、誰も——未来のRyanを含め——ソフトウェアが何を約束し、次に何をすべきかをすぐには言えない。」のようなemダッシュの宝石がたっぷり出てくると思ってください。**
Ryanがビル・ジョイの額から完全な姿で生まれ、すでにsun4v内部に精通していたという幻想はここにはありません。このプロジェクトは、好奇心、実験、AIコラボレーション、古いドキュメント、新しい証拠、そして時折の非常に生産的な悪いアイデアを通じて構築されています。
それによって規律はより重要になります。SPECはシステムが何をすべきかを述べます。テストはそれが実際に何をするかを証明します。証拠台帳は私たちが実際に観測したものを記録します。コントリビューターワークフローは、有望なハックが静かに考古学的な層になるのを防ぎます。
| Name | Required | Description | Default |
|---|---|---|---|
| run | Yes | ||
| reason | Yes | ||
| profile | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| run | Yes | ||
| limit | No | ||
| after_id | No | ||
| investigation_id | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| run | Yes | ||
| claim | Yes | ||
| layer | Yes | ||
| notes | No | ||
| source | Yes | ||
| investigation_id | Yes | ||
| tool_result_digest | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| run | Yes | ||
| max_bytes | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| run | Yes | ||
| reason | Yes | ||
| adapter | No | ||
| command | Yes | ||
| timeout_seconds | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| run | Yes | ||
| sample_seconds | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| run | Yes | ||
| reason | Yes | ||
| recipe | Yes | ||
| duration_seconds | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| run | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| run | Yes | ||
| statement | Yes | ||
| predictions | Yes | ||
| investigation_id | Yes | ||
| discriminating_tests | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| run | Yes | ||
| reason | Yes | ||
| status | Yes | ||
| evidence_ids | Yes | ||
| hypothesis_id | Yes | ||
| investigation_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| run | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| run | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| include_stopped | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| run | Yes | ||
| reason | Yes | ||
| command | Yes | ||
| timeout_seconds | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| run | Yes | ||
| command | Yes | ||
| timeout_seconds | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| run | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0debugger.captureevidence.readevidence.recordguest.console_tailguest.exechost.process_samplehost.tracehost.trace_capabilitieshypothesis.starthypothesis.updatelab.classifylab.describe_runlab.list_runsqemu.hmp_controlqemu.hmp_queryqemu.statusScored across 16 tools
Several tool names overlap in intent: debugger.capture, evidence.record, and host.trace all imply capturing observational data, while qemu.hmp_query and qemu.status both seem to query VM state. Without descriptions, an agent could easily select the wrong tool for a task.
Tools consistently use a dotted domain prefix such as host., guest., qemu., lab., and evidence., which creates a clear namespace. The second segment is less uniform (verbs, nouns, and verb_noun forms), so it is not perfectly consistent, but the overall convention is predictable.
16 tools is slightly above the typical well-scoped range but justified by the breadth of a debugging/forensics server spanning host tracing, guest execution, QEMU control, evidence management, and lab workflows. It feels comprehensive rather than bloated.
The set covers start/read actions well but lacks lifecycle closures: hypothesis.start has no hypothesis.end or hypothesis.cancel, evidence.record/read has no evidence.delete/list, and there is no clear stop/cleanup for host.trace or debugger.capture. These gaps create dead ends in common workflows.
Shared debugging memory for AI coding agents
Run, build, and validate firmware on virtual hardware from your AI agent. Hardware knowledge corpus.
Persistent Linux microVMs for agents: root, internet, sub-second resume and a public URL.
Long-term memory for AI agents: bitemporal fact ledger, contradiction detection, explainability.
