Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the behavioral burden well: it discloses polling/latency behavior, cursor advancement, wait behavior, rough text quality, and the stop condition. It does not describe failure behavior when no live recording exists, which keeps it from a 5.

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 front-loaded with the core purpose and behavior, then gives concise loop and reporting instructions. Despite being longer than a bare definition, every sentence supports correct invocation or use of the returned transcript.

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 that an output schema exists, the description does not need to explain return values, and it covers the live/polling workflow, cursor reuse, accuracy caveat, and stop condition. It is nearly complete, though it could say what happens if no live recording is active.

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 must compensate, and it does: `since` is explained as the cursor for speech already heard and as the value returned from prior calls, while `wait_seconds` is explained as the maximum wait for new speech. Both parameters gain clear operational meaning beyond the bare schema.

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 names the specific tool action and resource: a live transcript of the recording in progress, limited to speech since the cursor. It also distinguishes itself from the final transcript by saying the post-call transcript is more accurate, so an agent can tell it apart from get_transcript.

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?

It gives explicit usage instructions: call in a loop within the same turn, pass the returned cursor as `since`, report useful findings to the user after each batch, and stop when the recording is over. It also states the prerequisite that the recording was started with live=true.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and does disclose one important trait: the call is blocking for up to wait_seconds when the recording is still running. It does not say what is returned on timeout (empty transcript, partial result, or error), whether a missing recording errors, or whether the call is read-only.

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?

A single sentence with no filler. The resource is front-loaded and the conditional wait behavior follows immediately, so the agent gets the essential facts in reading order.

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?

An output schema exists, so return values need no explanation. But for a blocking retrieval tool with zero annotations, the timeout outcome and error behavior for a nonexistent recording are unaddressed, leaving an agent unable to predict what happens at the wait boundary.

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 must compensate, and it does: 'recording' takes "latest" or a folder name, and wait_seconds caps how long it blocks while a recording is still running. Only the default values (schema-supplied) are not restated, which is fine.

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?

States a specific resource (transcript) and identifies the input form ("latest" or folder name), so an agent knows this retrieves an existing transcript rather than generating one. It does not explicitly contrast itself with the sibling transcribe_recording, so the get-vs-create distinction is inferred rather than stated.

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?

The clause "waiting up to wait_seconds if it is still running" implies this is safe to call while a recording is in progress, which is useful context. However, there is no explicit guidance on when to use this versus transcribe_recording or transcribe_file, and no exclusions or prerequisites are given.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations exist, so the description carries the full behavioral burden, and it does not explicitly say this is a read-only enumeration with no side effects. However, with zero parameters and an output schema, the description is not required to explain return values, and a listing operation is low-risk enough that the gap is small.

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?

It is a single short sentence with no padding, but it is a grammatical fragment with a dangling parenthetical ('Apps currently using audio (to choose the source), and the default microphone and output'), which reads ambiguously rather than being front-loaded with a clear verb.

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?

With an output schema present and zero parameters, the definition covers the essentials of what the call returns, so an agent can invoke it. It still omits that the call is read-only and does not state explicitly that it should precede start_recording to select a source.

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?

The tool takes no parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The description correctly implies the call is argument-free.

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 is a noun phrase enumerating what is returned (apps using audio, default microphone, default output) rather than stating 'List audio sources', though the intent is inferable. It does distinguish itself from the recording siblings by being device/source discovery, but the phrasing is fragmentary enough that an agent must read the tool name to confirm the verb.

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?

The parenthetical '(to choose the source)' implies the tool is meant to be called when the agent needs to pick a capture device, likely ahead of start_recording. That is an implied workflow hint rather than an explicit when-to-use/when-not statement, and no alternative tool is named.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It discloses that transcription state is included in the result, but says nothing about read-only safety, ordering (how 'latest' is determined), pagination beyond the limit, or whether all recordings or only recent ones are returned.

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?

It is a single short sentence with no waste, but it is under-specified rather than efficient. The sentence leads with the resource rather than an action, so front-loading is weak.

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?

An output schema exists, so return values need not be explained. For a zero-required-parameter listing tool, the description's one piece of added information (transcription state is included) is close to sufficient, though it omits the limit behavior and the 'latest' ordering semantics.

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 coverage is 0% for the single `limit` parameter, and the description never mentions it. The agent cannot learn the default (10), maximum, or what happens if it is omitted from the description or schema.

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 names the resource (recordings) and notes it returns the latest ones along with their transcription state, which is informative. But it is a bare noun phrase with no verb (list/retrieve) and no scope qualifiers, so it only vaguely signals the operation.

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?

There is no indication of when to use this versus siblings like recording_status, get_transcript, or transcribe_recording. An agent must infer from the name alone that this is the discovery/listing entry point.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full behavioral burden. It helpfully explains what is returned and interprets the -120 dB value as no captured sound, but it does not explicitly confirm that the operation is read-only or describe auth/rate-limit behavior.

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 a single well-structured sentence that front-loads the core status information and uses a parenthetical only where it adds interpretive value.

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 a zero-parameter status tool with an output schema, the description covers the essential query outcome and explains the most ambiguous value (dB level meaning). It could be slightly more complete by stating that it is a read-only check or when it is appropriate to call.

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?

The tool has zero parameters, which is the baseline for a 4. The description does not need to explain parameter semantics, and no misleading parameter context is present.

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 clearly states the resource and the information returned: whether recording is in progress, its duration, and recent per-side sound levels. It is specific enough to distinguish from siblings like start_recording or get_transcript, though it does not explicitly name an alternative.

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: checking live recording state and levels. However, the description does not explicitly say when to use this tool versus list_recordings or stop_recording, nor does it mention prerequisites such as an active recording.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full behavioral burden. It discloses the mutation and that an updated transcript is returned, but it does not say whether the stored transcript is modified in place, what permissions are required, what happens to unmatched labels, or how errors are handled.

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 definition is front-loaded with the core purpose, gives a compact example, and ends with the return behavior. Every sentence contributes useful information without repetition or fluff.

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?

Although an output schema exists and reduces the need to explain return values, this is an unannotated mutation tool with a nested-object parameter. The description does not cover the recording parameter, persistence semantics, permissions, or error cases, leaving important gaps for correct invocation.

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 must compensate. It usefully explains the required names mapping with an example and notes that labels are in the user's language, but it entirely omits the optional recording parameter, including its default of 'latest' and accepted identifier format.

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 uses a specific verb and resource: 'Replace speaker labels in a transcript with real names.' It is clear what the tool does, but it does not explicitly distinguish itself from transcript-related siblings such as get_transcript or transcribe_recording.

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 only implied by the phrase 'in a transcript'; there is no explicit guidance on when to use this instead of alternatives, prerequisites, or whether the transcript must already exist. The description does not mention the recording parameter or how to choose a recording.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It does add real behavioral context: source choices with a safety recommendation, that title becomes a folder name (a filesystem side effect), and that live transcription feeds get_live_transcript. It omits important behavior for a mutation tool: required macOS audio-capture permissions, what happens if a recording is already in progress, and how the recording ends.

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?

Front-loaded with a one-line purpose, then a compact per-parameter glossary. Every line corresponds to a parameter that the schema leaves undocumented, so little is wasted, though the multi-line wrapping of the source list is slightly noisy.

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?

An output schema exists, so return values need not be explained, and all six parameters are covered. The remaining gap is operational context around a stateful capture tool — permissions and concurrent-recording behavior — which is a real but moderate omission.

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 must carry all six parameters, and it does: source (with an enumerated list of valid values and bundle-ID fallback), title, include_mic, language, speakers (with the default and the Speaker 1/Speaker 2 consequence), and live. This is meaningfully richer than the bare schema types and defaults.

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 first sentence states a specific verb and resource: 'Start recording a call or a conversation.' It is unambiguous against siblings like stop_recording and recording_status, though it never explicitly names those siblings or distinguishes itself from transcribe_file/transcribe_recording.

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 guidance is given at the parameter level ('live ... Use it when the user wants help during the call') and a recommendation is embedded for source ('system ... the safest'). However, there is no tool-level guidance on when to use this versus transcribe_file or transcribe_recording, and no stated prerequisites or when-not-to-use conditions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full behavioral burden. It usefully discloses that stopping also starts transcription and that the result depends on wait_seconds, but it omits permission requirements, behavior when no recording is in progress, and whether the stop action is irreversible.

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 short and front-loads the main action before parameter notes. The parameter section is somewhat terse and fragmentary, but it does not waste much space.

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?

An output schema exists, so return-value details are not fully required in the description. Still, for a mutation tool with no annotations and four undocumented schema parameters, the description should say more about transcribe semantics and edge cases such as stopping when no recording is active.

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 must explain all four parameters. It covers speakers and language and refers to wait_seconds indirectly, but it never explains the transcribe boolean, leaving a meaningful parameter undocumented.

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 clearly states a specific verb and resource: "Stop the recording in progress and start its transcription." That is enough for an agent to understand the operation, but it does not explicitly distinguish this tool from related siblings such as recording_status or transcribe_recording.

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 "recording in progress" and the fallback instruction to call get_transcript later, plus a note to ask the user for group-call speaker count. However, it does not explicitly say when to use stop_recording versus recording_status, start_recording, or transcribe_recording, nor does it give clear exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations exist, so the description carries the burden; it does disclose that the source is copied into a new recording folder and that speakers above 1 trigger voice separation. However, it says nothing about wait_seconds behavior (blocking vs async), whether transcription is synchronous, or what happens on unsupported formats.

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?

Two short paragraphs, front-loaded with the core action and followed by the one parameter that has non-obvious semantics. No filler sentences, though the parenthetical format list runs slightly long.

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?

An output schema exists so return values needn't be explained, and the file-format hints help. But with 5 parameters at 0% schema coverage, the unexplained wait_seconds (a timing/blocking concern) and language defaults leave real gaps for an agent deciding how to call it.

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 must compensate. Only 'speakers' is given real meaning ('total number of people speaking... separated into Speaker 1, Speaker 2'); title, language, and wait_seconds remain entirely unexplained, and 'path' format is only loosely implied by the listed extensions.

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?

States a clear verb+resource ('Transcribe an existing audio or video file') and enumerates concrete file formats, which distinguishes it from the recording-oriented siblings without naming them. The addition of 'copied into a new recording folder' clarifies the scope is an existing on-disk file rather than a live capture.

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?

The word 'existing' implicitly points to file input versus the record-then-transcribe flow of transcribe_recording, but no sibling is named and no when-to-use/when-not guidance is given. An agent must infer the routing from the word 'existing' alone.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full behavioral burden. It does not disclose whether re-transcription overwrites the existing transcript, whether the operation is asynchronous or blocking, what wait_seconds controls, or what permissions/side effects apply.

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?

It is front-loaded and has no wasted sentences, but it is under-specified rather than appropriately concise given four undocumented parameters and no annotations.

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?

An output schema exists, so return values need not be explained, but the description leaves critical gaps around parameter semantics and behavioral side effects for a tool that reprocesses recordings.

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 must compensate for all four parameters. It only explains speakers; language, recording, and wait_seconds remain undocumented beyond their names and defaults.

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: re-transcribing an existing recording. The word "again" helps distinguish it from first-time transcription or file transcription, but it does not explicitly name siblings like transcribe_file or get_transcript.

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?

It gives clear usage scenarios: re-transcribing in another language or separating voices. It does not explicitly state when not to use it or name alternatives, but the context is clear enough for selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.