ecamm-mcp

Overview Schema Source Related Servers Discussions Admin

ecamm_zoom

Destructive

Operate Ecamm Live in Zoom: switch panels, toggle video/audio, raise hand, start or end meetings, mute all, and control recordings; disruptive actions require confirmation.

Instructions

Ecamm for Zoom controls. View/self actions run directly; new_meeting, leave, end_for_all, mute_all and recording actions need confirm: true. panel shows meeting|chat|participants|share.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "action": "<action>"
    },
    "name": "ecamm_zoom"
  }
}

Input Schema

Name	Required	Description
`panel`	No
`action`	Yes
`confirm`	No	Must be true to actually do it. Without it you get a dry run describing what would happen.
`usePersonalMeetingId`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.2.2Nov 10, 2026

TDQS

B3.3/5.0

Behavior4/5

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

Annotations declare destructiveHint=true and readOnlyHint=false; the description adds the meaningful constraint that a subset of destructive actions is gated behind confirm: true, so the agent knows a write can silently degrade to a dry run. It does not disclose what end_for_all or leave actually terminate, or the scope of impact on other participants.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three dense sentences, front-loaded with the tool's domain and then the operational rule; no filler. The opening "Ecamm for Zoom controls" is the weakest line, but the rest is tight and information-dense.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 15-action control tool with no output schema, the description covers the safety-critical gate and one parameter but omits the dry-run response shape, what happens on invalid action/panel combinations, and any behavior notes for the recording actions. Adequate to call safely, not complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 25%, so the description needs to compensate; it does partially by naming the confirm-required actions and clarifying that panel selects a view (meeting|chat|participants|share). It says nothing about usePersonalMeetingId or which behaviors depend on it, leaving one of four parameters undocumented in both places.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

"Ecamm for Zoom controls" plus the confirm gating identifies this as a multi-action Zoom meeting control surface, but the actual operation set (toggle_video, gallery_speaker, spotlight_self, cloud_record, etc.) lives only in the schema enum. Nothing distinguishes it from siblings like ecamm_recording or ecamm_toggle, which plausibly overlap with its record/toggle actions.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description usefully partitions actions into those that run directly (view/self) versus those requiring confirm: true (new_meeting, leave, end_for_all, mute_all, recording), which is real usage guidance. It gives no guidance on when to choose this tool over overlapping siblings such as ecamm_recording for record operations.

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