JooVoice

Start a call request

prepare_task

Idempotent

Start one call request; destinations [] lets JooVoice find the business. Include what the owner told you in request and brief. JooVoice decides the language, accent and voice, so you don’t have to: state the request and its requirements in detail. Most calls check the owner can pay before JooVoice’s questions and charge when approved; older offers may charge during preparation. This connection’s limit applies. Retry a lost reply with the same operationId and input.

Input Schema

Name	Required	Description
`brief`	No	What you know that the call needs, one point per field, up to 300 characters each. Request and brief together fit 2,000 characters.
`request`	Yes	What the owner wants, in their words, with every name, number, reference and preference they gave. Before preparing, ask the owner in one message for what’s missing: each fact saves JooVoice a question. JooVoice decides the call’s language, accent and voice, so you don’t have to; a fact about the other side still counts, e.g. “she only speaks Italian”. For example, a table needs the day, time, how many, the name it’s under and what else would do (ask them; don’t assume flexibility); an appointment, the service, who should do it and whether anyone else is fine, when they’re free and their name; a refund or bill, the order or account number, the name on it, what went wrong, the amount and what they’d accept.
`timezone`	Yes	The owner’s IANA time zone, e.g. Asia/Singapore.
`direct_call`	No	Set true to ring the owner’s own phone directly, with no Start link. Only their current verified account number can be called this way; any other number fails. With destinations [], JooVoice uses that number. Preparing still doesn’t dial: you call approve_call. Normally ask whether they’re ready first; an explicit instruction, an agreed routine or urgency can justify going ahead without another reply.
`operationId`	Yes	A new unique ID you make up for each new request: 8–120 letters, digits, underscores or hyphens (a UUID works). Send the same ID and input only to retry.
`destinations`	Yes	Who to call: one number with its country code, e.g. +6591234567, or [] to let JooVoice find the business from the request.
`destinationTimezones`	No	The IANA time zone of a number you supplied, keyed by that number, when you know it, e.g. {"+14155550100":"America/Los_Angeles"}. Never put the owner’s time zone here.

Output Schema

Name	Required	Description
`hint`	No	Optional guidance for helping the owner at this step. Advisory; never a permission grant. Wording may change.
`next`	Yes	Calls to make next.
`status`	Yes	pending: check again later; requires_user_action: the owner must act; error: refused.
`meaning`	Yes	What happened, for you.
`sayToOwner`	Yes	A line for the owner.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 22, 2026

addedInput schema / properties / direct_call

Added value: +{
+  "description": "Set true to ring the owner’s own phone directly, with no Start link. Only their current verified account number can be called this way; any other number fails. With destinations [], JooVoice uses that number. Preparing still doesn’t dial: you call approve_call. Normally ask whether they’re ready first; an explicit instruction, an agreed routine or urgency can justify going ahead without another reply.",
+  "type": "boolean"
+}

First observedOct 17, 2026

TDQS

A3.7/5.0

Behavior4/5

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

Annotations cover safety and idempotency, and the description adds non-obvious behavior: that most calls verify the owner can pay before questions and charge when approved, that older offers may charge during preparation, and that connection limits apply. "This connection's limit applies" is vague about what the limit is, which keeps it from a 5.

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

Conciseness3/5

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

Purpose is front-loaded and the paragraph is short, but sentences are dense and slightly garbled ("JooVoice's questions", "This connection's limit applies") without explaining what the limit is. Some clauses, particularly the charging aside, are compressed to the point of ambiguity.

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?

For a mutation tool with billing implications, the description covers the essential non-schema facts (delegated business lookup, voice selection, retry/idempotency, approval gate) and an output schema exists so returns needn't be described. Missing is any statement of preconditions such as account/credit state.

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

Parameters4/5

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

Schema coverage is 100%, so the schema already documents each field. The description still adds value by explaining that destinations [] delegates business lookup, that JooVoice chooses language/accent/voice so the agent needn't supply them, and that retries reuse the same operationId with identical input.

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?

Opens with a concrete verb and resource: "Start one call request," and clarifies the destinations [] case where JooVoice finds the business. It hints at the approval flow ("charge when approved") but doesn't explicitly contrast with siblings like approve_call or revise_task in the description body.

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

Usage Guidelines3/5

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

"Include what the owner told you in request and brief" and the retry-on-lost-reply rule give some operational guidance, and the charging note implies the approval step follows. But the description never states when to use this vs. revise_task, approve_call, or retry_call, leaving the lifecycle routing to the schema.

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

All JooVoice 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?