Start with a narrow inspection task
Useful first tools can retrieve service status, list a selected directory or report a named test. The tool declares its inputs and returns structured evidence with a timestamp. The assistant can explain that result without gaining unrelated access.
Logs, filenames and external text can contain misleading instructions. They remain data from the inspected resource. They do not grant permission to run another operation.
Keep authorization with the system owner
Changes need target validation, the required permission and an approval policy. Separate read and execute capabilities make that boundary visible. Administrative access is an additional decision.
A failed operation should return its exit state and error. The assistant needs to distinguish a blocked action from incomplete code, missing configuration or a server error.
Keep sessions observable
Long running work returns a reference that can be read later in the workflow. Output cursors avoid losing earlier messages or treating truncated text as a new failure. Stop requests retain their outcomes.
We test the client and server together, including expired tokens, cancellation, oversized output and a process that exits unsuccessfully. Public examples never connect visitors to a live server.
Before you begin
Can this use an existing MCP client?
Yes. We name the client, transport and supported version in the specification and test permissions and results.
Will the assistant operate without review?
That is an owner decision for each class of task. The project design separates inspection from operations that change infrastructure.
DSDillon / 26 September 2026
