Skip to main content
Use fentaris edge on the computer that owns the filesystem, credentials, or local process you want an MCP client to use.

Quick Start

Open the displayed verification URL and enter the user code. Join creates a random device keypair, proves possession, enrolls the device, and installs a per-user background service when the platform permits it. No global package installation is required for the npx form. For an application using the integrated local control plane, approve the displayed code from the application project:
Approval travels through an owner-only local operator socket. The CLI does not read or mutate the protected authority database. Enrollment, connection, desired-state reconciliation, and capability publication then happen without custom gateway wiring. If native service installation is unavailable, the device stays enrolled and the command returns fentaris edge run as the foreground fallback. Pass --no-service to choose foreground operation or --service to fail unless persistent installation succeeds. The local executable allowlist is deny-by-default. Set FENTARIS_EDGE_ALLOWED_EXECUTABLES for direct executables or FENTARIS_EDGE_ALLOWED_PACKAGES for packages launched through npx, pnpm, yarn, or bunx. Values are comma-separated exact names.
The hostname is a display label, not device identity. Copying non-secret config without the protected key cannot authenticate another installation as the device.

Define and Assign the Workload

The application defines the MCP. The edge CLI does not have an add command.
The local prompt shows the recipe digest and requested access. Approving a folder stores its canonical path locally and reports only an opaque grant ID.

Install an Assigned MCP Server

Declare installation separately from the launch recipe. Managed installation supports exact Node package versions with integrity, exact Python versions with hashes, immutable binary archives, container image digests, custom sources, and manual prerequisites.
Git recipes require an exact 40-character commit. Archives, packages, distributions, and containers require immutable digests or hashes. Private source credentials are resolved from the local encrypted credential store and are never placed in command arguments, desired state, inventory, or review output. Custom installers require local review of the exact source identity, entrypoint, arguments, permissions, outputs, verification, cleanup plan, and effective policy digest. Denial and revocation are sticky. Any effective-plan change creates a new approval identity. A custom cleanup with external side effects requires a separate --cleanup review and approval.
Fentaris rejects floating Git refs, credentials embedded in URLs, archive traversal, symlinks escaping staging, submodules, undeclared executables, elevation, and required isolation that the device cannot enforce.
Keep desktop applications as manual prerequisites:
Fentaris detects this prerequisite but does not download, elevate, install, update, or remove it.

Review and Recover Installations

For a custom external cleanup, review and approve the cleanup identity separately before removal:
Lifecycle states distinguish assignment, checking, approval, installation, verification, setup, startup, readiness, degradation, failure, removal, and rollback. Retried failures create a new attempt; they do not overwrite diagnostics. Updates install into a digest-addressed root and activate only after verification. Shared artifacts are deleted only after their final deployment reference is removed. Protocol v3 carries correlated installation and launch digests. Older agents can continue compatible transparent execution, but a deployment requiring managed installation remains blocked with agent-upgrade-required until an eligible agent connects.

Inspect and Disconnect

Status reports connection, desired deployments, readiness, and blocked counts. It does not print local paths, tokens, credentials, secrets, or full environments. disconnect closes the channel and stops workloads according to shutdown policy. Existing pinned sessions fail with EDGE_UNAVAILABLE; they do not move to another device.

Use Edge Control From an Agent

After the application explicitly enables and governs Edge Control, an MCP client can discover eligible devices without knowing physical IDs:
Call the effective tool normally after selection. Use edge__call only when the agent must name one device explicitly, and use edge__call_many for a bounded parallel operation. Fan-out accepts either devices or selector, never both.
The result contains one terminal entry per resolved device. fail-fast stops new work and cancels cancellable children; it does not roll back completed mutations.

Revoke the Device

Revocation removes the server-side device authorization, stops the local connection, and deletes local identity, grants, and setup secrets. Grant or workload denial is also sticky: replaying desired state cannot restart it until local consent is renewed.

Placement Examples

Personal filesystem

Group-scoped personal devices

Shared worker pool

Cloud fallback

Omit a placement binding to use implicit cloud, or bind it explicitly:
Selector fallback can choose another eligible selector before pinning. It does not fail over after a session is pinned.

Troubleshooting

Setup remains pending

Run fentaris edge status. Approve every required field and the current recipe digest. A schema access change invalidates only affected grants.

Device reconnects but calls fail

An existing session is pinned to its original connection generation. Start a new downstream MCP session after reconnection.

Command is denied

Add the exact executable or package to FENTARIS_EDGE_ALLOWED_EXECUTABLES or FENTARIS_EDGE_ALLOWED_PACKAGES, reconnect the agent, then renew consent for the recipe digest. Do not allow a shell interpreter as a generic workaround.