Solaris на SPARC, внутри QEMU, внутри другого Mac, подключённый к ИИ, который выполнил
uname, мельком заглянул в бездну 2002 года и сказал:«Хм. Странно. Ну ладно, у меня есть Bash. Погнали, блин.»
Это специально созданная управляющая плоскость MCP для виртуальной лаборатории Sun Niagara.
Начните с нормативной спецификации. Работа организована в каноническом списке задач, а руководство по присоединению и внесению вклада объясняет, как идея превращается в ограниченную ветку, протестированное изменение и чисто закрытую часть работы. Блог проекта ведёт хронологическую, непочтительную историю, не превращая нормативные документы в пятничный словесный салат. Настройка Codex охватывает прямую установку на хост-машине VM и путь SSH stdio с другой машины.
Смысл не в том, чтобы дать агенту вежливую маленькую удалённую оболочку и притворяться, что древний гость Solaris — это обычная облачная VM. Смысл в том, чтобы позволить агенту воплотиться в машине, одновременно давая ему ту невозможную рентгеновскую способность, о которой мечтают хакеры железа и ядра:
оболочка внутри гостя Solaris/illumos SPARC;
нативный для гостя DTrace: зонды, агрегации, свидетельства syscall/провайдеров, и операционная система, объясняющая себя на своём родном языке;
внеполосные последовательные и служебные каналы;
доступ к монитору QEMU и состоянию машины;
GDB с поддержкой SPARC, смотрящий прямо на эмулируемый CPU;
свидетельства eBPF, perf, syscall, планировщика и ввода-вывода на стороне хоста;
диски VM, снимки, журналы, прошивка и манифесты запусков; и
реестр свидетельств для отделения фактов от вибраций.
Сетевое взаимодействие гостя — одна из вещей, которые отлаживаются. Поэтому оно никогда не является предпосылкой для его отладки.
Выгода — это плотный цикл исправления для сбоев, пересекающих исторические и виртуализационные границы. Предположим, Solaris ifconfig сбоит на неожиданном ioctl. Ошибка может жить в предположениях пользовательского пространства, сетевом стеке illumos, эмулируемом драйвере устройства Solaris Райана, модели sun4v/устройств QEMU или в конфигурации лаборатории, связывающей их.
Этот MCP — аппарат для отказа от догадок. Воспроизведите симптом, сформулируйте конкурирующие гипотезы на уровне слоёв, наблюдайте ioctl с помощью гостевого DTrace, исследуйте состояние ядра/драйвера, сопоставьте его с трассами QEMU и хоста, исправьте наиболее вероятного владельца, пересоберите, перезагрузите или перезагрузите намеренно, и снова запустите тот же различающий тест. Этот итеративный межслойный цикл и есть продукт.
То же самое применимо, когда -smp 2 по-прежнему даёт однопроцессорную систему Solaris. Мы можем сравнить инвентаризацию vCPU QEMU, данные описания машины OpenBoot и sun4v, свидетельства обнаружения/подключения CPU Solaris, состояние CPU, видимое отладчиком, и потоки хоста, вместо того чтобы рассматривать «у других людей SMP заработало» как действенный диагноз.
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».
Проект следует методу гипотез Гилфойла Райана:
Сформулируйте конкурирующие, опровержимые гипотезы.
Предскажите, что, согласно каждой гипотезе, мы должны наблюдать.
Запустите самый дешёвый тест, который их различает.
Немедленно записывайте свидетельства, включая их слой и происхождение.
Убивайте плохие гипотезы без сентиментальности.
Изменяйте систему только после того, как свидетельства до изменения надёжно сохранены.
Никаких сеансов по журналу. Никакого объявления победы из-за того, что консоль дёрнулась. Никакого превращения «я не знаю» в страницу уверенной фан-фантастики.
Райан провёл пять лет в Joyent, и этот проект осознанно заимствует операционную идею из manta-thoth. Thoth брал ядро illumos и дампы сбоев, давал каждому дампу стабильную идентичность, хранил его метаданные и запускал именованные анализаторы против него. Инженер мог интерактивно отладить один дамп, превратить полезную часть этого сеанса в анализатор и применить анализатор к последующим дампам.
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 остановленным, не является умной.
Один писатель означает один писатель. Общие каналы не становятся надёжнее, когда три устаревших процесса-моста борются за них.
Никогда не нажимайте Ctrl-C на управляющем терминале QEMU. Мы уже заплатили за этот урок.
Снимки перед преступлениями. Воспроизводимые преступления — это наука.
Свидетельства побеждают уверенность. Особенно когда уверенность одета в футболку Sun Microsystems.
Предполагаемые семейства инструментов явно указывают слой, на котором они работают:
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 внутри гостя и eBPF/perf снаружи QEMU — это взаимодополняющие рентгеновские углы. Ни один из них не повышается до свидетельства из другого слоя: зонд DTrace описывает Solaris; зонд хоста описывает процесс эмулятора. Когда они согласуются через границу виртуализации, вот тогда мы готовим.
Портативное ядро 0.1 реализовано, и первый живой профиль доказан. Строгая конфигурация, проверенная идентичность запуска, адаптеры гостя/HMP/QMP/хоста, неизменяемая история свидетельств и гипотез, а также сервер MCP stdio покрыты 58 тестами. CI запускает портативный набор на macOS и Linux.
Профиль Niagara также был опробован на живом запуске QEMU 10.2. Он доказал точный PID, запросил QMP через приватный Unix-сокет, захватил регистры и инструкции SPARC v9 с помощью gdb-multiarch, отсоединился и независимо доказал, что QEMU вернулся в состояние running. Затем свежий CLI Codex на хост-машине VM обнаружил запуск и запросил его статус, используя только инструменты MCP.
Рецепты гостевого DTrace, именованные рецепты eBPF/perf на хосте, семантический классификатор проекта, диагностические захваты с адресацией по содержимому и автоматическое переключение при зависании остаются отслеживаемой работой, а не рекламируемой магией.
Коробка старая. Отладочная установка — нет.
Вполне!
**Я намеренно использую стиль ИИ-помоев, а не пытаюсь притворяться поэтом. Ожидайте больших порций жемчужин с тире, например: «Дух захвачен, но никто — включая будущего Райана — не может быстро сказать, что обещает программное обеспечение или что делать дальше.»**
Здесь нет иллюзий, что Райан появился полностью сформировавшимся из лба Билла Джоя, уже свободно владея внутренностями sun4v. Этот проект строится через любопытство, эксперименты, сотрудничество с ИИ, старую документацию, новые свидетельства и иногда чрезвычайно продуктивную плохую идею.
Это делает дисциплину более важной, а не менее. 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.
