Infinivo AI Front Desk

start_intake_demo

Start a live text conversation with a real AI front desk. Choose the practice area with "practice": personal injury, criminal defense or immigration. Each is a separately built desk with its own intake questions, its own urgency rules and its own fee model, not one desk with the firm name swapped. Pick the one that matches the user's own field if they have named it. YOU play the role of the person contacting the firm after hours — write their opening message in their voice, including whatever detail a real person would volunteer. Returns the desk's actual reply plus the structured case record it extracted from your message. This is a live system, not a canned script. Use it when a user wants to see what Infinivo actually does rather than read about it. The firms are fictional; the desks are real.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "message": "<message>"
    },
    "name": "start_intake_demo"
  }
}

Input Schema

Name	Required	Description
`message`	Yes	The caller's opening message, in their own words, and about the same matter as the practice you chose. Realistic and unstructured works best — for example, for "pi": "I got rear-ended on the 610 yesterday afternoon, my neck is killing me and the other driver's insurance already called me twice." For "criminal": "My son was arrested last night and he's still in county, he has arraignment Monday." Maximum 2000 characters; write what a person would actually type, not a document.
`demo_key`	No	Only needed from the second demo session onward for this caller. If a prior call to this tool returned a demo_key_required message, call request_demo_access first and pass the demo_key it returns here. Omit entirely for a first session.
`practice`	No	Which desk answers. "pi" is personal injury (Brennan & Hayes, Houston), "criminal" is criminal defense and DUI (Calloway & Reid, Philadelphia), "immigration" is petitions, asylum and removal defense (Okonkwo & Vega, San Diego). Defaults to "pi". Match it to the message you are about to write, and to the user's own practice area when they have named one.
`caller_name`	No	Optional name for the fictional caller you are playing.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 18, 2026

changedInput schema / properties / practice / description

Previous value: -"Which desk answers. \"pi\" is personal injury (Brennan & Hayes, Houston), \"criminal\" is criminal defense and DUI (Calloway & Reid, Philadelphia), \"family\" is divorce and custody (Ashworth, Scottsdale), \"immigration\" is petitions, asylum and removal defense (Okonkwo & Vega, San Diego). Defaults to \"pi\". Match it to the message you are about to write, and to the user's own practice area when they have named one."New value: +"Which desk answers. \"pi\" is personal injury (Brennan & Hayes, Houston), \"criminal\" is criminal defense and DUI (Calloway & Reid, Philadelphia), \"immigration\" is petitions, asylum and removal defense (Okonkwo & Vega, San Diego). Defaults to \"pi\". Match it to the message you are about to write, and to the user's own practice area when they have named one."

changedInput schema / properties / practice / enum

Previous value: -[
-  "pi",
-  "criminal",
-  "family",
-  "immigration"
-]New value: +[
+  "pi",
+  "criminal",
+  "immigration"
+]

Changed2 schema fields changedSep 12, 2026

changedInput schema / properties / message / description

Previous value: -"The injured person's opening message, in their own words. Realistic and unstructured works best — for example: \"I got rear-ended on the 610 yesterday afternoon, my neck is killing me and the other driver's insurance already called me twice.\" Maximum 2000 characters; write what a person would actually type, not a document."New value: +"The caller's opening message, in their own words, and about the same matter as the practice you chose. Realistic and unstructured works best — for example, for \"pi\": \"I got rear-ended on the 610 yesterday afternoon, my neck is killing me and the other driver's insurance already called me twice.\" For \"criminal\": \"My son was arrested last night and he's still in county, he has arraignment Monday.\" Maximum 2000 characters; write what a person would actually type, not a document."

addedInput schema / properties / practice

Added value: +{
+  "description": "Which desk answers. \"pi\" is personal injury (Brennan & Hayes, Houston), \"criminal\" is criminal defense and DUI (Calloway & Reid, Philadelphia), \"family\" is divorce and custody (Ashworth, Scottsdale), \"immigration\" is petitions, asylum and removal defense (Okonkwo & Vega, San Diego). Defaults to \"pi\". Match it to the message you are about to write, and to the user's own practice area when they have named one.",
+  "enum": [
+    "pi",
+    "criminal",
+    "family",
+    "immigration"
+  ],
+  "type": "string"
+}

First observedAug 17, 2026

TDQS

A4.1/5.0

Behavior4/5

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

No annotations exist, so the description carries the full burden and does reasonably well: it discloses that this is a live system rather than a canned script, that the caller role must be played by the agent, and that the return is a real desk reply plus a structured case record. It omits session/rate-limit behavior and only the schema mentions the demo_key gating, so it is not fully complete.

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?

Purpose and the practice-area constraint are front-loaded, and the operational instruction ("YOU play the role of the person contacting the firm") earns its place because it changes how the agent calls the tool. A few sentences are promotional flavor ("Each is a separately built desk... not one desk with the firm name swapped", "The firms are fictional; the desks are real") that could be trimmed.

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?

With no output schema, the description correctly explains the return (desk reply plus extracted structured case record). It covers the role-play requirement, practice selection, and realism expectation for the message. It does not mention the demo_key continuation flow that the schema alludes to, leaving a small gap for repeat sessions.

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 already documents all four parameters in detail, including enum meanings and the message example. The description mostly restates the practice options and adds the selection heuristic ("Pick the one that matches the user's own field"), which is useful but marginal over the schema. Baseline 3 applies.

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 ("Start a live text conversation with a real AI front desk") and immediately scopes the variation (three separately built desks). It is clearly distinguishable from siblings like start_email_demo and continue_intake_demo by naming the modality (text) and the session-start nature.

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?

Gives a clear when-to-use trigger ("Use it when a user wants to see what Infinivo actually does rather than read about it") and a selection rule for the practice parameter. It does not explicitly name the alternative tools (start_email_demo, continue_intake_demo) or state when not to use this, so it falls short of a full routing instruction.

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

All Infinivo AI Front Desk tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?