Wisent Las

Las: one local catalogue for approved agent tools

Las is a local, policy-preserving federation layer for Wisent agent tools. It adopts operator-approved MCP registrations through a CLI or packaged graphical importer, verifies signed release contracts, and exposes children through one stdio MCP server.

  • One stdio MCP server
  • Signed release contracts
  • surface__tool namespacing
  • On-demand secure loopback GUI
  • Fails closed per surface

Your tool surfaces need one boundary

Las keeps the catalogue local and policy-preserving instead of turning aggregation into new child authority.

Registration stays static

Las launches children from a static repository-owned registry and gives tools deterministic surface__tool names.

Authority stays with the child

Las does not broaden child permissions, implement child behavior, install or repair products, or act as a raw secret broker.

One bad surface stays one surface

A missing, invalid, expired, rolled-back, or byte-and-schema-mismatched release fails closed for that surface while remaining surfaces can still federate.

Signed releases become one stdio surface

The federation path is registry, manifest verification, namespaced exposure, and stdio communication; catalogue adoption is also available through an on-demand loopback GUI.

  1. Start from the registry

    Las discovers an operator-approved set of sibling MCP servers from a static repository-owned registry.

  2. Bind the release

    Signed release manifests bind child command, working directory, arguments, environment names, binary and code digests, tool names, and input-schema digests.

  3. Verify before exposure

    Las verifies signed release contracts, and an invalid or mismatched release fails closed for that surface while remaining surfaces can still federate.

  4. Keep every channel narrow

    Federation communicates through stdio. The optional graphical importer binds loopback only, requires an exact host, origin, and random session token, never starts children, and never inherits the complete parent environment.

The interfaces are explicit

Inspection, graphical adoption, child initialization, and tool invocation remain separate operations.

$ las adopt /path/to/existing/mcp.json
$ las gui
$ las list
$ las check <surface>
$ las-mcp
Installed interfaces: atomic CLI/GUI adoption, readback commands, and the stdio MCP server.

The boundaries are part of the product

Does Las grant children more authority?

No. Las does not broaden child permissions or implement child behavior.

Does the graphical importer expose a network service?

Only when las gui is explicitly running, and only on 127.0.0.1 for that process lifetime. It requires the exact session host, origin, and random bearer token, caps requests before parsing, does not open a browser, and never starts or probes MCP children.

What happens when a release cannot be trusted?

A missing, invalid, expired, rolled-back, or byte-and-schema-mismatched release fails closed for that surface while remaining surfaces can still federate.

What does the current source require?

The current public development source requires Node.js 18 or newer, a coordinated local Wisent workspace, and operator-provisioned signed release files.

Federate the catalogue without widening authority

Use Las when you want one local, policy-preserving MCP federation layer for an operator-approved catalogue of Wisent agent tools. Read the quick start.