Agent-First HTTP v0.4: A Narrower Runtime with Complete Help

A tool for agents should not grow every integration surface forever.

Agent-First HTTP started with multiple ways to reach the same idea: native CLI, pipe mode, curl-style translation, and an MCP server mode. The v0.4 line narrowed that runtime and invested in the interface agents actually inspect: the command line contract.

The problem: too many surfaces make the contract harder to trust

Every extra runtime mode adds dependencies, failure modes, docs, and tests. If a mode is not the primary way agents use the tool, it can make the binary heavier without making the protocol clearer.

The v0.4.0 release removed --mode mcp and the rmcp/schemars dependency surface. Agents still had native CLI, pipe mode, and curl-compatible translation. The tool became smaller and easier to reason about.

The docs change: generated CLI reference replaced hand-written drift

The next step was documentation. v0.4.1 generated CLI docs from the clap command definition instead of maintaining a separate manual by hand.

That matters because agents read docs as operational context. If docs drift from flags, agents make bad calls. Generated docs keep the reference close to the code that actually parses arguments.

The help change: one call should reveal the interface

v0.4.2 replaced normal shallow help with recursive help via Agent-First Data’s cli_render_help, and added --help-markdown for docs generation.

An agent can run one help command and see the whole CLI shape. It does not have to crawl subcommands or infer hidden flags from failed executions.

Where this fits: fewer modes, better affordances

The v0.4 line was less about adding a new HTTP feature and more about making the connector dependable as a tool. Fewer runtime surfaces. Better generated docs. Complete help. Strict linting to protect structured output discipline.

That is agent-first design too: make the way into the tool obvious, complete, and hard to misread.