Hexis Files

The knowledge base's Groups/ root is now Plugins/, laid out per the Agent Plugins specification (v1.0.0): each plugin carries a plugin.json manifest, its skills under skills/, and its MCP servers in mcp.json — the three things a conformant client knows how to read. Platform-specific .tool manuals live in the spec's reserved software.bevel.hexis/ namespace, and access.md stays at the plugin root, where access resolution needs it.

Existing knowledge bases migrate themselves. The next load after upgrading renames the root, writes manifests, converts mcp-type .tool files into mcp.json entries, and commits the result. Manual ids are preserved as server names, so configured secrets and completed OAuth sign-ins stay bound. The migration is idempotent, finishes a half-done run, names anything it deliberately declines to convert, and never widens access: a .tool that gates itself, carries credentials in its URL, or wouldn't survive as an mcp.json entry stays a .tool.

Secrets never enter the portable files. mcp.json records only where a server is; auth headers with ${VAR} references, variable declarations, and the local-only flag live in the plugin manifest's extensions block, which Hexis interprets and other clients ignore — exactly the client-managed credential storage the specification defers to.

Editing MCP servers without editing JSON. Tool pages for mcp.json-backed servers grew a server-scoped form: transport, URL or command, headers split between portable and auth, variable declarations with scopes — validated at save with the same rules discovery applies, so nothing saveable is undiscoverable. Renaming a server warns that secrets and sign-ins bound to the old name disconnect.