Skip to main content
Glama
kostikpenzin

mcp-iva-mcu

by kostikpenzin
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

iva_conference

Manage conference lifecycle: create, update, delete, schedule sessions, quick-start meetings, create rooms, list participants, and respond to invitations.

Instructions

IVA conference management: create/get/update/delete conferences, calculate session schedule, quick start, create rooms, get participants, respond to invitations, get free resources. Clients API v2.28.12.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMaximum number of results
actionYesOperation to perform: - "create": Create a new conference/meeting/event. Required: conferenceData with name and startDate (UNIX ms). Use this when user says 'заброни встречу', 'создай конференцию', 'schedule a meeting', 'book an event'. - "get": Get conference details by ID - "delete": Delete a conference by ID - "update": Update conference properties - "calculate_sessions_schedule": Calculate session schedule for recurring conferences - "get_draft": Get draft conference based on existing one - "get_free_resources": Get free resources available for a conference - "get_participant": Get a specific participant of a conference - "get_participants": List all participants of a conference - "respond_on_invitation": Respond to a conference invitation (accept/decline) - "start_now": Start a conference immediately (quick start without scheduling) - "create_room": Create a conference room (persistent meeting space)
offsetNoNumber of results to skip (pagination offset)
confirmNoSet to true to confirm destructive actions (delete, remove, stop, etc.) when IVA_CONFIRM_DESTRUCTIVE is enabled.
roomDataNoRoom creation data
conferenceIdNoConference UUID
scheduleDataNoSchedule calculation data
startNowDataNoQuick start conference data
participantIdNoParticipant UUID
conferenceDataNoConference creation/update data. Required fields: name (string), startDate (integer, UNIX ms). Optional: duration (ms), description, settings object with conferenceType, participants array.
invitationResponseNoInvitation response data

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.0.8

TDQS

C2.9/5.0
Behavior2/5

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

No annotations provided, so the description carries the full burden of behavioral disclosure. It lists operations but does not mention destructive-action confirmation behavior (despite a confirm parameter), side effects, permission requirements, or any consequences of the mutating actions. The tool is heavily mutative (create/update/delete/respond), yet the description gives no behavioral caveats.

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?

One efficient, front-loaded sentence that summarizes scope before listing operations. No filler words and the API version tag is useful context. Slight redundancy with the action enum, but as a summary it earns its place.

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

Completeness2/5

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

This is a complex tool-12 distinct actions, 11 parameters, nested objects, no output schema, and no annotations-and the description is a single summary line. It does not explain action-parameter coupling, return behavior (relevant since there is no output schema), or the confirm/IVA_CONFIRM_DESTRUCTIVE flow for destructive actions. The rich action-enum descriptions compensate partially, but the description itself leaves major navigation gaps.

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 description coverage is 100%, so the baseline is 3. The description adds only a high-level mapping of operations to the action enum, but the schema already documents each parameter in detail (including required conferenceData fields and UNIX ms format). The description does not go beyond the structured data.

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

Purpose4/5

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

The description states a clear verb+resource ('IVA conference management') and enumerates the operations it covers: create/get/update/delete conferences, schedule calculation, quick start, room creation, participants, invitations, free resources. This distinguishes it from non-conference siblings like iva_documents or iva_chat. However, it does not differentiate from specialized conference siblings (iva_conference_participants, iva_conference_session, iva_conference_media), leaving boundary ambiguity.

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

Usage Guidelines2/5

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

The description provides no when-to-use or when-not-to-use guidance and names no alternatives. The detailed per-action usage examples ('Use this when user says...') live in the action enum schema, not in the description, so the description field itself offers no routing help.

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

Deploy Server

Other Tools