I came across the Apideck CLI from the MCP/context-window angle. The agent-prompt / command-help progressive disclosure pattern is a good answer to the problem where agents load a full OpenAPI spec or many MCP tool schemas before they know what they need.
One small auditability gap I think is worth considering: if an agent workflow relies on the CLI to save context, the operator may still want a privacy-safe receipt that proves the disclosure boundary without storing raw prompts, API args, API responses, or secrets.
A minimal event shape could be something like:
cli.agent_prompt.loaded — tiny startup prompt loaded; full OpenAPI/MCP schemas not loadedcli.command_help.loaded — one command help page expanded on demand; unselected commands stayed unloadedcli.command.executed — command ran with args/result hashes and coarse size/count bucketscli.session.completed — how many command help pages were loaded, whether full specs/schemas were loaded, and the explicit audit gap
I made a small executable fixture here to make the idea concrete rather than just prose:
The fixture uses deliberately private-looking input data and verifies the exported receipt/trace does not include raw customer names, API keys, connection IDs, prompts, arguments, or result bodies — only hashes/buckets.
No ask to adopt this exact schema. The narrower question is: would a --receipt-json / trace export for CLI progressive disclosure be useful for agent workflows, or is the CLI boundary already observable enough from logs?
I came across the Apideck CLI from the MCP/context-window angle. The
agent-prompt/ command-help progressive disclosure pattern is a good answer to the problem where agents load a full OpenAPI spec or many MCP tool schemas before they know what they need.One small auditability gap I think is worth considering: if an agent workflow relies on the CLI to save context, the operator may still want a privacy-safe receipt that proves the disclosure boundary without storing raw prompts, API args, API responses, or secrets.
A minimal event shape could be something like:
cli.agent_prompt.loaded— tiny startup prompt loaded; full OpenAPI/MCP schemas not loadedcli.command_help.loaded— one command help page expanded on demand; unselected commands stayed unloadedcli.command.executed— command ran with args/result hashes and coarse size/count bucketscli.session.completed— how many command help pages were loaded, whether full specs/schemas were loaded, and the explicit audit gapI made a small executable fixture here to make the idea concrete rather than just prose:
The fixture uses deliberately private-looking input data and verifies the exported receipt/trace does not include raw customer names, API keys, connection IDs, prompts, arguments, or result bodies — only hashes/buckets.
No ask to adopt this exact schema. The narrower question is: would a
--receipt-json/ trace export for CLI progressive disclosure be useful for agent workflows, or is the CLI boundary already observable enough from logs?