JooVoice agent connection

Start on the JooVoice homepage (/) in a WebMCP-capable browser. The homepage
provides check_account, start_connection and wait_for_connection before sign-in.
You do not need a special connection page or the owner’s browser. Start with
check_account. If it is
not connected, call start_connection with {}. Show the owner the returned
matchingCode on its own line (bold or a code block if you can), then the
verificationUrl, so they compare the code with the page before approving. If your chat can show images, also show the
returned qrImageUrl as an image so they can scan it with their phone. They open
the link on their own phone or computer, sign in with JooVoice, compare the code
and approve your connection.

Call wait_for_connection with {} while they approve. Each wait is bounded;
follow checkAfterSeconds when still pending. On approval, discover the tools
again, call check_account, and continue. The page observes approval automatically.
Never request passwords, OTPs, cookies, access tokens or callback URLs in chat.
Never approve your own connection on the owner's behalf.

If check_account says setup is not ready, give the owner setup.link (and show
setup.qrImageUrl if you can). That page takes them through each step and checks
they are signed in to the account that approved you. Call wait_for_setup with
setup.version to hear each step as it happens. They type the texted code on the
page; never ask for it. Use start_welcome_call only after the owner says yes,
and first tell them the number it rings from (setup.welcomeCaller) so they can
save it as JooVoice. If they get lost, the same link reopens at the step they
are on. Someone new to JooVoice may take a spot in a sign-up wave on the way
in; the approval page carries on afterwards.

For an external MCP client, discover /.well-known/oauth-protected-resource/mcp
and its authorization server metadata. Use its configured MCP resource and
OAuth endpoints. Authorization code with PKCE remains supported. Clients that
support the advertised OAuth device grant can POST client_id, resource and scope
to device_authorization_endpoint, show user_code_display on its own line (the
code as the approval page prints it) and verification_uri_complete,
then poll token_endpoint with grant_type=urn:ietf:params:oauth:grant-type:device_code,
client_id, resource and device_code. Keep device_code and tokens in the client's
credential mechanism, never in chat. Honor interval, authorization_pending,
slow_down, access_denied and expired_token. Do not invent a callback or claim
support in a client that does not implement device authorization.

Permissions and the monthly preparation allowance come from the owner's
approval. With tasks:approve, read the owner the recap from the final-review
reply and ask for a fresh, explicit yes in the conversation before approve_call.
Without that scope, use the returned call-review link. Purchases and payment
settings stay with the owner; scheduling and extra paid time use the review page.
At the plan step, or when credits run short, get_payment_link makes a link
anyone can pay without signing in (the plan, or a credit pack). It spends
nothing; make it only after the owner says yes, send it only where they say,
and never ask anyone for card details in chat.
Replies are short: get_task with include fetches details, and get_guide explains
how prices, reviews, personal calls, timing and results work.
Use returned human-action URLs on the owner's device. A reply with sendToPhone
means the step needs their phone (a texted code, the welcome call, paying, a
review): if you can message them another way, offer to send the link there, and
only after they choose. Never ask them to send a code back. A disconnected or expired
connection requires a fresh approval; recover existing operations by their
original identifiers before creating replacements.

In a browser without WebMCP, open /connect and press "Connect this browser";
it shows the same matching code and approval link to relay. People can give
you the homepage URL or /connect. Owner approval links and Connected agents settings remain
separate, explicit human actions; signing in alone never grants a connection.