Browse docs
Product docs
Claude Automation With CONXA
How Conxa packages browser workflow automation as local MCP skills that Claude Desktop can invoke safely.
Summary
- Claude automation with Conxa starts from a reviewed human workflow, not from an AI model improvising browser clicks at runtime.
- Claude Desktop automation runs through the installed Conxa runtime, which registers as a local MCP server and executes prepared skills on the end user machine.
- MCP automation still depends on authorized access, reviewed workflows, local browser session state, and package boundaries that exclude target-site credentials.
How Claude automation works
Claude automation with Conxa starts when a builder records a browser workflow once in Build Studio. Conxa compiles that recording into a data-only skill package with step intent, selectors, validation expectations, and recovery metadata.
The installed runtime registers as an MCP server for Claude Desktop or another MCP-capable client. When Claude invokes a skill, the runtime executes the prepared browser workflow automation locally on the user machine.
Why MCP is the boundary
MCP automation gives Claude Desktop a defined tool surface instead of asking the model to rediscover every screen. The runtime can expose available skills, input schemas, execution status, cancellation, package refresh, and permitted skill metadata.
This keeps the AI client focused on selecting the right skill and providing inputs. The local Conxa runtime handles browser execution, deterministic recovery, assertions, and telemetry.
Local AI automation runtime
The runtime is the local AI automation runtime for Conxa skills. It syncs packaged workflow definitions, opens the local browser automation context, uses local session state where available, and reports compact operational telemetry.
Conxa Cloud coordinates packages, installers, billing, updates, compile-time LLM proxying, and telemetry. It does not operate the customer application for the end user.
Execution stays on the user machine
Claude Desktop can ask for a skill to run, but the browser session and target-application credentials remain local runtime state rather than cloud execution state.
Authorized workflow automation
- Build skills only for products, accounts, data, and workflows the user is authorized to operate.
- Review compiled workflows before distribution so end users understand what the skill will do.
- Do not package browser session files, passwords, cookies, credential stealers, or intentionally harmful automation.
- Use Conxa for repeatable operational workflows, not as a way to bypass target-application permissions or policy.
Who this is for
SaaS vendors can make common product workflows usable from Claude Desktop without building a custom native API integration for every workflow. Internal operations teams can package browser workflow automation for repeatable local execution by authorized users.
Related docs
Platform Overview
How Conxa turns recorded software workflows into local MCP skills that AI tools can execute reliably.
Runtime And MCP Execution
How the installed runtime exposes local browser workflow automation to Claude Desktop or another MCP client and executes skills locally.
Security
Security boundaries, local execution guarantees, auth handling, token storage, and practical operational limits.
Acceptable Use Policy
Rules for safe, lawful, and authorized use of CONXA workflow recording, packaging, installers, runtime, and cloud services.