Solaris auf SPARC, in QEMU, in einem anderen Mac, verbunden mit einer KI, die
unameausführte, kurz in den Abgrund von 2002 starrte und sagte:„Huh. Komisch. Na ja, ich habe Bash. Verdammt, los geht's.“
Dies ist eine maßgeschneiderte MCP-Steuerungsebene für ein virtuelles Sun-Niagara-Labor.
Beginnen Sie mit der normativen Spezifikation. Die Arbeit ist in der kanonischen TODO-Liste organisiert, und der Beitritts- und Beitragsleitfaden erklärt, wie aus einer Idee ein abgegrenzter Zweig, eine getestete Änderung und ein sauber abgeschlossenes Arbeitspaket wird. Der Projektblog bewahrt die chronologische, respektlose Geschichte, ohne die normativen Dokumente in einen Freitagabend-Wortsalat zu verwandeln. Die Codex-Einrichtung behandelt die direkte Installation auf dem VM-Host und den SSH-stdio-Pfad von einem anderen Rechner.
Es geht nicht darum, einem Agenten eine höfliche kleine Remote-Shell zu geben und so zu tun, als sei ein uralter Solaris-Gast eine normale Cloud-VM. Es geht darum, dem Agenten zu ermöglichen, die Maschine zu bewohnen und ihm gleichzeitig die Art von unmöglicher Röntgenvision zu geben, von der Hardware- und Kernel-Hacker träumen:
eine Shell im Solaris/illumos-SPARC-Gast;
gastnative DTrace: Probes, Aggregationen, Syscall-/Provider-Beweise und das Betriebssystem, das sich in seiner eigenen Muttersprache erklärt;
Out-of-Band-Serien- und Wartungskanäle;
QEMU-Monitor- und Maschinenzustandszugriff;
ein SPARC-bewusstes GDB, das direkt auf die emulierte CPU blickt;
hostseitige eBPF-, perf-, Syscall-, Scheduler- und I/O-Beweise;
VM-Datenträger, Snapshots, Protokolle, Firmware und Lauf-Manifeste; und
ein Beweisbuch, um Fakten von Stimmungen zu trennen.
Die Gastvernetzung ist eines der Dinge, die debuggt werden. Sie ist daher niemals die Voraussetzung für das Debuggen.
Der Nutzen ist eine enge Reparaturschleife für Fehler, die historische und
Virtualisierungsgrenzen überschreiten. Angenommen, Solaris ifconfig spuckt
bei einem unerwarteten ioctl. Der Fehler könnte in Userland-Annahmen, im
illumos-Netzwerkstack, in Ryans emuliertem Solaris-Gerätetreiber, im
sun4v-/Gerätemodell von QEMU oder in der Labor-Konfiguration liegen, die sie
verbindet.
Dieses MCP ist die Apparatur, um das Raten zu verweigern. Reproduzieren Sie das Symptom, formulieren Sie konkurrierende schichtspezifische Hypothesen, beobachten Sie den ioctl mit gastnativem DTrace, inspizieren Sie den Kernel-/Treiberzustand, korrelieren Sie ihn mit QEMU- und Host-Traces, patchen Sie den wahrscheinlichsten Besitzer, bauen Sie neu, starten Sie bewusst neu oder laden Sie neu, und führen Sie denselben unterscheidenden Test erneut aus. Diese iterative schichtübergreifende Schleife ist das Produkt.
Dasselbe gilt, wenn -smp 2 immer noch ein Ein-CPU-Solaris-System erzeugt. Wir
können QEMUs vCPU-Inventar, OpenBoot- und sun4v-Maschinenbeschreibungsdaten,
Solaris-CPU-Erkennungs-/Anhänge-Beweise, debugger-sichtbaren CPU-Zustand und
Host-Threads vergleichen, anstatt „andere Leute haben SMP zum Laufen gebracht“
als umsetzbare Diagnose zu behandeln.
Related MCP server: pwno-mcp
Der Gast ist das primäre Subjekt:
Solaris processes and kernel
↕
SPARC CPU, memory, traps, and devices
↕
QEMU monitor, console, and GDB stub
↕
VM host tracing, networking, and storageDer Agent beginnt auf der Schicht, die dem Symptom am nächsten ist, und überquert Schichten, wann immer ein unterscheidender Test es erfordert. Eine Tatsache sagt immer, woher sie stammt. Eine Gastbeobachtung ist keine QEMU-Beobachtung; eine QEMU-Beobachtung ist keine Host-Beobachtung; und ein heißer Host-Thread ist kein Beweis dafür, dass Solaris Fortschritte macht.
Das ist weniger „SSH in einen Server“ und mehr „Gedankenverschmelzung mit virtualisiertem nacktem SPARC-Metall“.
Das Projekt folgt Ryans Gilfoyle-Hypothesenmethode:
Formulieren Sie konkurrierende, falsifizierbare Hypothesen.
Sagen Sie voraus, was jede Hypothese besagt, dass wir beobachten sollten.
Führen Sie den billigsten Test aus, der sie unterscheidet.
Zeichnen Sie die Beweise sofort auf, einschließlich ihrer Schicht und Herkunft.
Töten Sie schlechte Hypothesen ohne Sentimentalität.
Ändern Sie das System erst, wenn die Beweise vor der Änderung sicher in der Tasche sind.
Keine Séance per Logdatei. Kein Sieg, nur weil die Konsole zuckte. Kein Verwandeln von „Ich weiß nicht“ in eine Seite selbstbewusster Fan-Fiction.
Ryan verbrachte fünf Jahre bei Joyent, und dieses Projekt übernimmt bewusst eine operative Idee von manta-thoth. Thoth nahm illumos-Core- und Crash-Dumps, gab jedem Dump eine stabile Identität, speicherte seine Metadaten und führte benannte Analysatoren dagegen aus. Ein Ingenieur konnte einen Dump interaktiv debuggen, den nützlichen Teil dieser Sitzung in einen Analysator verwandeln und den Analysator auf spätere Dumps anwenden.
Thoth stammt aus der Zeit vor OpenAI. Seine nützliche Idee ist operativ: Debugging sollte die Wiederherstellung nicht als Geisel halten. Der entsprechende Workflow für dieses Labor ist:
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 progressDer versiegelte Fall sollte genügend Material enthalten, um nach dem Verschwinden des ursprünglichen QEMU-Prozesses zu untersuchen: Lauf-Eingaben und Hashes, Konsolenverlauf, QMP-Zustand, Gastspeicher oder einen Crash-Dump, wo unterstützt, Debugger-Erfassungen, Tool-Versionen und Beweis-Herkunft. Analysator-Ergebnisse gehören zum Fall, ohne seine ursprünglichen Beweise umzuschreiben.
Der Dump und der Ersatz sind getrennte Transaktionen. Der festgefahrene Lauf überlebt, bis seine Erfassung lesbar und verifiziert ist. Ein erfolgreicher Dump beweist nicht, dass der Ersatz gebootet hat, und ein bootender Ersatz entschuldigt keinen korrupten oder unvollständigen Dump.
Dieser Lebenszyklus ist geplant, nicht ausgeliefert. SUN-009 definiert inhaltsadressierte Erfassungen und Analysatoren. SUN-010 definiert die Zustandsmaschine für Einfrieren, Versiegeln, Übergabe, Ersatz und Rollback.
Out-of-Band zuerst. Serielle Sockets, QEMU-Monitor und Debugger-Zugriff müssen ein kaputtes Gastnetzwerk überleben.
Nur exakte Ziele. Kein pgrep qemu | head -1-Cowboy-Scheiß, wenn mehrere
unersetzliche Experimente laufen könnten.
Jede Mutation beichtet. Monitorsteuerungen, Signale, Debugger-Schreibvorgänge, Registerlesevorgänge mit bestätigten Nebenwirkungen und Datenträgeroperationen werden als zustandsändernd gekennzeichnet.
Debugger abkoppeln. Eine clevere Diagnose, die stillschweigend jede vCPU stoppt, ist nicht clever.
Ein Schreiber bedeutet ein Schreiber. Gemeinsame Kanäle werden nicht zuverlässiger, wenn drei veraltete Bridge-Prozesse darum kämpfen.
Niemals Ctrl-C auf QEMUs Steuerterminal. Wir haben für diese Lektion bereits Lehrgeld bezahlt.
Snapshots vor Verbrechen. Reproduzierbare Verbrechen sind Wissenschaft.
Beweise schlagen Selbstvertrauen. Besonders wenn das Selbstvertrauen ein Sun-Microsystems-T-Shirt trägt.
Die beabsichtigten Werkzeugfamilien sind explizit in Bezug auf die Schicht, auf der sie arbeiten:
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 rolloverRoher Expertenzugriff ist ein Feature, keine Peinlichkeit. Die Antwort auf
gefährliche Macht ist präzises Targeting, begrenzte Ausführung, sichtbare
Effekte und wiederherstellbare Experimente – nicht jedes Werkzeug so weit
abzuschleifen, bis es nur noch hello world drucken kann.
DTrace im Gast und eBPF/perf außerhalb von QEMU sind komplementäre Röntgenwinkel. Keiner wird in Beweise aus der anderen Schicht erhoben: Eine DTrace-Probe beschreibt Solaris; eine Host-Probe beschreibt den Emulatorprozess. Wenn sie sich über die Virtualisierungsgrenze hinweg einig sind, dann läuft's.
Der portable 0.1-Kern ist implementiert, und das erste Live-Profil ist bewiesen. Strikte Konfiguration, validierte Lauf-Identität, Gast-/HMP-/QMP-/Host-Adapter, unveränderliche Beweis- und Hypothesenhistorie und der MCP-stdio-Server sind durch 58 Tests abgedeckt. CI führt die portable Suite auf macOS und Linux aus.
Das Niagara-Profil wurde auch gegen einen Live-QEMU-10.2-Lauf getestet. Es
bewies die exakte PID, fragte QMP über einen privaten Unix-Socket ab, erfasste
SPARC-v9-Register und -Anweisungen mit gdb-multiarch, koppelte ab und bewies
unabhängig, dass QEMU zu running zurückkehrte. Eine frische Codex-CLI auf dem
VM-Host entdeckte dann den Lauf und fragte seinen Status nur mit MCP-Tools ab.
Gast-DTrace-Rezepte, benannte Host-eBPF/perf-Rezepte, der semantische Klassifikator des Projekts, inhaltsadressierte Diagnose-Erfassungen und automatischer Wedge-Rollover bleiben verfolgte Arbeit und keine beworbene Magie.
Die Box ist alt. Die Debugging-Ausrüstung nicht.
Ziemlich!
**Ich lehne mich in den KI-Slop-Schreibstil hinein, anstatt zu versuchen, wie ein Dichter zu wirken. Erwarten Sie em-dash-Juwelen wie „Der Geist ist eingefangen, aber niemand – einschließlich des zukünftigen Ryan – kann schnell sagen, was die Software verspricht oder was als Nächstes zu tun ist.“ in großen Portionen.**
Es gibt hier keine Illusionen, dass Ryan vollständig geformt aus der Stirn von Bill Joy hervorgegangen ist, bereits fließend in sun4v-Interna. Dieses Projekt wird durch Neugier, Experimente, KI-Zusammenarbeit, alte Dokumentation, neue Beweise und die gelegentliche äußerst produktive schlechte Idee aufgebaut.
Das macht Disziplin wichtiger, nicht weniger. Die SPEC sagt, was das System tun muss. Tests beweisen, was es tatsächlich tut. Das Beweisbuch zeichnet auf, was wir tatsächlich beobachtet haben. Der Beitrags-Workflow hält einen vielversprechenden Hack davon ab, stillschweigend zu einer archäologischen Schicht zu werden.
| 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.
Linux microVM sandboxes for AI agents: run commands, files, processes, pause and wake.
Attestable memory for AI agents: curated writes, verifiable tenant isolation, bi-temporal facts.
