Each tool targets a distinct stage of the async pipeline: queue (transcribe/diarize/summarize), poll (status), fetch (result), and inspect (models). The only friction is mild overlap between listen_transcribe's optional minutes flag and listen_summarize, plus status vs result needing the description to clarify state-vs-content. Descriptions do resolve this, so misselection risk is low.

All six tools use a uniform listen_ prefix followed by a clear noun/verb (transcribe, status, diarize, summarize, result, models) in consistent snake_case. The pattern is predictable enough that an agent can guess a tool name before reading it.

Six tools is a tight, well-scoped surface for an asynchronous audio-processing service: one per job type plus the status/result/models trio needed to drive the queue-and-poll workflow. No tool looks redundant or padded.

The lifecycle is largely covered: submit jobs, check status/health, retrieve results in multiple formats, summarize, and inspect engines. Gaps are administrative rather than core — no cancel/delete job, no explicit list-jobs tool (folded into listen_status), and no way to submit remote/uploaded audio, but agents can work around these.