Capture microphone audio for 1–20 seconds, save it as a mono 16 kHz WAV file on the controller, and return the absolute file path for later use. No transcription included.
Record the Voice-kit microphone for 1–20 seconds, save mono 16kHz WAV on the controller, and return its absolute path. No automatic transcription.
| Name | Required | Description | Default |
|---|---|---|---|
| duration_seconds | No |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description discloses key behavior: the recording length range, output format, where the file is saved, and the fact that no transcription is performed. It does not specify whether repeated calls create separate files or how filenames are chosen, but the annotations already establish the non-read-only, non-destructive, non-idempotent profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two compact sentences with the core action front-loaded. Every clause adds useful information: duration bounds, audio format, save location, return value, and transcription behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of an output schema, the description usefully explains what is returned: an absolute path to the saved WAV file. It covers the main behavior an agent needs, though file naming and overwrite behavior are left unspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the burden for the single duration_seconds parameter. It supplies the critical range of 1–20 seconds, though it does not explicitly name duration_seconds or mention the default value of 5.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: record the Voice-kit microphone. It also specifies important scope details (1–20 seconds, mono 16kHz WAV, saved on the controller) and distinguishes the output from transcription-focused siblings by saying there is no automatic transcription.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the clear action and duration constraint, but there is no explicit guidance about when to choose record_audio instead of record_camera, capture_camera, or other audio-related siblings. The 'No automatic transcription' note clarifies expectations but does not route the agent among alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.