Skip to main content
Glama

Submit a test job

submit_test

Queue a new TestMyVibes job for a given URL. You explicitly choose the runner: AI agent (headless Chromium + GPT-4o vision, fastest, deterministic for well-specified goals) or human checker (slower, better for visual/UX judgment calls). Returns a jobId you can poll with get_test_status.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlYesThe URL to test. Must be publicly reachable.
goalNoAI runner only. CONCRETE success criterion the agent stops on — e.g. 'Reach a URL containing /dashboard', 'See a Welcome banner on the page header', 'Receive an OTP email and submit the code'. Without a goal the AI runs out its step budget on exploration instead of completing a flow.
runnerNoWho runs the test. 'ai' = headless browser + GPT-4o vision agent (default; use for deterministic flows, signup/login, regression checks). 'human' = real human checker on TMV's panel (use for visual/UX judgment, complex flows the AI can't drive, accessibility passes).ai
jobTypeNoTest category — defaults to 'General QA'. Affects credit cost when billed.General QA
priorityNoJob priority.normal
targetOSNoHuman-runner advisory string for OS (e.g. 'iOS 17', 'Android 14', 'macOS 14'). Surfaced on the checker's claim card.
viewportNoExplicit viewport for non-preset resolutions (e.g. {width: 2560, height: 1440} for a 27" desktop monitor). Wins over devicePreset only when devicePreset is NOT set. Use devicePreset for known phones/tablets and viewport for custom resolutions.
projectIdNoExisting project to attach this job to (optional).
offeringIdNoMarketplace offering id (browse via list_worker_offerings). When set, this job is priced + routed through the marketplace: the customer pays the offering's `creditsCharged` and the worker who fulfills the job earns the offering's pre-locked `workerPayoutCredits` (75% of charged). When omitted, the legacy personality/step-based pre-flight quote applies.
slaMinutesNoTarget turnaround in minutes (human runner only; AI runs finish in ~1-5 min regardless).
descriptionYesPlain-English description of what to test. The platform uses this to seed a checklist.
mcpEndpointNoMCP Auditor only. URL of the MCP server to audit (e.g. https://api.example.com/mcp). Pair with `personalityOfferingId: 'mcp-smoke'` or `'mcp-full-audit'`. The MCP Auditor runs JSON-RPC against this endpoint instead of opening a browser at `url`.
recordVideoNoAI runner only. WebM video recording of the entire browser session. Defaults on; set false to opt out. When true, the worker captures a continuous screencast via Puppeteer and uploads it to Spaces; signed URL surfaced in get_test_results.aiReport.videoUrl. Free — no credit charge. 30-day retention same as step screenshots. Ops can globally disable the default with AI_RECORD_VIDEO_DEFAULT=false.
useSmsInboxNoAI runner only. When true, TMV provisions a throwaway phone number from Paradise's SMS test-number pool (US/CA available) bound to this run. The agent uses it for any phone field, and `wait_for_sms` blocks until verification SMS arrive. Required for phone+OTP signup flows. Pool is finite — release reserves the number for ~15min then auto-releases.
devicePresetNoOptional device emulation. Pass a Puppeteer KnownDevices name (e.g. 'iPhone 14 Pro', 'iPad Mini', 'Pixel 5', 'Galaxy S9+') and the AI agent runs the test as that device — proper viewport, touch events, user-agent, and DPR. No markup; this is the same Chromium with different emulation flags. Use list_device_presets to see the full 131-device catalog or the curated featured subset. For human runners this is advisory and surfaced on the checker's job card.
identityModeNoAI runner only. 'auto' infers when a signup/OTP flow needs a TMV inbox/persona; 'fresh' forces a new persona/inbox for this run; 'keep' creates a managed retained identity with a persistent inbox and saves credentials after a passing signup; 'reuse' signs in with testIdentityId/existingPersonaId; 'none' disables identity provisioning.auto
mcpTransportNoMCP Auditor only. Transport protocol the customer's MCP server speaks. Most servers built with @modelcontextprotocol/sdk use streamable-http; older ones use sse. No stdio support (we don't run customer code in TMV's sandbox).streamable-http
projectLabelNoAudit label naming which of your projects submitted this test (e.g. 'pm-claude-code', 'shiftsee-claude-code'). Not used for auth.
targetDeviceNoHuman-runner advisory string naming the device (e.g. 'iPhone 14 Pro', 'Pixel 7'). Surfaced on the checker's claim card so they know which device to test on. No effect for AI runners.
useTestInboxNoAI runner only. When true, TMV provisions a per-job inbox at `<job-prefix>-<random>@inbox.testmyvibes.com` bound to this run. The agent uses it for any email field, and `wait_for_email` blocks until verification emails arrive. Required for OTP / email-verify flows; pointless for read-only tests.
mcpAuthHeaderNoMCP Auditor only. Optional auth header passed to the MCP endpoint (e.g. 'Bearer <token>', 'X-API-Key: <key>'). Format: 'HeaderName: value'. Used verbatim on every JSON-RPC request.
targetBrowserNoHuman-runner advisory string for browser (e.g. 'Safari', 'Chrome', 'Firefox'). Surfaced on the checker's claim card.
videoCallTestNoAI runner only. Video/voice call testing (human↔AI calls, WebRTC flows): Chrome launches with a fake camera+microphone (auto-granted; synthetic pattern/tone media the far side really receives) and every RTCPeerConnection on the page is instrumented. The agent gains the check_call_media action, returning hard metrics — ICE state, time-to-first-frame, fps, resolution, packet loss, freezes, and whether remote audio is actually AUDIBLE. The raw metric timeline is surfaced in get_test_results.aiReport.callStats. Screenshots cannot distinguish a live call from a frozen frame; instruct the agent to start the call, then use check_call_media (~10s settle), then re-check later to confirm the call is sustained. For human↔human two-browser calls use submit_interaction_scene with videoCallTest on each role.
sessionCookiesNoAI runner only. Session injection — pre-authenticated cookies planted on the browser BEFORE the first navigation, so the agent starts already signed in and skips the login/OTP gate. Purpose-built for gated flows (photoreal video calls, member dashboards) where driving an email-OTP login with the vision agent is slow and flaky. Obtain a real session however you like (server-to-server auth, a scripted OTP redeem) and pass the cookies here; they're domain-scoped to the test URL at inject time and never echoed back in results. Combine with videoCallTest to land a logged-in agent directly on a call surface.
testIdentityIdNoAI runner only. Managed retained identity id from list_test_identities/create_test_identity. If it already has credentials the worker signs in as that returning user; if not, the worker uses its persistent email/persona for a fresh signup and saves credentials on PASS.
useFakeProfileNoAI runner only. Adds depth to the test persona beyond default username/displayName/bio. 'basic' (+1 credit): generates a physicalProfile JSON (age, height, hair color, eye color, etc.) so any open-ended profile fields are filled with consistent realistic values. 'full' (+2 credits): basic + 2 photorealistic Flux Schnell photos uploaded to TMV Spaces and exposed to the agent as signed URLs for avatar / profile-image uploads. Skip this for read-only tests; use 'basic' for profile-completion tests; use 'full' for photo-required signup flows.off
keepTestAccountNoAI runner only. When false (default), signup tests end by deleting the account they created so customer user tables don't accumulate orphan rows. Set true to KEEP the account alive after the test — the persona's credentials are persisted so a later submit_test with `existingPersonaId` can sign in as a returning user (repeat-testing offering). Costs more (persona retention fee) but saves signup steps on every subsequent run.
smsInboxCountryNoAI runner only. Used with useSmsInbox=true. Country code of the throwaway number to rent. US (default) covers most American/Canadian flows; CA needed for sites that gate by destination country. India is NOT available (Telnyx has no IN inventory).US
syntheticVisitorNoParadise Modern Growth Kit structured input. When present, TMV queues a Synthetic Visitor Test: an AI visitor simulation focused on CTA/A-B conversion completion rather than general QA.
targetScreenSizeNoHuman-runner advisory string (e.g. '1920x1080', '390x844'). Stored on the job and surfaced on the checker's claim card. No effect for AI runners — use devicePreset or viewport instead.
agentInstructionsNoAI runner only. Verbal step-by-step the vision agent follows. Pin exact field values here (e.g. 'When asked for a name use "QA Tester"; when asked for a password use "TestPass!2026"'). Without this the agent invents values and tests become non-reproducible. By default these are advisory — set strictAgentInstructions=true to enforce them as hard rules.
existingPersonaIdNoAI runner only. Task #30 repeat-test. Set to the personaId of a previously-kept persona (from a job submitted with keepTestAccount=true). The worker skips provisioning + signup and instead reuses the persona's stored email + password to log straight in. Use this to exercise return-user flows (profile edits, dashboards, settings, follow-up actions) without paying for signup every time. Discounted -1 credit per run; persona retention itself costs 2 credits per 30-day window (first persona per project free). Call list_device_presets to see all device names.
personalityOfferingIdNoPersonality menu offering id (browse via list_personality_offerings). Locks the step budget, inbox provisioning, personality, and price to the offering. Mutually exclusive with offeringId — offeringId routes to a worker; personalityOfferingId is an AI-only packaged test priced by TMV.
strictAgentInstructionsNoAI runner only. When true, agentInstructions are enforced with a stronger preamble + post-step self-check ("Did my last action violate any rule? If yes, reverse course before continuing"). Use for OTP / mid-form flows where one wrong click (extra OTP request, dropdown change after submit) invalidates state. Default false — instructions are advisory, the agent uses judgment.
expectedEmailFromContainsNoAI runner only. Pin the wait_for_email fromContains filter (substring of the sender address). Use when the sender domain isn't the obvious test target (e.g. delivered from sendgrid.net but the site is acme.com).
provisionTestCardFundedUsdNoAI runner only. Mints a Stripe-Issuing test-payment card just-in-time when the worker picks up this job, funded to this USD amount. The PAN is held in-memory only — never touches the Job record, never returned to the caller. The AI agent receives it via the system prompt and types it at the customer's checkout. Card is frozen automatically at end of run (or 24h, whichever first). Billed at funded + 25% markup + $2 service fee. Currently sandbox-only — cards auth against Stripe test-mode merchants only until live activation lands.
expectedEmailSubjectContainsNoAI runner only. Pin a case-insensitive substring the AI agent MUST use as wait_for_email's subjectContains filter. Useful when your customer's verification email subject doesn't match the site name (e.g. site is 'newvibecity.com' but email subject is 'Newvibecityhotel sign-in code'). Without this, the agent guesses from the URL/brand and can timeout on wrong filters. Surfaced in the system prompt with strict instructions.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultNoTool result payload (JSON object)

TDQS

A4.7/5.0
Behavior5/5

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

The description discloses numerous behavioral traits beyond the annotations: queueing behavior, run times (~1-5 min AI, slower human), effects like video recording, identity provisioning, SMS inbox, and cookie injection. It also mentions polling for results and credit costs. No contradictions with 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?

The description is fairly concise for the complexity (37 params). It is front-loaded with the core purpose and runner options. Some detail could be trimmed (e.g., repeating 'Returns a jobId' is clear from context), but overall it is well-structured and efficient.

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?

Given 37 parameters, 2 required, 100% schema coverage, and existence of output schema, the description is remarkably complete. It covers parameter relationships, dependencies, and edge cases (e.g., viewport vs devicePreset, offeringId vs personalityOfferingId). It also explains nuanced features like video call testing and synthetic visitors.

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

Parameters5/5

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

Schema coverage is 100%, but the description adds substantial meaning. For example, it explains the purpose of runner, goal, useSmsInbox, recordVideo, and agentInstructions, including constraints and best practices (e.g., 'Without a goal the AI runs out its step budget'). This goes well beyond the schema descriptions.

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 clearly states it queues a test job for a URL, explains the two runner types (AI agent vs human checker), and indicates the return value (jobId). It distinguishes from sibling tools like submit_test_batch or submit_conversation_test by focusing on a single test job with explicit runner choice.

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?

The description gives clear guidance on when to use AI vs human runner, e.g., 'AI agent... fastest, deterministic for well-specified goals' and 'human checker... slower, better for visual/UX judgment calls'. It does not explicitly mention when to use this tool over siblings, but the contrast is implied.

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.

TDQS

A3.9/5.0
Disambiguation4/5

The tools cover a wide range of functionalities, but each has a clearly distinct purpose. For example, submit_test, submit_test_batch, submit_combo, and submit_interaction_scene are all different types of submissions with unique parameters. However, the sheer number of tools (43) might cause some initial confusion, but descriptors resolve ambiguity.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in snake_case (e.g., list_projects, create_project, get_test_results). The only exception is 'whoami', which is a common idiom and does not break the pattern. Overall, naming is highly predictable.

Tool Count3/5

43 tools is on the high side for a single server. The domain is broad (testing, worker marketplace, credits, cards, feedback, video), so the count is justifiable. However, it borders on being overwhelming, and some tools could be consolidated (e.g., multiple submit_* variants).

Completeness3/5

The tool surface covers core workflows like project creation, test submission, result retrieval, worker management, and credit operations. However, there are gaps: no update or delete for projects, no delete for worker offerings, and no user-facing combo editing (though combos are predefined). These are minor but noticeable.

Resources