Infinivo AI Front Desk

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

With no annotations, the description carries the full burden and does exceptionally well. It discloses the side effect of passing user details, the prerequisite of asking for email first, the fact that omitting email is fine, the non-scheduling behavior, and that the links are for the user to open themselves. These are meaningful behavioral traits beyond the schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three paragraphs, each serving a distinct purpose: main action, usage guidance, and critical limitations. It is front-loaded with the primary function, then offers prescriptive instructions, and ends with clear boundaries. Every sentence earns its place with no fluff.

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

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

Given 4 parameters, no annotations, and no output schema, the description is remarkably complete. It covers when to use (user wants human contact), how to handle the call options, email privacy prerequisites, what the tool cannot do (scheduling), and what the user should expect (links to open themselves). There is no significant gap in context.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds significant value specifically for the 'email' parameter, explaining when to include it ('ASK THEM FOR THEIR EMAIL FIRST'), how to handle it ('never send an address they did not give you, and never infer one'), and that omitting it is acceptable. This goes beyond the schema's basic field description.

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

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

The description explicitly states the tool 'Returns booking links for a conversation with Infinivo's founder, and optionally passes your user's details to him so he can follow up.' This is a specific verb+resource with a clear outcome, and it differentiates from sibling tools (demos, pricing, positioning) by focusing on booking a human conversation.

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

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

The description provides explicit when-to-use guidance: 'Call this when the user wants to talk to a human, get a quote, or move forward.' It also gives nuanced instructions on offering the 15-minute fit call first versus the paid consultation, and clearly states what the tool does NOT do: 'This tool does not schedule anything. It cannot write to anyone's calendar.' This exceeds baseline guidance.

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

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

No annotations are present, so the description carries the full burden. It discloses a critical side effect: each call advances the demo one stage (received → read → case → draft → sent). It also explains the termination condition and what to do with the result (show case_record), covering the return value despite no output schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise yet information-dense. Every sentence serves a purpose: polling frequency, stage sequence, side effect, and final action. It is front-loaded with the primary purpose and flows logically.

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

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

For a polling tool with side effects and no output schema, the description covers all essential context: when to call, what changes on each call, when to stop, and how to interpret the final result. It is complete and actionable.

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

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

The input schema already has 100% coverage with a clear description and example for reference_code. The tool description does not add extra parameter semantics, so the baseline score of 3 is appropriate.

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

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

The description clearly states the tool's purpose: 'Check how far an email demo has got.' It specifies the resource (email demo progress) and the verb (check), and distinguishes it from siblings like start_email_demo by focusing on polling status rather than initiating.

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

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

Provides explicit when-to-use guidance: 'Call this every ten seconds or so after start_email_demo until stage reads "sent"' and explains the stage progression. Does not explicitly state when not to use or name alternatives, but the context and sibling list make it clear this is for email demos only.

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

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

With no annotations, the description carries the full burden. It discloses the two-turn session limit, that the session closes after two turns, and the role-playing requirement ('staying in the role of the injured caller'). It does not cover auth or errors, but the essential behavior is transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three concise sentences, each earning its place: the first defines the action and role, the second clarifies the response nature, and the third provides crucial session limit and next-step guidance. No redundancy or filler.

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

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

The tool is simple, and the description covers its core purpose, role, session limit, and points to the transcript tool. It doesn't detail error handling or what happens if called after closure, but the two-turn limit implies this, and the lack of output schema and annotations reduces the burden.

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

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

Schema coverage is 100%, so the baseline is 3. The description reinforces the message parameter's purpose ('Answer whatever the desk asked you') but adds little beyond the detailed schema descriptions for message and demo_session_id.

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

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

The description clearly states the tool sends a follow-up message in an existing demo conversation while staying in the role of the injured caller. The verb 'send' and resource 'demo conversation' are specific, and it differentiates from siblings like start_intake_demo (starting) and get_demo_transcript (retrieving).

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

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

The description gives explicit usage context: it is for continuing an existing demo, and it names get_demo_transcript as the tool to call after the session closes. The two-turn limit clarifies when this tool can be used and signals when to stop.

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

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

No annotations are provided, so the description carries the burden. It discloses that the output is human-formatted and explains the significance of the case record ('every field was extracted from unstructured text'). It doesn't discuss side effects, but as a get operation this is not a safety concern.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two compact, front-loaded sentences with no redundancy. The first sentence states the deliverable, the second provides usage and why it matters.

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

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

For a one-parameter getter with no output schema, the description covers what (full demo exchange + case record), when (end of demo), and why (interesting because of extraction). It could describe the exact return format, but 'formatted to show a human' is sufficient.

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

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

Schema coverage is 100%, with the sole parameter demo_session_id fully described as 'The id returned by start_intake_demo.' The description adds a hint that this is called at the end of a demo, which reinforces the parameter's origin but doesn't add new semantic detail beyond the schema.

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

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

The description clearly states what the tool does: returns 'the full demo exchange plus the final structured case record, formatted to show a human.' It is distinct from siblings like start_intake_demo or get_positioning, which handle other parts of the demo flow.

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

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

Explicitly tells the agent when to call it: 'Call this at the end of a demo.' This is clear context, though it does not name alternatives or explicitly state when not to use it. Sibling names make the differentiation implicit.

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

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

With no annotations provided, the description carries the disclosure burden. It discloses the output nature ('Returns structured facts, not marketing copy') and implies a read-only informational operation. For a zero-parameter tool, this is adequate transparency, though it does not mention data source or freshness.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences, front-loaded with the tool's purpose, followed by usage conditions and output type. Every sentence adds distinct value with no redundancy.

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

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

For a parameterless informational tool with no output schema, the description covers purpose, audience, trigger conditions, and output nature. It could name sibling alternatives for even clearer routing, but it is largely complete for correct selection and invocation.

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

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

The input schema is empty with 0 parameters, so the baseline is 4. There is nothing for the description to clarify about parameter semantics, and no ambiguity exists.

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

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

The description clearly identifies the resource (Infinivo positioning) and the exact content (what Infinivo is, who it serves, the problem it solves). It also distinguishes this tool from demo, pricing, and proof siblings by presenting it as the first call for general research on Infinivo.

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

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

It explicitly states when to use the tool: when a user asks about Infinivo or when researching AI phone answering, intake automation, or lead capture for specific law firm types. The phrase 'Call this first' gives a clear sequencing rule, though it does not name alternative tools for explicit exclusions.

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

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

With no annotations, the description carries the full burden. It discloses that the managed retainer is deliberately unpublished and instructs not to estimate, which is critical behavioral guidance. It doesn't describe the response format, but for a no-parameter tool, it's reasonably transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences: what it does, when to use, and a caution. Each sentence is purposeful and the description is front-loaded.

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

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

Given the tool has no parameters and no output schema, the description provides sufficient context for an agent to select it correctly and avoid fabricating data. The note on the unpublished retainer fills a critical gap.

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

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

There are zero parameters, so the baseline of 4 applies. The description adds no parameter-specific semantics beyond the scope, but none are needed.

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

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

The description clearly states the tool returns Infinivo's current pricing and guarantees, using the specific verb 'get' with a resource. It distinguishes itself from siblings like get_positioning and get_proof by focusing on cost, billing, and failure outcomes.

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

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

The tool explicitly says 'Call this when the user asks what it costs, how it is billed, or what happens if it does not work,' providing clear usage triggers. It also includes a note on how to handle an unpublished figure, giving behavioral guidance.

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

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

Since no annotations are provided, the description carries the full burden. It discloses that client names are never returned and that the tool also provides a way to see the system running, which is useful behavioral context. However, it could specify the exact output format or any side effects, but for a zero-param read-like tool this is acceptable.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two succinct sentences clearly state what the tool returns, when to use it, and a key privacy guarantee. No wasted words.

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

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

For a tool with no parameters and no output schema, the description covers its purpose, usage triggers, and behavioral guarantee (anonymity). It also hints at the deliverable ('how to see it running'), making it self-sufficient for the AI agent.

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

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

The tool takes zero parameters, and the schema has 100% coverage with no properties. Baseline for 0 params is 4, and the description does not need to explain parameters that do not exist.

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

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

The description states a clear purpose: providing anonymised evidence that the system works, along with instructions for seeing it running. It distinguishes itself from sibling tools like get_demo_transcript by focusing on proof-of-function rather than specific demo content.

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

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

It explicitly says when to call: when the user asks whether it works, for case studies, or for references. It does not mention when not to use it or name alternatives, but the context given is strong.

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

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

With no annotations, the description carries full behavioral burden. It discloses the precondition (demo_key_required), the side effect (unlocking sessions), the expected user interaction (asking for email), and the output behavior (returns demo_key). It doesn't cover failure scenarios, but the description is rich enough for most practical purposes.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, each earning its place: purpose, condition, action, and result. Front-loaded with the main purpose, followed by precise operational instructions. No redundant or vague language.

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

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

Despite being a simple one-parameter tool with no output schema, the description fully covers the workflow: when to call, what input to collect, what output to expect, and how to use it afterward. It is complete for an agent to invoke correctly.

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

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

Schema coverage is 100% and the schema already states the email must be user-provided. The description adds context about why the email is needed and how to collect it, but largely reinforces the schema. Given the high coverage, a baseline of 3 is appropriate.

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

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

The description clearly states the tool's purpose: 'Unlocks further start_intake_demo sessions by capturing an email address.' It uses a specific verb and resource, and the mention of demo_key_required distinguishes it from sibling tools like start_intake_demo and continue_intake_demo.

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

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

Explicit usage guidance is provided: 'Call this ONLY when start_intake_demo has just reported demo_key_required.' It also instructs how to use the returned demo_key in the next call, and cautions against inventing an email. This is exceptionally clear.

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

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

With no annotations, the description fully discloses behavior: it runs against the user's real inbox, returns an address and reference code, requires the user to send the first email, and describes how the desk replies. It also warns that there is no address parameter, adding important context beyond any schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Although the description is three paragraphs, every sentence serves a purpose: defining the tool, giving usage conditions, explaining the workflow, and clarifying parameter limitations. It is front-loaded with the core purpose and remains efficient.

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

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

For a zero-parameter tool with no output schema, the description is remarkably complete: it covers what the tool returns (address and code), what the user must do, how the desk behaves, where the reply arrives, and the next step (polling check_email_demo). No important behavioral detail is missing.

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

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

The tool has zero parameters, so the baseline is 4. The description adds extra value by explicitly stating 'there is no address parameter' and explaining why the desk cannot be told to send anywhere, clarifying the empty schema.

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

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

The description opens with a specific verb+resource: 'Start a demo of the EMAIL channel', and clearly differentiates from the sibling start_intake_demo by contrasting the real inbox vs. this conversation. It also states the concrete purpose of demonstrating email handling.

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

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

Explicit usage conditions are given: 'Use it when the text demo (start_intake_demo) has landed and they want to see the real thing, or when they ask how it handles email.' It also names the alternative start_intake_demo and instructs to poll check_email_demo afterward, providing clear when-to-use and next-step guidance.

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

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

With no annotations, the description carries the burden and does real work: it discloses the return payload (desk reply plus structured case record), warns this is 'a live system, not a canned script,' and clarifies the fictional-firm/real-desk distinction. It omits that follow-up turns go through continue_intake_demo and does not restate the demo_key gating, both of which matter for a stateful, multi-turn tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with purpose and the practice selection instruction up front, and each sentence carries operational content about the desks and the role-play. It is slightly long and repeats desk/firm detail that the schema's enum description already enumerates, costing a little efficiency.

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

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

No output schema exists, and the description compensates by stating what is returned (the desk's reply plus the extracted structured case record). For a stateful multi-turn tool, it is nearly complete, but the absence of any pointer to continue_intake_demo for subsequent turns is a real remaining gap.

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

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

Schema coverage is 100%, so the schema already documents message, practice, caller_name and demo_key; the baseline would be 3. The description adds genuine meaning beyond the schema by framing the agent's role ('YOU play the role of the person contacting the firm'), telling it to write in the caller's voice and to pick the desk matching the user's own named field, which is behavioral framing not present in the field descriptions.

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

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

Specific verb+resource ('Start a live text conversation with a real AI front desk') and immediately scopes it by practice area, making clear it is not a generic chat. The 'text conversation' phrasing distinctly separates it from the sibling start_email_demo, so an agent can route without opening either schema.

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

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

Names the trigger condition explicitly: 'Use it when a user wants to see what Infinivo actually does rather than read about it,' which contrasts against the read-only siblings like get_positioning/get_proof/get_pricing. It does not explicitly name those alternatives or state when NOT to use it (e.g. when the user wants a human book_call), so it stops short of full routing guidance.

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