# Sowiedu/Edict [Health: Active]

**Category:** 👨‍💻 Code Execution  
**Repository:** https://github.com/Sowiedu/Edict  
**GitHub Stars:** 13  
**npm Downloads (last month):** 897  
**Views:** 4  
**Installs:** 0  
**Upvotes:** 0  
**Directory Page:** https://allmcps.com/mcp/sowiedu-edict

## Description
Agent-first programming language: agents produce JSON AST, the compiler validates, type-checks, effect-checks, verifies contracts via Z3/SMT, and compiles to WASM. 19 MCP tools for the full compile-and-execute loop.

## Tools
Capabilities this server exposes over MCP:

- **edict_schema** — Returns the full AST JSON Schema — the spec for how to write programs
- **edict_version** — Returns compiler version and capability info
- **edict_examples** — Returns 41 example programs as JSON ASTs (includes schema snippet)
- **edict_validate** — Validates AST structure (field names, types, node kinds)
- **edict_check** — Full pipeline: validate → resolve names → type check → effect check → verify contracts
- **edict_compile** — Compiles a checked AST to WASM (returns base64-encoded binary)
- **edict_run** — Executes a compiled WASM binary, returns output and exit code
- **edict_patch** — Applies targeted AST patches by nodeId and re-checks
- **edict_errors** — Returns machine-readable catalog of all error types
- **edict_lint** — Runs non-blocking quality analysis and returns warnings
- **edict_debug** — Execution tracing and crash diagnostics
- **edict_compose** — Combines composable program fragments into a module
- **edict_explain** — Explains AST nodes, errors, or compiler behavior
- **edict_export** — Packages a program as a UASF portable skill
- **edict_import_skill** — Imports and executes a UASF skill package
- **edict_generate_tests** — Generates tests from Z3-verified contracts
- **edict_replay** — Records and replays deterministic execution traces
- **edict_deploy** — Compiles and deploys an Edict program to edge runtimes (Cloudflare Workers)
- **edict_invoke** — Invokes a deployed Edict WASM service via HTTP
- **edict_invoke_skill** — Invokes a UASF skill package directly
- **edict_package** — Packages a compiled program as a deployable skill bundle
- **edict_support** — Returns diagnostics and environment info for troubleshooting

## Claude Desktop Quick Installation
Install path detected from listing signals. Uses `npx` (confidence: high):

```json
"mcpServers": {
  "edict": {
    "command": "npx",
    "args": ["-y","edict-lang"]
  }
}
```

## Documentation

## What Sowiedu/Edict does

Sowiedu/Edict exposes the Edict compiler and runtime through Model Context Protocol tools. Edict programs are represented as JSON AST objects, so an agent does not need to generate or parse a traditional programming-language syntax. The server can validate AST structure, resolve names, perform static type checking, inspect declared effects, and verify contracts with Z3/SMT.

After checking succeeds, the Sowiedu/Edict tool set can compile the AST to WebAssembly. The resulting binary can be executed through the server, with output and an exit code returned to the caller. Additional tools support linting, diagnostics, deterministic trace replay, AST patching, fragment composition, test generation from verified contracts, and explanations of nodes, errors, or compiler behavior.

The project also supports packaging programs as UASF skills or deployable skill bundles. Its deployment and invocation tools cover Edict WASM services on edge runtimes, including Cloudflare Workers, and direct invocation of UASF skill packages.

## How it works

A typical agent workflow starts with `edict_schema` to obtain the AST specification, or `edict_examples` to inspect sample programs. The agent submits an AST to `edict_validate` for structural checks, then uses `edict_check` for the complete compilation-preparation pipeline. Errors are returned as structured data; `edict_errors` exposes the machine-readable error catalog.

Successful checks can be passed to `edict_compile`, which returns a base64-encoded WebAssembly binary. `edict_run` executes compiled WebAssembly and reports its output and exit status. The language uses declared effects such as pure operations, reads, writes, I/O, and failure handling. Contract verification can return counterexamples when a condition cannot be proven.

Execution is designed around WebAssembly isolation. Programs do not receive filesystem, network, or operating-system access unless the host supplies those capabilities through an `EdictHostAdapter`. Runtime limits can control execution time, memory, and filesystem sandboxing. Available adapter areas include sandboxed filesystem access, HTTP, cryptographic operations, environment variables, and CLI arguments.

## Setup and configuration

Run the MCP server with Node.js 20 or newer:

```bash
npx edict-lang
```

The default transport is stdio, which suits local MCP clients. A local installation can be started with `npm install edict-lang` followed by `npx edict-lang`. Docker images are available for Linux amd64 and arm64. The container uses stdio by default; setting `EDICT_TRANSPORT=http` starts HTTP transport on port 3000 when the port is published.

The repository development workflow uses `npm install`, `npm test`, and `npm run mcp`. Edict can also run in a browser or in QuickJS, but those are embedding options rather than requirements for the MCP server.

## Tools and capabilities

Sowiedu/Edict includes tools for:

- Reading schemas, examples, version information, errors, support diagnostics, and explanations.
- Validating, checking, linting, patching, and composing JSON AST programs.
- Compiling checked ASTs to WebAssembly and running the resulting binaries.
- Debugging executions, generating contract-based tests, and replaying deterministic traces.
- Exporting, importing, invoking, and packaging UASF skills.
- Deploying Edict programs to supported edge runtimes and invoking deployed services.

The server also exposes MCP resources for the full and minimal AST schemas, examples, errors, patch schema, onboarding guide, and support information.

## Limitations and notes

Sowiedu/Edict requires callers to produce valid JSON AST data; it is not a text parser for a conventional source language. Contract verification depends on what the verifier can prove, and failed proofs may stop the checked pipeline. WebAssembly execution is sandboxed by default, so external capabilities must be explicitly provided by the host adapter.

The browser bundles have different scope: the lightweight bundle covers checking-related phases, while the full bundle adds WASM generation, contract verification, and execution. Browser ESM usage requires HTTP serving rather than opening modules through `file://`.

_Full upstream README: https://allmcps.com/mcp/sowiedu-edict/readme_