MCP & Plugin

Evigauge MCP Server & Claude Code Plugin

On this page

Naming: Evigauge vs opexia
What is in here

Reference for the developer tooling that runs on your machine: the pxcore MCP server (token compression via imaged context) and the Evigauge Claude Code plugin (/opexia:* skills).

Companion documents: REST API Reference · SDK Reference

Naming: Evigauge vs `opexia`

The product is Evigauge (formerly OpexIA). The rename is a brand change only.

Every identifier in commands, configs, and code stays opexia / pxcore:

Surface	Value — do not rename
Plugin name	`opexia`
Slash commands	`/opexia:instrument`, `/opexia:secure`, `/opexia:log`, `/opexia:compress`
MCP server name	`pxcore`
MCP tools	`pxcore_read`, `pxcore_run`, `pxcore_grep`, `pxcore_view`
Console scripts	`pxcore-mcp`, `pxcore-proxy`, `opexia`
Python import	`import pxcore`
Env var	`PXCORE_MODEL`
PyPI package	`opexia-trace` (ships `pxcore` too)

What is in here

Component	Runs	Network	Purpose
`pxcore` MCP server	Locally, stdio or HTTP	None	Token compression — dense reference output becomes images the model reads with native vision
`pxcore-proxy`	Locally, in-path	To your LLM provider	Same compression, applied transparently to Claude Code
`/opexia:instrument`	In Claude Code	Yes — verifies a span lands	Detects your stack and instruments it correctly
`/opexia:secure`	In Claude Code	Zero egress	Prompt-injection audit + mitigations under review
`/opexia:log`	In Claude Code	Zero egress	Committed, agent-queryable relational dev-log
`/opexia:compress`	In Claude Code	None	Set up, calibrate, and verify pxcore

Privacy. /opexia:secure and /opexia:log are strictly local and make no network call — security findings are a disclosure, so they must not travel, and the dev-log is your codebase's history. pxcore compression contains no LLM in its path. Only /opexia:instrument talks to Evigauge, and only to confirm your test span arrived.