Is Vaaya MCP server safe?

Findings (2)

• highWrite-action tools reachable without authenticationauth.open-write
• lowUnusually long tool description (over 2,000 characters)poison.long-description

  tool buy: …Buy something for the USER — a physical good, a ticket, a subscription — paid by the user's OWN card, never from their Vaaya balance. First use `setup` to check the Link wallet and shipping address; resolve missing setup once. Prefer guest checkout; when login is required, let the user sign in or sign up in the checkout browser. THE SEAMLESS PATH: once the user has told you what to buy and you have the exact item, merchant page URL and total, call `purchase` { item, merchant, url, total_cents, confirmed: true, confirmation: <the user's own words> } — it approves from their message (under the chat limit), starts buying in the user's cloud browser in the background and returns `message` ("Hold on — buying it now."): RELAY IT, then poll `status` { approval_id } every ~10 seconds and relay its `message` when the status is completed ("Done — …"), requires_action (read action_required.reason for the exact blocker) or failed. If `status` says the user's shipping address is missing, ask for it and call `address` { name, line1, line2?, city, state?, postal_code, country, phone? } then `checkout` { approval_id } to resume; if a merchant login is needed, prefer direct browser sign-in; only if the user chooses to save credentials, call `credentials` { merchant, username, password } (stored encrypted, never shown again) then `checkout` again. Other sub-commands: `search` { query } (protocol merchants plus a real web search; the web half bills 5¢), `propose` { item, merchant, total_cents, url?, notes?, confirmed?, confirmation? } (creates an approval; without `confirmed` it returns an approval link the user opens — show its `message` VERBATIM), `checkout` { approval_id, params? } (buys an approved purchase; for a browser merchant it runs in the background like `purchase`). Use the user's existing authorization of the exact item and total; do not ask them to confirm twice. Ask only for missing purchase details. Nothing is ever bought without the user's yes: `checkout` refuses anything else. Use `reconcile` { approval_id } after an uncertain submission: it only inspects the existing checkout and never submits payment. Resume other pauses with the same approval_id; do not recreate a purchase to bypass an unresolved attempt. `charged_cents` is the Vaaya tool fee, NOT a merchant charge; read merchant_payment separately, and never infer a hold or capture from Link approval. Never open `browserbase` sessions yourself to buy something — only `buy` can.…