Skip to main content
Glama

Send the notetaker to a meeting

start_meeting_assistant

Send Mondovo's meeting notetaker into a live Zoom, Google Meet, Microsoft Teams or Webex call. Use it whenever the user shares a meeting link and asks you, the assistant, a bot or a notetaker to join, sit in, listen in, record, transcribe or take notes. Do not tell them to open the Meetings screen instead. purpose: notes (default) for a transcript and summary; site_changes when the call is about changing one of their sites (pass site_id); new_client for a first call with a new client, where a draft site and designs are made from the conversation. Meeting time is free for the first 2 hours per workspace (once), then 40 credits an hour, charged when the notetaker leaves; say so before starting. When the user says who the call is for ("for London Mechanic", a web address), pass it as about; the first call answers with the matching ids, then call again with them. A follow-up call continues the latest meeting about that site or client by default, so the assistant starts from what was decided last time. Other links (or a calendar invite with no join link) are refused: ask for the meeting's join link. The notetaker may need to be admitted from the waiting room. Returns the meeting id and its page, where the transcript and summary appear.

Input Schema

NameRequiredDescriptionDefault
aboutNoWho the call is for, in the user's words, when they named a client, business or web address but you have no ids ("London Mechanic", "londonmechanic.co.uk"). Mondovo matches it to their clients and sites and replies with the ids to call again with.
titleNoOptional name for the meeting, e.g. "Kickoff with Bella Napoli"
purposeNonotes (default): transcript and summary only. site_changes: the call is about changing one of their sites; requested changes go into a new copy of its design, nothing is published (needs site_id). new_client: a first call with a new client; a draft site and designs are made from the conversation.
site_idNoThe site the call is about (from list_sites). Required for site_changes; for other calls it files the call under that site's client and continues its latest meeting.
websiteNoA new client's own current website (not one of the user's sites); the assistant reads it while planning.
bot_nameNoOptional name the notetaker shows in the call (default "Mondovo Notetaker")
client_idNoThe client the call is with, when known.
user_goalNoOptional: the user's goal behind this call, in one short sentence of plain words (e.g. "add a page so customers can book tables"). No names, emails or other personal details.
meeting_urlYesThe meeting's join link exactly as the user shared it (https Zoom, Google Meet, Microsoft Teams or Webex link)
idempotency_keyNoSet by Mondovo; leave it out.
continue_previousNofalse to start fresh instead of continuing the latest meeting about the same site or client (default true).
previous_meeting_idNoThe earlier meeting this call continues. Leave it out to continue the latest meeting about the same site or client automatically.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / user_goal
      Added value: +{
      +  "description": "Optional: the user's goal behind this call, in one short sentence of plain words (e.g. \"add a page so customers can book tables\"). No names, emails or other personal details.",
      +  "type": "string"
      +}
  2. Changed7 schema fields changed
    • addedInput schema / properties / about
      Added value: +{
      +  "description": "Who the call is for, in the user's words, when they named a client, business or web address but you have no ids (\"London Mechanic\", \"londonmechanic.co.uk\"). Mondovo matches it to their clients and sites and replies with the ids to call again with.",
      +  "maxLength": 300,
      +  "type": "string"
      +}
    • addedInput schema / properties / client_id
      Added value: +{
      +  "description": "The client the call is with, when known.",
      +  "format": "uuid",
      +  "type": "string"
      +}
    • addedInput schema / properties / continue_previous
      Added value: +{
      +  "description": "false to start fresh instead of continuing the latest meeting about the same site or client (default true).",
      +  "type": "boolean"
      +}
    • addedInput schema / properties / idempotency_key
      Added value: +{
      +  "description": "Set by Mondovo; leave it out.",
      +  "maxLength": 100,
      +  "type": "string"
      +}
    • addedInput schema / properties / previous_meeting_id
      Added value: +{
      +  "description": "The earlier meeting this call continues. Leave it out to continue the latest meeting about the same site or client automatically.",
      +  "format": "uuid",
      +  "type": "string"
      +}
    • changedInput schema / properties / site_id / description
      Previous value: -"The site the call is about (from list_sites). Required for site_changes; ignored otherwise."New value: +"The site the call is about (from list_sites). Required for site_changes; for other calls it files the call under that site's client and continues its latest meeting."
    • addedInput schema / properties / website
      Added value: +{
      +  "description": "A new client's own current website (not one of the user's sites); the assistant reads it while planning.",
      +  "maxLength": 300,
      +  "type": "string"
      +}
  3. Added

TDQS

A4.8/5.0
Behavior5/5

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

Goes well beyond the annotations (readOnlyHint false, openWorld true, destructiveHint false, non-idempotent) by disclosing pricing/credit charging timing, waiting-room admission, default continuation of the latest meeting, refusal behavior for non-join links, and the return value (meeting id and page). The mutation behavior of site_changes (copy of design, nothing published) is also clarified.

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?

Front-loaded with purpose and platform list, then usage, then behavioral details. It is dense and information-rich, though the purpose/about/continue explanations partially restate the schema, adding some length that isn't strictly necessary.

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

Completeness5/5

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

For a 12-parameter mutation tool with no output schema, the description covers invocation triggers, pricing side effects, refusal cases, continuation defaults, and the return value, leaving no major gaps an agent needs to call it correctly.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description adds real value: it explains the two-call `about` matching flow (first call returns ids, call again with them) and clarifies purpose enum meanings and default continuation beyond the schema text.

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

Purpose5/5

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

The description states a specific verb and resource ('Send Mondovo's meeting notetaker into a live Zoom, Google Meet, Microsoft Teams or Webex call') and enumerates supported platforms, so an agent knows exactly what it does. It also explicitly distinguishes itself from an alternative ('Do not tell them to open the Meetings screen instead').

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

Usage Guidelines5/5

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

Provides explicit when-to-use conditions ('whenever the user shares a meeting link and asks you... to join, sit in, listen in, record, transcribe or take notes'), when-not ('Other links... are refused: ask for the meeting's join link'), and routes around the Meetings screen alternative.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources