Skyvern

Use Skyvern’s MCP or API for browser operations and multi-step workflows. Choose cloud or self-hosted execution, supply the required credentials, and review the business result rather than only the run status.

Review a one-record workflow

Run one existing workflow or one direct browser task first. This reveals missing inputs without silently turning a test into workflow-authoring work.

Test URL and records, requested fields, cloud/local connection, and existing workflow ID or direct-browser-only mode.

Copy the request into a new Floatboat conversation and provide the required material.

Download Floatboat

Your request for Floatboat

Preview and copy the request. It is not sent automatically from this page.

Reference: Skyvern
https://github.com/Skyvern-AI/skyvern

Read the original documentation and check the current environment and dependencies. Propose any new installation or tool connection before proceeding.

My task:
Use the configured Skyvern backend to prepare one test record in the approved form. Verify all fields against the input, report errors, and stop before final submission. Keep session and workflow identifiers in the report.

Expected deliverable:
A one-record run with field comparison, errors, and a submission checkpoint. Include failed steps and unresolved questions when evidence is insufficient.

About Skyvern

Skyvern combines direct browser inspection with reusable browser workflows. A session preserves page state, a workflow defines steps, and a run records one execution. The CLI offers direct validation/extraction and workflow operations; cloud or self-hosted backends supply browser and model execution while the coding host invokes their tools.

The official MCP server documentation names Cursor and Codex, with cloud and local configuration paths. Cloud access uses a Skyvern account and authentication; self-hosted execution requires the backend and model/browser dependencies. Some setups require explicit browser-session creation before tool use.

Use the official skyvern Skill for the matching CLI/MCP release, keeping workflow-authoring and workflow-running scopes distinct. The repository is AGPL-3.0; hosted subscriptions, model use, and any enterprise terms are separate. Floatboat can use the external-agent path without implying that a workflow has already been verified.

How Skyvern Fits the Browser Workflow

Choose the object the job needs: inspect a page in a session, define reusable workflow steps, or inspect a particular run. That choice determines the tools, identifiers, and outputs to retain.

  • Session, workflow, and run

    Sessions hold browser state; workflows declare reusable steps; runs track particular executions with inputs, status, and output.

  • Inspection before automation

    Direct validation or extraction answers a page question; reusable multi-page jobs use workflows with navigation and extraction blocks.

  • Backend-executed browser work

    Cloud or self-hosted services execute browser/model work. The coding host calls those tools rather than providing the complete backend.

Skyvern Use Cases

These workflows emphasize repeatable business results rather than only page navigation. Use sample records and observable checkpoints before increasing run frequency, batch size, or the permissions available to the agent.

Enter a repeatable portal record

Provide approved test records and the destination form. Build a workflow that fills one record and pauses before final submission, then compare the field values with the input. Validate the exception path before increasing the batch size.

Inspect a recurring invoice workflow

Supply an existing workflow ID, test parameters, and expected invoice fields. Retain the run ID, inspect its status, and compare invoice number and total with the destination record. Diagnose the failing step before rerunning the same input rather than treating completed status as correct accounting data.

Collect a structured portal result

Use an approved account to navigate to a specified report and return named fields with their source context. Keep login, date selection, and extraction as visible steps so a stale page cannot silently become the report for the wrong period.

Compare local and cloud operation

Run a small non-sensitive workflow on the selected backend and record setup, output, and required services. Choose deployment based on data access and operational needs, rather than assuming self-hosting removes model costs or that cloud execution inherits a local browser login.

Before Using Skyvern

Choose hosted or self-hosted execution, then prepare the account, runtime, and workflow permissions for that path.

  • Selected backend

    Prepare cloud authentication or the documented self-hosted stack and model/browser configuration.

  • Workflow inputs

    Use test records and identify session creation and submission checkpoints before a production run.

Inspect One Existing Test-Invoice Workflow Run

Use an existing workflow intended for staging invoice data. Supply its workflow ID, declared parameter values, expected invoice number and total, and a permitted test destination. This task runs and checks that definition; it does not create a workflow or operate an unrelated direct browser session.

  1. Resolve the definition and test inputs

    Inspect the existing workflow and its parameter requirements through the configured interface. Confirm that the destination and records are test data and that the defined actions are authorized. If a parameter or expected output is unknown, resolve it before starting; do not substitute a browser session ID for the workflow ID.

  2. Start one run and retain its identifier

    Start the selected workflow with the supplied parameter values using the configured CLI or MCP interface. Save the returned run ID alongside the workflow ID and the non-sensitive input summary. Use this run ID for later status checks instead of starting another run whenever the result is not yet ready.

  3. Read status and reconcile invoice fields

    Query that run until it reaches the documented completed or failed state. On completion, inspect its output and compare invoice number and total with the expected test record and destination. Report absent fields or mismatches even if status indicates completion; retain the run ID with the result.

  4. Diagnose a failed step before a controlled rerun

    For a failed run, inspect the reported step, error, and available output before changing inputs. Resolve the identified test-data, login, or workflow issue, then rerun only after checking whether the first attempt changed the destination. Record the new run ID separately and compare the same invoice fields; unresolved failures remain explicit in the handoff.

Related Software Projects

Compare the workflows, operating requirements, and source licenses of these projects.

Skyvern FAQ

Does Skyvern provide a Cursor/Codex interface?
Yes. The official MCP server documentation names both and describes local and cloud configuration. Configure the backend and session requirements in addition to the client entry.
Which identifier is needed to resume a failed job?
Keep workflow ID for the definition, run ID for execution/status, and session ID for stateful direct browsing. Resume or rerun the appropriate object; a new browser session does not recover the old page state or a failed workflow run.
Can the backend be self-hosted?
The project provides a self-hosted path. It requires its own runtime, browser, model, and authentication setup; a local MCP wrapper alone does not supply a complete backend.
What does the official Skill add?
It guides the coding agent through the current Skyvern CLI and MCP workflow. It does not replace the server, account, or output verification, and it should match the installed release.
When should a workflow stop for review?
Mark consequential submissions, account changes, and purchases as explicit checkpoints. Test the workflow using draft or staging data before allowing those actions on production records.
How are licensing and service fees different?
The source is AGPL-3.0, while hosted access and model usage have separate terms and charges. Review deployment and redistribution requirements rather than interpreting the repository license as free hosted service.