edict-lang
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| EDICT_TRANSPORT | No | The transport protocol to use for the MCP server. Set to 'http' for HTTP transport; defaults to stdio. | stdio |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| prompts | {
"listChanged": true
} |
| resources | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| edict_schemaA | Return the JSON Schema defining valid Edict AST programs. Use format 'agent' for one-call bootstrapping (minimal schema + compact maps + builtins + effects). |
| edict_versionD | – |
| edict_examplesD | – |
| edict_validateA | Validate an Edict AST against the compiler's JSON schema without typing or compiling. Use this as a first pass. |
| edict_checkA | Run the full semantic checker (name resolution, type checking, effect checking, contract verification) on an AST. Supports single module (ast) or multi-module (modules array) input. |
| edict_compileA | Compile a semantically valid Edict AST into a WebAssembly module. Returns the WASM binary encoded as a base64 string. Supports single module (ast) or multi-module (modules array) input. |
| edict_runA | Execute a compiled WebAssembly module (provided as base64) in a sandboxed runtime. The WASM VM has no ambient authority — filesystem, network, and crypto access are provided exclusively through host adapters. Returns standard output, exit code, and any sandbox limit errors. Supports optional execution limits (timeout, memory, sandbox directory) and external WASM modules for import interop. Set record: true to capture all non-deterministic host responses in a replay token for deterministic reproduction. |
| edict_patchA | Apply surgical patches to an Edict AST by nodeId, then run the full check pipeline. Use this to fix errors without resubmitting the entire AST. Each patch specifies a nodeId, an operation (replace/delete/insert), and the relevant field/value. |
| edict_errorsD | – |
| edict_lintA | Run non-blocking lint analysis on an Edict AST. Returns quality warnings (unused variables, missing contracts, oversized functions, redundant effects, etc.) without blocking compilation. Warnings use the same structured format as errors but with severity: 'warning'. |
| edict_composeA | Compose multiple Edict program fragments into a single module. Fragments declare what they provide and require, enabling independent validation and incremental program generation. |
| edict_debugA | Execute an Edict program with debug instrumentation. Compiles the AST with call-stack tracing, runs it, and returns structured crash diagnostics including call stack at crash time, crash location with nodeId, and step count. Use this instead of edict_compile + edict_run when debugging runtime failures — the crash location and call stack enable targeted fixes without guessing. |
| edict_exportB | Export an Edict AST as a portable WASM skill package with validation and manifest generation. |
| edict_import_skillC | Import and execute a compiled Edict WASM skill package, validating its checksum. |
| edict_packageA | Package a compiled Edict module + WASM binary into a portable SkillPackage. Input: the module AST (same one sent to edict_compile) + the base64 WASM string returned by edict_compile. Output: a SkillPackage JSON with interface metadata, verification info, integrity checksum, and the embedded WASM. |
| edict_invoke_skillB | Execute a packaged Edict skill — load WASM from a SkillPackage, verify integrity checksum, and run it. Returns structured output with exit code and return value. |
| edict_generate_testsA | Auto-generate structured test cases from Z3-verified contracts. For proven contracts, extracts boundary input values and expected outputs from Z3 models. For failing contracts, extracts counterexample inputs as regression tests. Returns an array of GeneratedTest objects — each with function name, input values, expected output, and source (boundary/counterexample). Use this to get free tests from formal specifications without writing them manually. |
| edict_explainA | Given a structured error, returns enriched repair context: pipeline stage, field metadata, example ASTs, and repair strategy. |
| edict_replayA | Re-execute a WASM module using a previously recorded replay token for deterministic reproduction of runtime behavior. All non-deterministic host responses (random values, timestamps, HTTP responses, file IO) are replayed from the token instead of calling real host functions. Use this to reproduce exact failures or verify fixes against known execution traces. |
| edict_supportB | Returns structured sponsorship and support information for the Edict project |
| edict_deployA | Deploy an Edict program to a target. Runs the full pipeline (validate → check → compile) then packages for the specified target. Targets: 'wasm_binary' (returns WASM + metadata), 'cloudflare' (generates Worker bundle). |
| edict_invokeB | Invoke a deployed Edict WASM service via HTTP. Sends a request to the given URL with optional input and returns the structured result. Completes the deploy → invoke round-trip. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| write_program | System prompt for writing a new Edict program from a task description. Includes minimal schema, example, and builtin list. |
| fix_error | Prompt for fixing a structured Edict compiler error. Includes error taxonomy and fix strategy. |
| add_contracts | Prompt for adding pre/postcondition contracts to existing Edict functions for Z3 formal verification. |
| review_ast | Prompt for reviewing an Edict AST for quality issues (unused variables, missing effects, dead code, etc.). |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| schema | The full JSON Schema defining valid Edict AST programs |
| schema-minimal | Token-optimized JSON Schema (descriptions stripped) for minimal context window usage |
| examples | 10 example Edict programs as JSON ASTs |
| errors | Machine-readable catalog of all structured error types with fields, pipeline stages, and example cause/fix ASTs |
| schema-patch | JSON Schema defining the AST diff/patch protocol for the edict_patch tool (replace, insert, delete operations) |
| support | Sponsorship and support information for the Edict project |
| guide | Agent bootstrap guide — workflow, template, error recovery, builtins, tool reference |
TDQS
Scored across 22 tools
Most tools have distinct purposes clearly described, such as edict_compile for compilation and edict_run for execution. However, some overlap exists between edict_deploy (which includes validation, checking, and compilation) and other tools like edict_validate and edict_compile, which could cause confusion about when to use each. The descriptions generally help clarify boundaries, but the pipeline overlap is noticeable.
All tool names follow a consistent verb_noun pattern with the prefix 'edict_' and snake_case throughout, such as edict_check, edict_compile, and edict_deploy. There are no deviations in naming conventions, making the set predictable and easy to parse for agents.
With 22 tools, the count feels heavy for a language server, bordering on excessive. While the domain (Edict language processing) is complex, many tools like edict_errors, edict_examples, and edict_version lack descriptions, suggesting they might be trivial or redundant. A more streamlined set of 10-15 core tools would likely suffice without losing functionality.
The tool surface covers a comprehensive lifecycle from validation (edict_validate) to deployment (edict_deploy) and debugging (edict_debug), with good support for testing (edict_generate_tests) and packaging (edict_package). Minor gaps exist, such as no explicit tool for editing or refactoring code beyond edict_patch, but agents can work around this using existing tools for most workflows in the Edict domain.