> ## Documentation Index > Fetch the complete documentation index at: https://docs.adsumnetworks.com/llms.txt > Use this file to discover all available pages before exploring further. # Tool bits > The loggers, sniffer, decoders, board shell, modem trace and scan engines the agent drives: what each one does, and how they reach you without waiting for an extension release. A coding agent that cannot see the board is guessing. These are the instruments Adsum drives on your behalf: it starts them, reads what comes back, and correlates it with the code it just wrote. Each is a **Tool bit**: the executable half of Adsum's expertise layer, where a [Knowledge bit](/knowledge-bits) is the half that teaches. A K-bit says an nRF fault trace has a program counter worth decoding; the T-bit below is the decoder that turns it into a function and a line. [How the two compare](/architecture#two-kinds-of-bit). Every T-bit is versioned, credited to the engineer who wrote it, and checked against a published hash before it is allowed to run. ## What the tools cover Five areas. Which binary answers a given question is named in your session at the moment it runs, and the set grows without this page changing. ### Watching a board RTT and serial capture, the ESP-IDF monitor driven by the agent rather than by you, and log handling that keeps a very large capture readable. A captured log is often the largest thing in a session, and loading one whole is what ends it early: searching by pattern and reading by line range is what keeps that from happening. One real capture cost 333,000 tokens loaded whole, and a few thousand read this way. *For example `rtt-logger`.* ### Looking at the radio Over-the-air BLE capture, so you can see what left the antenna rather than what your code intended to send, and the host-controller bus between your application and the radio, where a surprising number of BLE bugs actually live. Together with the application log these are the [3-layer debug](/ble-debug): a flow that works on paper and fails in practice broke at exactly one of the three, and correlating them tells you which. *For example `nrf-sniffer`.* ### Bringing a modem up An interactive shell to a running board that speaks both AT commands to the modem and Zephyr shell commands to the application, and a capture from inside the modem of the network signalling your application never sees. Both earn their keep in [cellular](/cellular). *For example `modem-trace`.* ### Reading a crash Fault dumps resolved to the function and the line that faulted, on nRF and ESP alike. ### Proving the product An SBOM from the real build, a ranked scan of it against the published vulnerability databases, and a secure-by-design posture check read from your actual configuration: debug left enabled, secure boot off, a hardcoded credential. These drive the [CRA readiness](/cra-readiness) run end to end. ## Why they are not part of the extension The obvious way to ship a tool is inside the release, and it has a specific flaw: **a CVE database moves faster than an extension release**. A scan engine whose advisory mappings are pinned to whenever we last shipped is a scan engine that is wrong most of the time. So the tools are delivered from the registry instead. Three consequences, all of them the point: A fix to a decoder reaches you the next time it runs, not the next time we ship. Every tool names the engineer who wrote it, in the session that uses it. Checked against a published hash. A tool that does not match does not execute. ### How resolution works A fix to a decoder reaches every machine the next time that decoder runs, whatever version of the extension is installed. No network, restricted site, offline bench: the extension still has a working copy of every open tool. Nothing stops working because a registry is unreachable. Each tool states the oldest extension it will run on. One that needs a newer extension than yours is not downloaded and not run: it waits, rather than half-working against an API it does not have. ## Open and proprietary The rule is simple and worth stating plainly, because it is easy to get the wrong impression from "registry": > **Every tool bundled in the extension is open source, Apache-2.0.** The loggers, the sniffer, the decoders, the fault decoder, the action drivers: all of them, in the VSIX, under a licence that lets you read and fork them. The registry also serves Adsum's own commercial tools, the CRA scan engines and the cellular tooling among them. Nothing bundled in the extension is proprietary. The other half, and the one that came first: curated expertise rather than executables. Who wrote it, what the credit line in your session means, and what its tier tells you about how far it has been proven.