TestMyVibes

Run a two-AI voice conversation through Paradise Comms

submit_conversation_test

Spawns two AI personas as participants on a real LiveKit voice call (via Paradise's self-hosted comms cluster), driven by PM Brain's realtime lane by default, and runs a structured conversation. Each persona talks aloud (PM TTS) and listens to the other (PM STT) — this isn't simulation, it's a real WebRTC call with real audio. Used to verify Paradise Comms end-to-end (publisher → SFU → subscriber → recording → outbound webhook) and to demo agent-to-agent voice. Returns the full transcript and a recording hint.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`turns`	No	Total back-and-forth turns. 6 means A→B→A→B→A→B. Cap of 20 to bound LLM + TTS + STT spend per test.
`personaA`	No	Persona for agent A (speaks first). Defaults to skeptical-cto. See lib/personalities.ts for the full list of 8 personas.	skeptical-cto
`personaB`	No	Persona for agent B. Defaults to power-user. The pairing skeptical-cto + power-user is the canonical demo because their voices contrast strongly enough to prove the conversation is real (not echo).	power-user
`scenario`	No	Optional scenario nudge added to both personas' system prompts. Example: 'Topic: should the team switch from PostgreSQL to MongoDB? Have a real disagreement.' Leave empty to let the personas freestyle.
`smokeUrl`	No	URL of the smoke page on the LiveKit SFU droplet. Defaults to staging.	https://livekit-staging.comms.paradisemodern.com/smoke/
`paradiseBase`	No	Paradise Comms API base URL. Defaults to staging; pass production when ready.	https://comms.staging.paradisemodern.com
`paradiseToken`	Yes	Paradise Comms portfolio bearer token (e.g. paradise-staging_test_…). Get one by running scripts/seed-staging.ts in the paradisemodern repo, OR via POST /api/admin/comms/tokens as a super_admin.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	No	Tool result payload (JSON object)

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 27, 2026

changedInput schema / properties / turns / description

Previous value: -"Total back-and-forth turns. 6 means A→B→A→B→A→B. Cap of 20 to bound LLM + TTS + Whisper spend per test."New value: +"Total back-and-forth turns. 6 means A→B→A→B→A→B. Cap of 20 to bound LLM + TTS + STT spend per test."

First observedMay 25, 2026

TDQS

A4.1/5.0

Behavior4/5

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

With annotations covering safety (openWorld=true, idempotent=false, destructive=false), the description adds meaningful context: this makes a real WebRTC call with real audio and TTS/STT, consumes LLM/TTS/STT spend, and returns a transcript plus recording hint. It does not address auth requirements or rate limits, but adds real behavioral value beyond the annotations.

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-loads the core action (spawning personas on a real call) before elaborating on the mechanism and use case. Efficient, though slightly dense with parenthetical detail; every sentence still contributes relevant information.

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

Completeness4/5

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

An output schema exists so return values needn't be re-explained, and the description covers the real-call nature, purpose, and outputs. It is nearly complete for a moderately complex tool, with the only gap being explicit routing versus sibling test tools.

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 schema fully documents all 7 parameters including enums, defaults, and constraints. The description adds no parameter syntax or semantics beyond what the schema already provides, so the baseline 3 is appropriate.

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?

States a specific verb and resource: spawns two AI personas as participants on a real LiveKit voice call and runs a structured conversation. Explicitly distinguishes itself from simulation and from sibling 'submit' tools, making its identity unmistakable.

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

Usage Guidelines4/5

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

Names clear contexts: verifying Paradise Comms end-to-end (publisher → SFU → subscriber → recording → webhook) and demoing agent-to-agent voice. However, it never names an alternative tool or states when NOT to use this versus siblings like submit_test or submit_interaction_scene.

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

All TestMyVibes tools Inspect

Try in Browser

Let your AI agent see the webWeb-to-screenshot MCP for Claude, Cursor and Codex. No cookie banners. Free to start.snap-render.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?