Skip to main content

​
Use the CLI for A2A workflows

Message responses and errors default to readable text for interactive use. Pass --output json for full protocol responses, or --output ndjson before streaming commands when you need structured event output for automation or agent-driven workflows. Commands without a custom text formatter may still emit JSON in the default mode.

​
Inspect an agent card first

Fetch the card for a configured server:
Validate the configured server’s card:
Validate a saved agent card file:
Use card validation before deeper debugging when you’re not sure whether the agent itself is advertising a valid card.

​
Send a message

Send a basic message to a configured server:
You can target a URL directly instead of a configured server:

​
Stream the response

Stream task events and response text from a configured server:
In text mode, streaming prints lightweight event: summaries for task state changes, tool calls, tool results, data/file parts, and response text before the final answer content. That makes it clear when the agent is still working even if the model’s text arrives in one larger chunk. Handler also prints the full task ID once when the stream starts so you can resubscribe if the server connection is interrupted. If you already use message send in scripts, adding --stream switches that same command to streaming mode. Otherwise, prefer the more explicit message stream command in examples and documentation. Use newline-delimited JSON when you want structured stream events:
If you need to tune networking behavior, Handler exposes global timeout flags and matching environment variables. Values are seconds, or none to disable a specific timeout:
The same timeout settings are available as HANDLER_CONNECT_TIMEOUT, HANDLER_READ_TIMEOUT, HANDLER_WRITE_TIMEOUT, HANDLER_POOL_TIMEOUT, and HANDLER_STREAM_READ_TIMEOUT, including from a workspace .env file. Streaming disables the read timeout by default so long-running tasks are not aborted during idle gaps between SSE events.

​
Continue a saved conversation

Handler persists conversation identifiers locally so you can continue later:
Continue using Handler’s saved context and task IDs:
Inspect the saved session for a configured server:
If you already know the IDs you want, you can pass them explicitly:

​
Send custom payloads or headers

For agent-friendly invocation and integration testing, Handler exposes raw JSON input, structured output, and repeatable header flags:
You can also override saved auth with --bearer-env or --api-key-env.

​
Work with tasks directly

Fetch the latest task status:
Include recent message history with the task response:
Cancel a running task:
Reconnect to a task’s SSE stream after interruption:
resubscribe is useful when a task uses streaming events and you need to attach again after a dropped server connection.

​
Configure push notifications for tasks

Point a task at a webhook receiver:
Inspect the current push config later:
For a local receiver you can run the bundled webhook server described in Local servers.

​
Manage saved sessions

Handler stores session metadata locally so repeated CLI calls can reuse conversation state. List all saved sessions:
Show the saved session for a configured server:
Clear the saved session for one configured server:
Clear all saved sessions:
Use session clear when you want a clean slate without deleting the server definition itself.