Loading ToolBench
MCP adapter over the bridge server's HTTP API for Google Meet and Zoom transcript capture, advice channel, action-item board, snapshots, local STT and TTS
This MCP server has serious definition quality gaps. Tool names lack clear action verbs and are inconsistent in style. Descriptions vary wildly in length and completeness, some are detailed (attach, poll), others are vague (wake-loop) or incomplete. Input schemas are present and mostly typed, but parameter descriptions in the source code are minimal or missing for critical parameters. Error handling documentation is absent. The server lacks output schema documentation for any tool. Tool composition shows concerning stateful patterns (session pinning via attach) that would confuse LLM reasoning. Overall, this reads like an early-stage extension bridge rather than a production-grade agentic tool suite.
Add an action item to the meeting's action board. Fails silently if the session does not exist, so an action issued before attach has pinned the session lands in the previous meeting.
Post advice to the meeting's advice channel (displayed as a card in the panel). The text can include markdown. Fails silently if the session does not exist, so advice issued before attach has pinned the session lands in the previous meeting.
Attach to a meeting: claim it for this assistant, and pin its session key for all subsequent calls. Returns the meeting's metadata (timestamp, participants, language) and the reader's current position in the transcript. Fails if the session does not exist or the token is rejected.
Send a chat message into the meeting. Sent to the extension which adds it to the server's chat store. The message will appear in the panel's chat history.
Retrieve the full context of the current pinned meeting: all captions from the start, advice, action items, and chat. Useful for answering questions about what has happened so far in the call.
Tool names lack consistent action verb prefixes. Names like 'attach', 'poll', 'advice', 'chat', 'wake-loop' do not follow verb_noun convention. LLMs cannot reliably infer intent from 'poll' vs 'context', both are ambiguous. Should be: 'pin_session', 'fetch_updates', 'post_advice', 'send_chat', 'get_wake_script', 'get_meeting_context'.
No output schemas documented for any tool. Tool descriptions mention what is returned (e.g., 'Returns everything that arrived since the last poll, keyed by type') but no structured schema is provided. LLMs cannot plan downstream tool calls or extract typed fields without knowing the response structure.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 45 | 2026-07-28+ | v2 |
Poll for new transcript lines, advice batches, action items, chat messages, and snapshots. Returns everything that arrived since the last poll, keyed by type. Holds the reader's position server-side (no need to track byte offsets). Poll returns immediately if content is available; otherwise it times out after ~30 seconds.
Capture a snapshot (page content + URL) at the current moment. Snapshots are stored and can be reviewed later. Used by the panel's snapshot feature to record relevant page state during a call.
Convert text to speech and stream the audio to the meeting (via the extension). Voice and language are inferred from the meeting's detected language. Returns audio metadata and stream details.
Returns a shell script (POSIX sh) that the assistant can spawn under a persistent monitor to receive wake-up notifications whenever new content arrives. The script polls the /wake endpoint and prints each batch it receives. Intended for use in an assistant's shell loop to trigger a turn on new captions or advice.
Stateful session management via 'attach' (pin session for all subsequent calls) violates stateless tool design. The description warns: 'Fails silently if the session does not exist, so advice issued before attach has pinned the session lands in the previous meeting.' This is a composition antipattern, each tool should be independently callable without side effects. LLMs cannot reason about invisible state transitions.
Error handling descriptions are absent. No guidance on what happens on failure, whether errors are retryable, or what recovery steps exist. E.g., 'Attach' says 'Fails if the session does not exist or the token is rejected' but does not explain how the LLM should respond. Pattern: 'recovery-guide' requires each error to tell the agent what to do next.
Parameter descriptions are minimal or absent in tool definitions. E.g., 'wake-loop' has zero parameters but the description references behavior ('pins session server-side') that is unclear. 'advice' and 'action' have text parameters but no guidance on format, length limits, or valid content.
'wake-loop' tool name and description are confusing. Tool returns a shell script, not streaming wake events. LLMs will be uncertain whether to call it to receive notifications or to set up a background process. Rename to 'get_wake_loop_script' and clarify in description: 'Returns a POSIX shell script that polls for new content and prints each batch. Intended for manual execution in a terminal or scheduled runner, NOT for direct agent use.'
Inconsistent parameter naming. 'attach' takes 'session' (string), but 'poll' does not document how it knows which session to poll, presumably the one pinned by attach. This implicit dependency on stateful session storage is not conveyed in the tool descriptions. If session selection is implicit, the tool should document it. If explicit, both tools should accept a 'session_id' parameter.
Tool descriptions embed failure modes and side effects in a way that requires careful reading. E.g., 'advice' says 'Fails silently if the session does not exist', a silent failure is unacceptable in agent tool design. The tool should return an explicit error with recovery guidance, not silently discard the message.