Solaris en SPARC, dentro de QEMU, dentro de otro Mac, conectado a una IA que ejecutó
uname, miró brevemente al abismo de 2002 y dijo:«Eh. Qué raro. Bueno, tengo Bash. Joder, vamos.»
Este es un plano de control MCP hecho a medida para un laboratorio virtual Sun Niagara.
Empieza con la especificación normativa. El trabajo se organiza en la lista TODO canónica, y la guía de incorporación y contribución explica cómo una idea se convierte en una rama acotada, un cambio probado y una pieza de trabajo cerrada limpiamente. El blog del proyecto mantiene la historia cronológica e irreverente sin convertir los documentos normativos en ensalada de palabras de viernes por la noche. La configuración de Codex cubre la instalación directa en el host de la VM y la ruta stdio SSH desde otra máquina.
El objetivo no es darle a un agente una pequeña y educada shell remota y fingir que un antiguo invitado Solaris es una VM de nube normal. El objetivo es dejar que el agente habite la máquina mientras le da también ese tipo de visión de rayos X imposible con la que sueñan los hackers de hardware y kernel:
una shell dentro del invitado SPARC Solaris/illumos;
DTrace nativo del invitado: sondas, agregaciones, evidencia de syscalls/providers, y el sistema operativo explicándose a sí mismo en su lengua nativa;
canales de mantenimiento y serie fuera de banda;
acceso al monitor de QEMU y al estado de la máquina;
un GDB consciente de SPARC mirando directamente a la CPU emulada;
evidencia de eBPF, perf, syscall, scheduler y E/S del lado del host;
discos de VM, instantáneas, registros, firmware y manifiestos de ejecución; y
un libro de contabilidad de evidencia para mantener los hechos separados de las vibraciones.
La red del invitado es una de las cosas que se están depurando. Por lo tanto, nunca es el requisito previo para depurarla.
La recompensa es un ciclo de reparación ajustado para fallos que cruzan fronteras históricas y de virtualización. Supongamos que ifconfig de Solaris vomita ante un ioctl inesperado. El error podría vivir en suposiciones del espacio de usuario, en la pila de red de illumos, en el controlador de dispositivo Solaris emulado de Ryan, en el modelo sun4v/dispositivo de QEMU, o en la configuración del laboratorio que los conecta.
Este MCP es el aparato para negarse a adivinar. Reproduce el síntoma, formula hipótesis competitivas específicas de cada capa, observa el ioctl con DTrace del invitado, inspecciona el estado del kernel/controlador, correlaciónalo con trazas de QEMU y del host, parchea al propietario más probable, reconstruye, reinicia o recarga deliberadamente, y vuelve a ejecutar la misma prueba discriminatoria. Ese bucle iterativo entre capas es el producto.
Lo mismo aplica cuando -smp 2 todavía produce un sistema Solaris de una sola CPU. Podemos comparar el inventario de vCPU de QEMU, los datos de descripción de máquina de OpenBoot y sun4v, la evidencia de descubrimiento/adjunción de CPU de Solaris, el estado de CPU visible para el depurador y los hilos del host, en lugar de tratar «a otras personas les funcionó SMP» como un diagnóstico accionable.
Related MCP server: pwno-mcp
El invitado es el sujeto principal:
Solaris processes and kernel
↕
SPARC CPU, memory, traps, and devices
↕
QEMU monitor, console, and GDB stub
↕
VM host tracing, networking, and storageEl agente comienza en la capa más cercana al síntoma y cruza capas siempre que una prueba discriminatoria lo requiera. Un hecho siempre dice de dónde vino. Una observación del invitado no es una observación de QEMU; una observación de QEMU no es una observación del host; y un hilo del host muy activo no es prueba de que Solaris esté progresando.
Esto es menos «hacer SSH a un servidor» y más «fusión mental con metal SPARC desnudo virtualizado».
El proyecto sigue el método de hipótesis de Ryan Gilfoyle:
Formula hipótesis competitivas y falsables.
Predice qué deberíamos observar según cada hipótesis.
Ejecuta la prueba más barata que las distinga.
Registra la evidencia de inmediato, incluyendo su capa y procedencia.
Mata las malas hipótesis sin sentimentalismo.
Cambia el sistema solo después de que la evidencia previa al cambio esté a salvo en el bolsillo.
Nada de sesiones espiritistas basadas en archivos de registro. Nada de declarar victoria porque la consola tuvo un espasmo. Nada de convertir «no lo sé» en una página de fan fiction confiada.
Ryan pasó cinco años en Joyent, y este proyecto toma prestada a propósito una idea operativa de manta-thoth. Thoth tomaba volcados de núcleo y de pánico de illumos, daba a cada volcado una identidad estable, almacenaba sus metadatos y ejecutaba analizadores con nombre contra él. Un ingeniero podía depurar un volcado interactivamente, convertir la parte útil de esa sesión en un analizador y aplicar el analizador a volcados posteriores.
Thoth es anterior a OpenAI. Su idea útil es operativa: la depuración no debería tomar como rehén a la recuperación. El flujo de trabajo correspondiente para este laboratorio es:
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 progressEl caso sellado debería contener suficiente material para investigar después de que el proceso original de QEMU haya desaparecido: entradas de ejecución y hashes, historial de consola, estado de QMP, memoria del invitado o un volcado de pánico donde se admita, capturas del depurador, versiones de herramientas y procedencia de la evidencia. Los resultados del analizador pertenecen al caso sin reescribir su evidencia original.
El volcado y el reemplazo son transacciones separadas. La ejecución atascada sobrevive hasta que su captura sea legible y verificada. Un volcado exitoso no prueba que el reemplazo haya arrancado, y un reemplazo que arranca no excusa un volcado corrupto o incompleto.
Este ciclo de vida está planificado, no implementado. SUN-009 define capturas y analizadores direccionados por contenido. SUN-010 define la máquina de estados de congelación, sellado, traspaso, reemplazo y reversión.
Primero lo fuera de banda. Los sockets serie, el monitor de QEMU y el acceso del depurador deben sobrevivir a una red de invitado rota.
Solo objetivos exactos. Nada de mierda de vaquero con pgrep qemu | head -1 cuando pueden estar ejecutándose varios experimentos irremplazables.
Toda mutación confiesa. Los controles del monitor, las señales, las escrituras del depurador, las lecturas de registros con efectos secundarios reconocidos y las operaciones de disco están etiquetadas como cambios de estado.
Desconecta el depurador. Un diagnóstico ingenioso que silenciosamente deja cada vCPU detenida no es ingenioso.
Un escritor significa un escritor. Los canales compartidos no se vuelven más fiables cuando tres procesos puente obsoletos pelean por ellos.
Nunca Ctrl-C en la terminal de control de QEMU. Ya hemos pagado la matrícula por esa lección.
Instantáneas antes de los crímenes. Los crímenes reproducibles son ciencia.
La evidencia vence a la confianza. Especialmente cuando la confianza lleva una camiseta de Sun Microsystems.
Las familias de herramientas previstas son explícitas sobre la capa en la que operan:
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 rolloverEl acceso experto en bruto es una característica, no una vergüenza. La respuesta al poder peligroso es la orientación precisa, la ejecución acotada, los efectos visibles y los experimentos recuperables—no lijar cada herramienta hasta que solo pueda imprimir hello world.
DTrace dentro del invitado y eBPF/perf fuera de QEMU son ángulos de rayos X complementarios. Ninguno se promueve a evidencia desde la otra capa: una sonda de DTrace describe Solaris; una sonda del host describe el proceso del emulador. Cuando coinciden a través de la frontera de virtualización, ahora sí que estamos cocinando.
El núcleo portátil 0.1 está implementado y el primer perfil en vivo está probado. La configuración estricta, la identidad de ejecución validada, los adaptadores de invitado/HMP/QMP/host, la evidencia inmutable y el historial de hipótesis, y el servidor stdio de MCP están cubiertos por 58 pruebas. CI ejecuta la suite portátil en macOS y Linux.
El perfil Niagara también se ha probado contra una ejecución en vivo de QEMU 10.2. Demostró el PID exacto, consultó QMP a través de un socket Unix privado, capturó registros e instrucciones SPARC v9 con gdb-multiarch, se desconectó y demostró de forma independiente que QEMU volvió a running. Una CLI de Codex recién creada en el host de la VM descubrió entonces la ejecución y consultó su estado usando solo herramientas MCP.
Las recetas de DTrace del invitado, las recetas nombradas de eBPF/perf del host, el clasificador semántico del proyecto, las capturas de diagnóstico direccionadas por contenido y la rotación automática de bloqueos siguen siendo trabajo registrado, no magia publicitada.
La caja es vieja. El equipo de depuración no lo es.
¡Bastante!
**Estoy apostando por el estilo de escritura basura de IA, en lugar de intentar actuar como si fuera un poeta. Espera joyas con rayas como «El espíritu está capturado, pero nadie—incluido el futuro Ryan—puede decir rápidamente qué promete el software o qué hacer a continuación.» en grandes cantidades.**
Aquí no hay ilusiones de que Ryan haya surgido completamente formado de la frente de Bill Joy, ya fluido en los internals de sun4v. Este proyecto se está construyendo mediante curiosidad, experimentos, colaboración con IA, documentación antigua, nueva evidencia y la ocasional idea mala extremadamente productiva.
Eso hace que la disciplina sea más importante, no menos. La SPEC dice lo que el sistema debe hacer. Las pruebas demuestran lo que realmente hace. El libro de contabilidad de evidencia registra lo que realmente observamos. El flujo de trabajo para contribuyentes evita que un hack prometedor se convierta silenciosamente en una capa arqueológica.
| 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.
