manage_sms_number appears only for accounts that can assign Pomerado phone numbers, and sign_in only where device sign-in is enabled.
This page lists each tool as tools/list returns it. Your client lists the same tools, so read the live list when this page and your client differ. Results and job behavior are in jobs and MCP tool results; error codes are in errors.
Website tools and jobs
find_website_tool
Find a ready-made Pomerado tool for a task on a website, instead of using a browser, Playwright, computer use or fetching the page. Tools cover searching flights, hotels and rentals; booking and reserving; shopping, comparing prices and checking out; checking orders, deliveries, claims, bills and account pages; and filling in forms, on sites such as Amazon and Google Flights. Search by query, siteOrigin or both, or pass id alone to get one tool. Run a match with run_website_tool, passing its id as operation_id; when nothing fits, build_website_tool makes one. With siteOrigin, possible_matches also lists the site’s tools that may cover the task, disabled ones included.
Effect: Reads only; changes nothing.
run_website_tool
Run a Pomerado website tool once and return its validated result, usually in seconds, instead of driving a browser, Playwright or computer use or fetching the page. Pass the tool’s id from find_website_tool as operation_id. A client that accepts SSE gets a stream that waits up to 5 minutes for the result, with progress while the job runs. Any other client waits up to 50 seconds. A run that asks a question returns input_required at once. A job still running then returns status “running” with its job_id; follow its next block (get_job with wait_seconds) instead of calling again. Protected input may require continuation. An operation that signs in uses the site’s saved login first; pass connected_account_id to choose among several. website_auth is used only when no login is saved for the site, and one that differs from a saved login is refused. Without either, the run asks the user for the login on its protected page and may save it. A job that reports status needs_credentials (the website rejected its saved login; a run waits only when nothing was changed, and a build that may have changed the website checks that on resuming, as possible_commit says) waits up to 60 minutes for the user who started it to correct that login, then resumes as the same job; its next names the page to correct it. Do not resubmit it. Values passed here are visible to your client and its model provider; the protected form keeps them out of this conversation. Pomerado keeps them from the minting model, traces and logs either way. Send a retry_key with every write and reuse it only to retry that same call. A call without a retry_key is a new website action.
Effect: May change a website or your account, and a change may not be undoable.
build_website_tool
Build a new Pomerado tool for a task on a website when find_website_tool finds none, instead of doing the task with a browser, Playwright, computer use or web fetch. A build takes about 10 minutes and runs the requested example once, and the tool is reused after that: tell the user it is building, then follow the job with get_job. The returned job preserves that example result; do not repeat a completed website action. Builds for ticket, bank and government sites are refused with site_not_supported. A website build requires effect. Use read when the operation only looks things up. Use write when it changes the website: filling in or advancing a form that saves data (an application, profile or checkout) is a write, as are submitting, booking, drafts, holds, uploads and account updates; a search, filter or query form is a read. Use ask when unsure: before anything runs, the build asks read or write as a pending input request (get_job shows it; answer with answer_job). A read build that finds its task needs a website change asks the same way before switching to a write. Omit site_origin for offline parsing, which is always a read. Set entry_url only to the exact requested https page on site_origin; the host opens it before the build starts. Website login: without connected_account_id or website_auth the build stays anonymous; if it signs in, it uses the site’s saved login, asks the owner which one when several could sign in, and asks through the protected form only when none is saved. With website_auth, a saved login for the site with the same username is used instead, and a different username is refused. A job that reports status needs_credentials (the website rejected its saved login; a run waits only when nothing was changed, and a build that may have changed the website checks that on resuming, as possible_commit says) waits up to 60 minutes for the user who started it to correct that login, then resumes as the same job; its next names the page to correct it. Do not resubmit it. Values passed here are visible to your client and its model provider; the protected form keeps them out of this conversation. Pomerado keeps them from the minting model, traces and logs either way.
Effect: May change a website or your account, and a change may not be undoable.
get_job
Get the status and authorized result of a job. Pass wait_seconds to wait: the call returns the moment the job asks a question or finishes, and when the wait ends with the job still running (call again then). A client that accepts SSE waits up to 1800 seconds with progress; any other waits at most 50 seconds. A result for a live job carries next, the exact call to make next. With wait_past naming a question already handed to the user, the wait holds while that question is pending. During a wait, a client that supports elicitation asks the user the job’s question itself: a form for plain questions, the protected page for secrets and logins. A build that published a tool, or found an existing tool that covers its request, returns that tool as tool. Run an enabled one with run_website_tool, passing its id as operation_id. Never ask for passwords in chat: when a job needs a login, a code or an approval, give the user protected_input_url and keep waiting here. Follow a job until it finishes and never start the same job twice. A job that reports status needs_credentials (the website rejected its saved login; a run waits only when nothing was changed, and a build that may have changed the website checks that on resuming, as possible_commit says) waits up to 60 minutes for the user who started it to correct that login, then resumes as the same job; its next names the page to correct it. Do not resubmit it.
Effect: Reads only; changes nothing.
answer_job
Answer the pending input request that get_job lists as pending_input, every question at once. Pass request_id and request_version from it and answers keyed by question id: choice, an option id (or {“other”: text} when allowOther); multi_choice, an array of option ids; text and secret, a string; confirm, {“confirmed”: true|false}; credential, {“username”, “password”, “saveLogin”}. With job_id alone this returns the protected page, which keeps secrets and logins out of this conversation; answer a secret or credential here only if the user agrees. Values passed here are visible to your client and its model provider; the protected form keeps them out of this conversation. Pomerado keeps them from the minting model, traces and logs either way. Never send TOTP seeds or durable tokens.
Effect: May change a website or your account, and a change may not be undoable.
cancel_job
Request cancellation of a job. A dispatched website effect may already have occurred.
Effect: May change a website or your account, and a change may not be undoable.
list_logins
List entitled saved logins’ metadata, as GET /v1/connections lists it: ID, label (null when the owner set none: call that login “<website host> · <masked identifier>”, such as “anthem.com · jo***om”), website, masked sign-in identifier with identifierKind (username, email, phone or account number), authMode (password or code), and for Personal accounts loginStatus and firstSuccessfulLoginAt (the identity locks after the first verified sign-in), and whether a Pomerado text-message number reads its codes. Never a password or other secret.
Effect: Reads only; changes nothing.
manage_connection
Open a protected browser page to create, update, import, reveal, delete, get a current TOTP code or manage the Logins PIN, for Personal and Business accounts alike. Never pass secrets to this tool. The page asks the user to sign in first if needed and prepares secure login storage on their first save; the backend checks the signed-in account, its role’s permissions, the account’s login rules and the PIN where required. Saved logins remain available to that account across its authorized clients.
Effect: Reads only; changes nothing.
manage_sms_number
Give a saved login a Pomerado phone number for its website’s text-message (SMS) sign-in codes, so Pomerado’s autofill sign-in fills them without asking anyone. Not every account may assign one yet. show: the login’s number, whether it was verified, whether this account may assign one, and during a verification the code in the newest text the number received. assign: link a number (a reused one or a newly bought one; assigning again returns the same number). Then the user enters that number on the website as the account’s phone for verification codes. verify: start a 10-minute verification; send a test text or have the website send its code, then call show to read it. unlink: remove the number; ask the user to remove it from the website account first, since a released number can be given to someone else after 45 days. Kernel Managed Auth and direct sign-in never read these texts and still ask the user for the code.
Effect: May change a website or your account, and a change may not be undoable.
create_connection
Save a website login directly, with the same fields and account rules as POST /v1/connections. Warn the user before asking for credentials here. Values passed here are visible to your client and its model provider; the protected form keeps them out of this conversation. Pomerado keeps them from the minting model, traces and logs either way. For the protected-page option call manage_connection with action create. Returns login metadata only.
Effect: May change a website or your account, and a change may not be undoable.
update_connection
Replace a saved website login directly, with the same fields and account rules as PATCH /v1/connections/{id}. Warn the user before asking for credentials here. Values passed here are visible to your client and its model provider; the protected form keeps them out of this conversation. Pomerado keeps them from the minting model, traces and logs either way. A label it leaves out is kept; label null removes it. For the protected-page option call manage_connection with action update. Returns login metadata only.
Effect: May change a website or your account, and a change may not be undoable.
delete_connection
Revoke access to a saved connection and request permanent credential deletion. Related jobs and saved sessions are invalidated; provider cleanup may remain pending.
Effect: May change a website or your account, and a change may not be undoable.
sign_in
Sign this agent in to Pomerado without a browser on this machine. Without device_code it returns verification_url and user_code: give both to the person, who opens the link on any device, signs in (Google, GitHub or email; a new account is created) and approves. Then call sign_in with the returned device_code every interval seconds: it returns status pending until they approve, then once an API key (secret) for their account, valid 90 days. Configure it as this MCP’s Authorization: Bearer header; it works on every Pomerado MCP and the REST API. Never ask the person for a password.
Effect: May change a website or your account.
Pomerado API tools
These three tools reach every operation in the API reference, by itsoperationId, with the same input, answers and errors as REST. Search lists only the operations your account can use.