muteStops the bot from transcribing a meeting and removes its transcribing chip. Requires the meeting_id returned by create_meeting or join_meeting.
Stops the bot transcribing this meeting; the transcribing chip goes away. The bot never sends audio, so this is the only kind of mute it has.
| Name | Required | Description | Default |
|---|---|---|---|
| meeting_id | Yes | The meeting_id returned by create_meeting or join_meeting. |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does meaningful work: it discloses the primary effect (transcription stops), a side effect (the transcribing chip disappears), and a non-obvious behavioral fact that the bot never sends audio. It omits reversibility and permission requirements, but the core behavior is clear.
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 sentences with the core effect front-loaded and zero filler. The second sentence resolves a genuine ambiguity about whether other mute variants exist, so every sentence earns its place.
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?
For a one-parameter, annotation-free tool with no output schema, the description is nearly sufficient: the effect and scope are covered, and the 'no audio' clarification prevents misreading. Only the reversibility/permission story is left to inference via the unmute sibling.
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?
A single required parameter with 100% schema description coverage, so the schema already documents meeting_id fully. The description adds no syntax or scoping detail about the parameter, making the baseline 3 correct.
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 action and its effect on the resource: it stops the bot transcribing this meeting. That distinguishes it from read/status siblings, but it never names the obvious counterpart 'unmute', so the differentiation is left implicit 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?
Usage is implied rather than stated – an agent can infer this is an in-meeting action keyed by meeting_id that halts transcription. It adds a mild clarification ('this is the only kind of mute it has') but gives no explicit when-to-use/when-not guidance or pointer to unmute for reversal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.