Is Otto Intel MCP server safe?

Findings (3)

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

  tool otto_delegation_cap: …TWO PHASES, both header authed, both resolving the end user from the access token. { phase: "reserve", accessToken, perSwapCapUsd, requestedDays, mintKey } takes a generation-bound unified mint claim, picks a whole-second expiry instant at or BEFORE the requested duration that no durable row for this user already occupies, writes the chosen cap (whole USD, 1…5000) against it, and answers { expires_at, mint_expires_at, per_swap_cap_usd, recorded }. Call createDelegation with mint_expires_at EXACTLY as given — it is the reserved instant plus a one-millisecond filler, because CDP refuses an expiry ending .000 and truncates the filler away — and with mintKey as the idempotencyKey. Then { phase: "confirm", accessToken, mintKey } re-reads the grant from CDP and promotes only the exact still-current claim whose reported instant IS the reserved one. A mismatch, Stop overlap, or stale claim remains unconfirmed and authorises nothing; no confirm path issues CDP's user-wide revoke because that could delete a newer permission, so use a fresh explicit Stop to revoke whichever permission is current. Why this shape: Coinbase issues no grant id and a send can learn nothing about a live grant except its expiry, so the expiry is made an identity BY CONSTRUCTION — reserved server-side, recorded before the mint, asserted after it. Until a reservation is successfully confirmed active, otto_submit_under_delegation refuses that delegation (DELEGATION_CAP_UNCONFIRMED) rather than falling back to the 5000 USD ceiling. A reservation is IMMUTABLE per mint key — pressing again returns the same instant and cap, and an older revoke generation cannot be revived. Coinbase's engine cannot hold this number: end-user accounts are fenced by ONE project-scope policy shared by every delegated user, so a lower per-user cap is enforced by Otto's server alone. Server-to-server only: the caller presents Otto's delegation secret in the `x-otto-delegation-auth` request header (never in arguments); a call without it is refused before anything is read. The listed input schema is intentionally permissive — the strict schema is validated after the caller is authenticated.…

• lowNo source repository listedmaint.no-repo