The edict-lang server provides a full lifecycle MCP interface for AI agents to write, validate, compile, and execute programs in Edict—a statically-typed, effect-tracked language where programs are JSON ASTs (no text parsing). Structured error feedback enables self-repair loops.
Schema & Discovery
edict_schema: Retrieve the JSON Schema for valid Edict ASTs (full, minimal, compact, or agent-optimized formats)
edict_version: Get compiler version and capability information
edict_examples: Access 41 example programs as JSON ASTs
edict_errors: Get a machine-readable catalog of all error types
edict_explain: Get enriched repair context (pipeline stage, field metadata, example ASTs) for a structured error
Validation & Checking
edict_validate: Validate AST structure (field names, types, node kinds) without full compilation
edict_check: Run the full semantic pipeline — name resolution, type checking, effect checking, and Z3/SMT contract verification
edict_lint: Non-blocking quality analysis returning warnings (unused variables, missing contracts, etc.)
AST Editing & Composition
edict_patch: Apply surgical patches to an AST by node ID (replace/delete/insert) and re-run the full check pipeline
edict_compose: Combine multiple program fragments into a single module
Compilation & Execution
edict_compile: Compile a valid AST to a base64-encoded WebAssembly binary
edict_run: Execute a compiled WASM module in a sandboxed runtime with configurable timeout and memory limits (supports record: true for deterministic replay)
edict_debug: Execute with debug instrumentation, returning call stack, crash location, and step count
edict_replay: Re-execute a WASM module deterministically using a previously recorded replay token
Skill Packaging & Invocation
edict_export: Export an AST as a portable WASM skill package (UASF format) with manifest generation
edict_package: Package a compiled module and WASM binary into a portable SkillPackage JSON with integrity checksum
edict_import_skill: Import and execute a compiled skill package with checksum validation
edict_invoke_skill: Execute a packaged SkillPackage directly
Deployment
edict_deploy: Deploy a program to a target (raw WASM binary or Cloudflare Workers bundle)
edict_invoke: Invoke a deployed Edict WASM service via HTTP
Testing & Support
edict_generate_tests: Auto-generate test cases from Z3-verified contracts (boundary values and counterexamples)
edict_support: Retrieve diagnostics, environment info, and sponsorship information
Compiles verified agent-generated programs into WebAssembly (WASM) binaries and provides a sandboxed execution environment with controlled host capabilities like filesystem and network access.
A programming language designed for AI agents. No parser. No syntax. Agents produce AST directly as JSON.
Edict is a statically-typed, effect-tracked programming language where the canonical program format is a JSON AST. It's purpose-built so AI agents can write, verify, and execute programs through a structured pipeline — no text parsing, no human-readable syntax, no ambiguity.
Agent (LLM)
│ produces JSON AST via MCP tool call
↓
Schema Validator ─── invalid? → StructuredError → Agent retries
↓
Name Resolver ────── undefined? → StructuredError + candidates → Agent retries
↓
Type Checker ─────── mismatch? → StructuredError + expected type → Agent retries
↓
Effect Checker ───── violation? → StructuredError + propagation chain → Agent retries
↓
Contract Verifier ── unproven? → StructuredError + counterexample → Agent retries
(Z3/SMT) ↓
Code Generator (pure-JS WASM encoder) → WASM → ExecuteJSON AST — Programs are JSON objects, not text files. No lexer, no parser.
Structured errors — Every error is a typed JSON object with enough context for an agent to self-repair.
Type system — Int, Float, String, Bool, Array<T>, Option<T>, Result<T,E>, records, enums, refinement types.
Effect tracking — Functions declare pure, reads, writes, io, fails. The compiler verifies consistency.
Contract verification — Pre/post conditions verified at compile time by Z3 (via SMT). Failing contracts return concrete counterexamples.
WASM compilation — Verified programs compile to WebAssembly via a pure-JS encoder and run in Node.js.
MCP interface — All tools exposed via Model Context Protocol for direct agent integration.
Schema migration — ASTs from older schema versions are auto-migrated. No breakage when the language evolves.
Related MCP server: Chiasmus
Edict compiles to WebAssembly and runs in a sandboxed VM. This is a deliberate security decision — not a limitation:
No ambient authority — compiled WASM cannot access the filesystem, network, or OS unless the host explicitly provides those capabilities via the pluggable EdictHostAdapter interface
Compile-time capability declaration — the effect system (io, reads, writes, fails) lets the host inspect what a program requires before running it
Runtime enforcement — RunLimits controls execution timeout, memory ceiling, and filesystem sandboxing
Defense-in-depth — agent-generated code that runs immediately needs stronger isolation than human-reviewed code. The effect system + WASM sandbox + host adapter pattern provides exactly that
Host capabilities available through adapters: filesystem (sandboxed), HTTP, crypto (SHA-256, MD5, HMAC), environment variables, CLI arguments. New capabilities are added by extending EdictHostAdapter.
The fastest way to use Edict is through the MCP server — it exposes the entire compiler pipeline as tool calls:
npx edict-lang # start MCP server (stdio transport, no install needed)Or install locally:
npm install edict-lang
npx edict-lang # start MCP serverTwo calls to get started: edict_schema (learn the AST format) → edict_check (submit a program). See MCP Tools for the full tool list.
npm install
npm test # 2675 tests across 136 files
npm run mcp # start MCP server (stdio transport)Run the Edict MCP server in a container — no local Node.js required:
# stdio transport (default — for local MCP clients)
docker run -i ghcr.io/sowiedu/edict
# HTTP transport (for remote/networked MCP clients)
docker run -p 3000:3000 -e EDICT_TRANSPORT=http ghcr.io/sowiedu/edictSupported platforms: linux/amd64, linux/arm64.
Run the Edict compiler entirely in the browser — no server required:
Bundle | Size | Phases | Use case |
| 318 KB | 1–3 (validate, resolve, typecheck, effects, lint, patch) | Lightweight checking |
| ~14 MB | 1–5 (+ WASM codegen, Z3 contracts, WASM execution) | Full compile & run |
import { compileBrowser, runBrowserDirect } from 'edict-lang/browser-full';
const result = compileBrowser(astJson);
if (result.ok) {
const run = await runBrowserDirect(result.wasm);
console.log(run.output); // "Hello, World!"
}Note: ESM modules require HTTP serving. Use
npx serve .or any static server —file://won't work.
See examples/browser/index.html for a working example.
The Edict compiler also runs inside QuickJS WASM — useful for sandboxed runtimes, edge workers, or embedding in other WASM applications:
Bundle | Size | Phases | Slowdown vs Node.js |
| 373 KB | 1–3 (validate, resolve, typecheck, effects) | ~3.7x |
| 932 KB | 1–5 (check + WASM compile) | ~3.7x |
import { EdictQuickJS } from "edict-lang/quickjs";
const edict = await EdictQuickJS.createFull(); // phases 1-5
const result = edict.compile(ast);
if (result.ok) {
console.log(result.wasm); // Uint8Array of valid WASM
}
edict.dispose();Note:
quickjs-emscriptenis an optional peer dependency — install it alongsideedict-langto useEdictQuickJS. For fs-free environments, passbundleSourcedirectly instead of loading from disk.
See docs/quickjs-feasibility-report.md for full benchmarks and recommendations.
Tool | Description |
| Returns the full AST JSON Schema — the spec for how to write programs |
| Returns compiler version and capability info |
| Returns 41 example programs as JSON ASTs (includes schema snippet) |
| Validates AST structure (field names, types, node kinds) |
| Full pipeline: validate → resolve names → type check → effect check → verify contracts |
| Compiles a checked AST to WASM (returns base64-encoded binary) |
| Executes a compiled WASM binary, returns output and exit code |
| Applies targeted AST patches by nodeId and re-checks |
| Returns machine-readable catalog of all error types |
| Runs non-blocking quality analysis and returns warnings |
| Execution tracing and crash diagnostics |
| Combines composable program fragments into a module |
| Explains AST nodes, errors, or compiler behavior |
| Packages a program as a UASF portable skill |
| Imports and executes a UASF skill package |
| Generates tests from Z3-verified contracts |
| Records and replays deterministic execution traces |
| Compiles and deploys an Edict program to edge runtimes (Cloudflare Workers) |
| Invokes a deployed Edict WASM service via HTTP |
| Invokes a UASF skill package directly |
| Packages a compiled program as a deployable skill bundle |
| Returns diagnostics and environment info for troubleshooting |
URI | Description |
| The full AST JSON Schema |
| Minimal schema variant for token-efficient bootstrap |
| All example programs |
| Machine-readable error catalog |
| JSON Schema for the AST patch protocol |
| Agent bootstrap guide for MCP-first onboarding |
| Diagnostics and environment info |
A "Hello, World!" in Edict's JSON AST:
{
"kind": "module",
"id": "mod-hello-001",
"name": "hello",
"imports": [],
"definitions": [
{
"kind": "fn",
"id": "fn-main-001",
"name": "main",
"params": [],
"effects": ["io"],
"returnType": { "kind": "basic", "name": "Int" },
"contracts": [],
"body": [
{
"kind": "call",
"id": "call-print-001",
"fn": { "kind": "ident", "id": "ident-print-001", "name": "print" },
"args": [
{ "kind": "literal", "id": "lit-msg-001", "value": "Hello, World!" }
]
},
{ "kind": "literal", "id": "lit-ret-001", "value": 0 }
]
}
]
}The core design: an agent submits an AST → the compiler validates it → if wrong, returns a StructuredError with enough context for the agent to self-repair → the agent fixes it → resubmits.
// 1. Agent reads the schema to learn the AST format
const schema = edict_schema();
// 2. Agent writes a program (may contain errors)
const program = agentWritesProgram(schema);
// 3. Compile — returns structured errors or WASM
const result = edict_compile(program);
if (!result.ok) {
// 4. Agent reads errors and fixes the program
// Errors include: nodeId, expected type, candidates, counterexamples
const fixed = agentFixesProgram(program, result.errors);
// 5. Resubmit
return edict_compile(fixed);
}
// 6. Run the WASM
const output = edict_run(result.wasm);src/
├── ast/ # TypeScript interfaces for every AST node
├── validator/ # Schema validation (structural correctness)
├── resolver/ # Name resolution (scope-aware, with Levenshtein suggestions)
├── checker/ # Type checking (bidirectional, with unit types)
├── effects/ # Effect checking (call-graph propagation)
├── contracts/ # Contract verification (Z3/SMT integration)
├── codegen/ # WASM code generation (pure-JS encoder)
│ ├── codegen.ts # IR → WASM module orchestration
│ ├── compile-ir-expr.ts # IR expression compilation
│ ├── compile-ir-*.ts # Specialized IR compilers (calls, data, match, scalars)
│ ├── runner.ts # WASM execution (Node.js WebAssembly API)
│ ├── host-adapter.ts # EdictHostAdapter interface + platform adapters
│ ├── closures.ts # Closure capture and compilation
│ ├── hof-generators.ts # Higher-order function WASM generators
│ ├── wasm-encoder.ts # Pure-JS WASM binary encoder (replaced binaryen)
│ ├── wasm-interpreter.ts # Pure-JS WASM interpreter (no WebAssembly API needed)
│ ├── recording-adapter.ts # Execution recording for replay
│ ├── replay-adapter.ts # Deterministic replay from recorded traces
│ └── string-table.ts # String interning for WASM memory
├── ir/ # Mid-level IR (lowering, optimization)
├── builtins/ # Builtin registry and domain-specific builtins
├── compact/ # Compact AST format (token-efficient for agents)
├── compose/ # Composable program fragments
├── deploy/ # Edge deployment scaffolding (Cloudflare Workers)
├── incremental/ # Incremental checking (dependency graph + diff)
├── lint/ # Non-blocking quality warnings
├── patch/ # Surgical AST patching by nodeId
├── migration/ # Schema version migration (auto-upgrade older ASTs)
├── skills/ # Skill packaging and invocation
├── mcp/ # MCP server (tools + resources + prompts)
└── errors/ # Structured error types
tests/ # 2675 tests across 136 files
examples/ # 41 example programs (⭐→⭐⭐⭐ difficulty in README)
schema/ # Auto-generated JSON SchemaType | Example |
Basic |
|
Array |
|
Option |
|
Result |
|
Record |
|
Enum |
|
Refinement |
|
Function |
|
Functions declare their effects. The compiler enforces:
A pure function cannot call an io function
Effects propagate through the call graph
Missing effects are detected and reported
Effects: pure, reads, writes, io, fails
Pre/post conditions are verified at compile time using Z3:
{
"kind": "post",
"id": "post-001",
"condition": {
"kind": "binop", "id": "binop-001", "op": ">",
"left": { "kind": "ident", "id": "ident-result-001", "name": "result" },
"right": { "kind": "ident", "id": "ident-x-001", "name": "x" }
}
}Z3 either proves unsat (contract holds ✅) or returns sat with a concrete counterexample the agent can reason about.
We welcome contributions from agents and humans alike. See CONTRIBUTING.md for setup instructions, coding standards, and the PR workflow.
Looking for a place to start? Check issues labeled good first issue.
See ROADMAP.md for the full development plan, FEATURE_SPEC.md for the language specification, and Crystallized Intelligence for how agents store and reuse verified WASM skills.
Edict is free and open source under the MIT license. If your agents find it valuable, consider sponsoring its development.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| ast | No | The Edict JSON AST to check (single module) | |
| modules | No | Array of Edict module ASTs to check together (multi-module). Cross-module imports are resolved automatically. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It describes the checking operations performed (name resolution, type checking, etc.) and input handling (single vs. multi-module), but does not cover other behavioral aspects like error handling, performance implications, or output format. It adds some value but lacks comprehensive behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, with two concise sentences that efficiently convey the tool's purpose and input options without any wasted words. Every sentence earns its place by providing essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of semantic checking and the lack of annotations and output schema, the description is adequate but has gaps. It covers the tool's purpose and input handling, but does not explain return values, error conditions, or how results are presented. For a tool with no output schema, more detail on expected outputs would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters ('ast' and 'modules'). The description adds marginal value by clarifying the input scope (single vs. multi-module) and noting automatic cross-module import resolution, but does not provide additional syntax or format details beyond what the schema offers. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('run the full semantic checker') and resources ('on an AST'), and distinguishes it from siblings by specifying the exact checking operations performed (name resolution, type checking, effect checking, contract verification). It also clarifies the input scope (single vs. multi-module).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool by specifying the input types (single module AST or multi-module array) and noting that cross-module imports are resolved automatically. However, it does not explicitly state when to use alternatives like 'edict_validate' or 'edict_lint', which are sibling tools that might overlap in functionality.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| ast | No | The Edict JSON AST to compile (single module) | |
| modules | No | Array of Edict module ASTs to compile together (multi-module). Cross-module imports are resolved automatically. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses the output format (base64 string) and cross-module import resolution, which are useful behavioral traits. However, it lacks details on error handling, performance characteristics, or any side effects (e.g., whether compilation caches results).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste: the first states purpose and output, the second clarifies input variants. Every word earns its place, and key information (base64 output, multi-module support) is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description does well by specifying the return format (base64 string) and input semantics. However, for a compilation tool with potential complexity (multi-module resolution), it could benefit from mentioning error conditions or validation prerequisites.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds value by explaining the semantic difference between 'ast' (single module) and 'modules' (multi-module array), and clarifies that cross-module imports are resolved automatically. This goes beyond the schema's parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('compile'), the resource ('Edict AST'), and the output ('WebAssembly module'). It distinguishes from siblings by specifying compilation vs validation (edict_check), deployment (edict_deploy), or execution (edict_run). The mention of base64 encoding further clarifies the output format.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you have an Edict AST ready for compilation, but provides no explicit guidance on when to choose this over alternatives like edict_check (validation) or edict_deploy (deployment). It mentions multi-module support but doesn't contrast with single-module scenarios or explain prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compose multiple Edict program fragments into a single module. Fragments declare what they provide and require, enabling independent validation and incremental program generation.
| Name | Required | Description | Default |
|---|---|---|---|
| fragments | Yes | Array of Edict fragment ASTs to compose | |
| moduleName | No | Name for the composed module (default: 'composed') | |
| moduleId | No | ID for the composed module (default: 'mod-composed-001') | |
| check | No | If true, run the full type/effect/contract pipeline on the composed module |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only partially discloses behavior. It mentions validation and generation capabilities but doesn't cover important aspects like whether this is a read-only or destructive operation, authentication requirements, error handling, rate limits, or what happens when composition fails. The description adds some context about fragment dependencies but misses critical behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise with two sentences that each earn their place. The first sentence states the core functionality, while the second explains the mechanism and benefits. There's no wasted language or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters, no annotations, and no output schema, the description is incomplete. While it explains the high-level purpose well, it doesn't provide enough information about the tool's behavior, error conditions, or what the composed module looks like. The description assumes knowledge of Edict fragments and ASTs without explaining them.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the baseline is 3. The description doesn't add any parameter-specific information beyond what's already in the schema descriptions. It mentions 'fragments' generally but doesn't elaborate on AST format or composition rules, and doesn't provide additional context for moduleName, moduleId, or check parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('compose multiple Edict program fragments into a single module') and distinguishes it from siblings by focusing on fragment composition rather than checking, compiling, debugging, or other operations. It explains the mechanism ('fragments declare what they provide and require') and benefits ('enabling independent validation and incremental program generation').
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you have multiple fragments to combine into a module, but it doesn't explicitly state when to use this tool versus alternatives like edict_compile or edict_package. It mentions validation and generation benefits, but lacks clear exclusions or prerequisites for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| ast | Yes | The Edict program AST (module) to debug — same format as edict_compile | |
| options | No | Optional debug execution options |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well by disclosing key behavioral traits: it describes what the tool does (compiles with call-stack tracing, runs with instrumentation), what it returns (structured crash diagnostics including call stack, crash location, step count), and resource constraints (implied through 'maxSteps' parameter description). It doesn't mention permissions, rate limits, or side effects, but covers core execution behavior adequately.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured in two sentences: the first explains what the tool does and returns, the second provides usage guidance. Every sentence adds value—no wasted words—and it's front-loaded with the core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (debug execution with instrumentation) and lack of annotations/output schema, the description does well to explain the tool's behavior, return values, and usage context. It could potentially mention error handling or output format details, but it covers the essential aspects for a debugging tool adequately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters thoroughly. The description adds minimal parameter semantics beyond the schema—it mentions 'same format as edict_compile' for the AST parameter, which provides useful context, but doesn't elaborate on the 'options' object. This meets the baseline expectation when schema coverage is high.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('execute', 'compiles', 'runs', 'returns') and resources ('Edict program with debug instrumentation', 'structured crash diagnostics'). It explicitly distinguishes from siblings by naming 'edict_compile + edict_run' and stating when to use this alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool ('when debugging runtime failures') and when not to use alternatives ('Use this instead of edict_compile + edict_run'). It also explains the benefit ('enables targeted fixes without guessing'), giving clear context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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).
| Name | Required | Description | Default |
|---|---|---|---|
| ast | Yes | The Edict JSON AST to deploy | |
| target | Yes | Deploy target: 'wasm_binary' or 'cloudflare' | |
| config | No | Target-specific configuration |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the pipeline steps but doesn't cover critical aspects like whether this is a read-only or destructive operation, authentication requirements, rate limits, error handling, or what happens after deployment (e.g., does it activate immediately?). For a deployment tool with significant implications, this leaves major gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured in two sentences: the first states the purpose and pipeline, the second specifies targets and their outputs. Every word earns its place with zero wasted text, making it easy to parse and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex deployment tool with 3 parameters (including nested objects), no annotations, and no output schema, the description is insufficient. It doesn't explain what the tool returns (only hints at outputs for targets), doesn't cover error conditions, permissions, or side effects, and leaves the agent guessing about the behavioral impact despite the tool's likely significant consequences.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds some value by clarifying the target options and their outputs ('wasm_binary' returns WASM + metadata, 'cloudflare' generates Worker bundle), but doesn't provide additional semantic context beyond what's in the schema descriptions for 'ast' or 'config'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Deploy an Edict program to a target') and the full pipeline sequence ('validate → check → compile then packages'), distinguishing it from sibling tools like edict_check, edict_compile, or edict_package which handle individual pipeline steps rather than the complete deployment flow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context about when to use this tool by specifying the deployment targets ('wasm_binary' and 'cloudflare') and what each target produces. However, it doesn't explicitly state when NOT to use it or mention alternatives among the many sibling tools, such as using edict_package for packaging without deployment.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Given a structured error, returns enriched repair context: pipeline stage, field metadata, example ASTs, and repair strategy.
| Name | Required | Description | Default |
|---|---|---|---|
| error | Yes | A structured error object from the compiler (must have an 'error' discriminator field) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions the tool 'returns enriched repair context' but doesn't disclose behavioral traits like whether it's read-only, has side effects, requires specific permissions, or handles errors. The description adds minimal context beyond the basic operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, dense sentence with zero waste—it efficiently states the tool's purpose, input requirement, and outputs. Every word earns its place, and it's front-loaded with the core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 1 parameter with full schema coverage and no output schema, the description adequately covers the purpose and outputs. However, as a tool with no annotations and potential complexity (error analysis), it lacks details on behavioral traits, error handling, or return format, leaving gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents the single parameter 'error' with its description. The description adds marginal value by specifying the error must be 'structured' and from the compiler, but doesn't provide additional syntax, format details, or examples beyond what the schema implies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('returns enriched repair context') and resource ('structured error'), distinguishing it from siblings like 'edict_errors' (likely lists errors) or 'edict_debug' (general debugging). It specifies the exact outputs: pipeline stage, field metadata, example ASTs, and repair strategy.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by mentioning 'structured error from the compiler' and 'must have an error discriminator field', suggesting it's for post-error analysis. However, it lacks explicit guidance on when to use this versus alternatives like 'edict_debug' or 'edict_errors', and no exclusions or prerequisites are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Export an Edict AST as a portable WASM skill package with validation and manifest generation.
| Name | Required | Description | Default |
|---|---|---|---|
| ast | Yes | The Edict JSON AST to compile and export | |
| metadata | No | Optional metadata for the exported skill package |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions 'validation and manifest generation' which adds some behavioral context beyond basic export, but doesn't cover critical aspects like whether this is a read-only operation, potential side effects, error handling, performance characteristics, or output format details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence efficiently conveys the core functionality with zero wasted words. Front-loaded with the main action and resource, followed by key additional features. Every element earns its place in this compact description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that exports to WASM with validation and manifest generation (moderate complexity), with no annotations and no output schema, the description is insufficient. It doesn't explain what the output looks like, what validation entails, error conditions, or how the manifest is structured. More context is needed for proper agent usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, providing complete parameter documentation. The description doesn't add any parameter-specific information beyond what's in the schema, but with full schema coverage, the baseline score of 3 is appropriate as the schema adequately documents the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Export') and resource ('Edict AST') with the output format ('portable WASM skill package') and additional functions ('validation and manifest generation'). It distinguishes from siblings like edict_compile (compilation only) or edict_package (packaging without WASM export).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like edict_compile or edict_package. The description implies usage for WASM export scenarios but doesn't specify prerequisites, constraints, or comparison with sibling tools that might handle similar functionality.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| ast | Yes | The Edict program AST (module) — same format as edict_check |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It describes what the tool does (generates tests from contracts) and the output format (array of GeneratedTest objects), but lacks details on permissions, rate limits, or error handling. It adds some context on source types (boundary/counterexample), but could be more comprehensive for a tool with mutation implications (generating tests).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose in the first sentence, followed by supporting details in a logical flow. Each sentence adds value: explaining functionality for different contract states, output structure, and use case. There is no wasted text, making it highly efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (generating tests from formal verification) and lack of annotations and output schema, the description does a good job explaining the process and output. It covers the input (AST from edict_check), behavior for proven/failing contracts, and return format. However, it could improve by detailing error cases or integration with sibling tools, leaving minor gaps in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the parameter 'ast' well-documented in the schema. The description does not add any parameter-specific details beyond what the schema provides (e.g., format or examples), so it meets the baseline of 3. Since there is only one parameter, this is adequate but not enhanced.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Auto-generate structured test cases') and resource ('from Z3-verified contracts'), distinguishing it from siblings like edict_check (verification) or edict_run (execution). It explains the dual functionality for proven vs. failing contracts, making the purpose explicit and differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool ('to get free tests from formal specifications without writing them manually') and implies usage after verification (referencing 'Z3-verified contracts'). However, it does not explicitly state when not to use it or name alternatives among siblings, such as edict_examples or edict_debug, which might offer different testing approaches.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Import and execute a compiled Edict WASM skill package, validating its checksum.
| Name | Required | Description | Default |
|---|---|---|---|
| skill | Yes | The skill package JSON object (produced by edict_export) | |
| limits | No | Optional execution sandbox limits |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. While it mentions 'validating its checksum' which adds some context, it doesn't disclose important behavioral traits: whether this is a read-only or destructive operation, what permissions are required, what happens on successful import/execution, error conditions, or side effects. For a tool that imports and executes WASM packages, this is a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise - a single sentence that efficiently communicates the core functionality. It's front-loaded with the main purpose and includes the important checksum validation constraint. There's no wasted verbiage or unnecessary elaboration, though it could potentially benefit from slightly more context given the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that imports and executes WASM packages with 2 complex parameters (one being a deeply nested object), no annotations, and no output schema, the description is insufficient. It doesn't explain what happens after import/execution, what the tool returns, error handling, security implications, or how this differs from similar sibling tools. The description leaves too many contextual questions unanswered for such a potentially impactful operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides no parameter-specific information beyond the tool's overall purpose. However, with 100% schema description coverage, the schema already documents both parameters thoroughly: the 'skill' object with its nested structure and the optional 'limits' object with execution constraints. The description doesn't add value beyond what the schema provides, but doesn't need to compensate for schema gaps either.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Import and execute a compiled Edict WASM skill package, validating its checksum.' It specifies the verb ('import and execute'), resource ('compiled Edict WASM skill package'), and an important constraint ('validating its checksum'). However, it doesn't explicitly differentiate this tool from its many siblings (like edict_import_skill vs edict_invoke_skill or edict_deploy), which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With 22 sibling tools including edict_deploy, edict_invoke_skill, and edict_run, there's no indication of when this import/execution tool is appropriate versus those other execution-related tools. The description is purely functional without any contextual guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL of the deployed Edict service to invoke | |
| input | No | Request body to send to the service | |
| method | No | HTTP method (default: POST) | |
| timeoutMs | No | Request timeout in milliseconds (default: 10000) | |
| headers | No | Additional HTTP headers to send |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions sending a request and returning a structured result, but lacks details on error handling, authentication needs, rate limits, or what 'structured result' entails. For a tool that performs HTTP operations with potential side effects, this is insufficient behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the core purpose in the first sentence. The second sentence adds useful context about the deployment round-trip. No wasted words, though it could be slightly more structured for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete for a tool that performs HTTP invocations with potential mutations. It doesn't explain the nature of the 'structured result,' error conditions, or safety considerations, leaving significant gaps for an agent to understand tool behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all 5 parameters. The description adds minimal value beyond the schema, mentioning 'optional input' and 'structured result' but not elaborating on parameter interactions or usage examples. Baseline 3 is appropriate as the schema handles most documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Invoke a deployed Edict WASM service via HTTP' with specific verb ('invoke') and resource ('deployed Edict WASM service'). It distinguishes from siblings like edict_deploy or edict_compile by focusing on the invocation phase, but doesn't explicitly contrast with edict_invoke_skill or other invocation-related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context with 'Completes the deploy → invoke round-trip,' suggesting it should be used after deployment. However, it doesn't provide explicit guidance on when to use this tool versus alternatives like edict_invoke_skill or edict_run, nor does it specify prerequisites or exclusions beyond the deployment context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| skill | Yes | The SkillPackage JSON (produced by edict_package or edict_export) | |
| limits | No | Optional execution sandbox limits |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It describes the execution process (load WASM, verify checksum, run) and mentions structured output with exit code and return value, which adds useful context. However, it lacks details on permissions, error handling, side effects, or rate limits, leaving gaps for a tool that executes external code.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that efficiently conveys the core action, process steps, and return value. Every part earns its place, with no redundant or vague language, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (executing WASM code with sandbox limits), lack of annotations, and no output schema, the description is moderately complete. It covers the basic process and output structure but omits details on security implications, error cases, or performance constraints, which are important for such a tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so the baseline is 3. The description adds value by clarifying that the 'skill' parameter is a 'SkillPackage JSON (produced by edict_package or edict_export)', which provides semantic context beyond the schema's structural definition. This helps the agent understand the parameter's origin and format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Execute a packaged Edict skill') and the resource ('WASM from a SkillPackage'), specifying the process of loading, verifying checksum, and running. However, it doesn't explicitly differentiate from sibling tools like 'edict_invoke' or 'edict_run', which appear to be similar execution tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'edict_invoke' or 'edict_run' from the sibling list. It mentions executing a packaged skill but doesn't specify prerequisites, use cases, or exclusions, leaving the agent with minimal contextual direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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'.
| Name | Required | Description | Default |
|---|---|---|---|
| ast | Yes | The Edict JSON AST to lint |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does so well by disclosing key behavioral traits: it's non-blocking (implying asynchronous or quick operation), returns warnings in a structured format similar to errors with severity 'warning', and lists example warning types (e.g., unused variables). It does not mention rate limits or authentication needs, but for a linting tool, this is generally acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose in the first sentence, followed by essential details about output format. Every sentence adds value—no wasted words—making it efficient and easy to parse for an AI agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (linting analysis), no annotations, and no output schema, the description is quite complete: it explains the purpose, behavior, and output format. However, it could slightly improve by hinting at error handling or performance characteristics, but it's largely sufficient for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the 'ast' parameter fully documented in the schema. The description adds no additional meaning beyond the schema, such as format details or constraints for the AST, so it meets the baseline of 3 where the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Run non-blocking lint analysis'), the target resource ('an Edict AST'), and distinguishes it from siblings by specifying it returns quality warnings without blocking compilation, unlike tools like edict_compile or edict_check which likely involve compilation or validation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context for when to use this tool ('without blocking compilation'), implying it's for preliminary analysis rather than full validation or compilation. However, it does not explicitly state when not to use it or name specific alternatives among the many sibling tools, such as edict_check or edict_validate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| ast | Yes | The Edict module AST (the same JSON sent to edict_compile) | |
| wasm | Yes | Base64-encoded WASM binary (from edict_compile result) | |
| metadata | No | Optional metadata to embed in the skill package |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool creates a SkillPackage with specific components (interface metadata, verification info, checksum, embedded WASM), which is useful behavioral context. However, it lacks details on permissions, side effects, error handling, or performance characteristics that would be important for a packaging operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose in the first sentence, followed by input and output details. Every sentence earns its place by clarifying the tool's role and data flow, with no redundant or vague language, making it efficiently structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of packaging with multiple inputs and no output schema, the description is mostly complete: it explains the purpose, inputs, and output structure. However, it could improve by detailing the SkillPackage JSON format or error cases, as there's no output schema to fall back on. It compensates well but has minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds minimal value by mentioning that 'ast' and 'wasm' are from edict_compile, but does not provide additional semantics beyond what the schema specifies (e.g., format details or constraints). This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Package a compiled Edict module + WASM binary') and the resource ('into a portable SkillPackage'). It distinguishes this tool from siblings like edict_compile (which produces the inputs) and edict_deploy (which likely uses the output), by focusing on the packaging step in the workflow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by specifying that inputs come from edict_compile ('same one sent to edict_compile' and 'returned by edict_compile'), guiding when to use this tool in the pipeline. However, it does not explicitly state when not to use it or name alternatives among siblings, such as how it differs from edict_export or edict_import_skill.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| ast | Yes | The base Edict JSON AST to patch | |
| patches | Yes | Array of patches to apply | |
| returnAst | No | Include the patched AST in the response (costs tokens, off by default) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but provides minimal behavioral context. It mentions running 'the full check pipeline' after patching, which hints at validation behavior, but doesn't disclose critical details like error handling, performance implications, authentication needs, or what happens when patches fail. For a mutation tool with zero annotation coverage, this is inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise with three sentences that each earn their place: first states the core action, second provides usage guidance, third explains patch structure. No wasted words, and the most important information (what the tool does and when to use it) is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 3 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain what the 'full check pipeline' entails, what happens when patches conflict, what errors might be returned, or what the response format looks like. The agent lacks critical information about this tool's behavior and outputs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents all parameters. The description adds some context about patch structure ('Each patch specifies a nodeId, an operation, and the relevant field/value') but doesn't provide additional semantic meaning beyond what's in the schema. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Apply surgical patches to an Edict AST by nodeId, then run the full check pipeline') and distinguishes it from siblings by explaining its specialized use case ('fix errors without resubmitting the entire AST'). It explicitly contrasts with the likely bulk operations of other tools like edict_check or edict_validate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool ('Use this to fix errors without resubmitting the entire AST'), which clearly differentiates it from sibling tools that likely process complete ASTs. It implies this is for targeted corrections rather than initial validation or bulk operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| wasmBase64 | Yes | The base64 encoded WebAssembly module to execute | |
| replayToken | Yes | Replay token from a previous edict_run call with record: true | |
| limits | No | Optional execution limits |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does well by disclosing key behavioral traits: it explains that non-deterministic host responses (random values, timestamps, HTTP responses, file IO) are replayed from the token instead of calling real host functions. This clarifies the tool's deterministic nature and execution behavior, though it could add more on error handling or output format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded: the first sentence states the core purpose, and subsequent sentences add necessary context without waste. Every sentence earns its place by clarifying behavior and usage, making it efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (replaying WASM execution with tokens), no annotations, and no output schema, the description does a good job of explaining the tool's purpose and behavior. However, it lacks details on return values or error cases, which would be helpful for completeness, especially without an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents parameters well. The description adds some meaning by explaining the purpose of the replay token ('from a previous edict_run call with record: true') and the tool's overall function, but does not provide additional details on parameter usage beyond what the schema offers, meeting the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('re-execute', 'reproduce', 'verify') and resources ('WASM module', 'replay token'). It distinguishes from siblings by focusing on deterministic reproduction using recorded tokens, unlike tools like edict_run (which likely runs normally) or edict_debug (which might debug without replay).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool ('to reproduce exact failures or verify fixes against known execution traces'). It implies usage by describing the scenario but does not explicitly state when not to use it or name alternatives (e.g., edict_run for non-replay execution), which prevents a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| wasmBase64 | Yes | The base64 encoded WebAssembly module to execute | |
| limits | No | Optional execution sandbox limits | |
| externalModules | No | External WASM modules keyed by import namespace (base64-encoded). Edict programs can import functions from these modules. | |
| record | No | When true, capture all non-deterministic host responses (random, time, IO, HTTP) in a replay token. The token is included in the response and can be passed to edict_replay for exact reproduction. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does so well by disclosing key behavioral traits: sandboxed runtime with no ambient authority, host adapters for access, return values (output, exit code, errors), and the record feature for capturing non-deterministic responses. It lacks details on rate limits or specific error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, starting with the core action and key constraints, followed by additional features. Every sentence adds value without redundancy, making it efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the tool (4 parameters, nested objects, no output schema), the description is largely complete, covering execution behavior, sandboxing, and key features. However, it does not detail the exact format of return values or error cases, leaving some gaps for an agent to infer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds some context by explaining the purpose of limits and the record feature, but does not provide significant additional meaning beyond what the schema specifies, meeting the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Execute a compiled WebAssembly module'), resource ('in a sandboxed runtime'), and scope ('provided as base64'), distinguishing it from siblings like edict_compile or edict_replay by focusing on execution rather than compilation or reproduction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context for when to use this tool (e.g., for running WASM with sandboxing and optional limits) and hints at alternatives by mentioning edict_replay for deterministic reproduction, but does not explicitly state when not to use it or compare to other siblings like edict_invoke.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the JSON Schema defining valid Edict AST programs. Use format 'agent' for one-call bootstrapping (minimal schema + compact maps + builtins + effects).
| Name | Required | Description | Default |
|---|---|---|---|
| format | No | Schema format: 'full' (default, with descriptions), 'minimal' (stripped for token efficiency), 'compact' (compact key/kind mapping reference), or 'agent' (recommended: one-call bootstrap with minimal schema + compact maps + builtins + effects) | full |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It describes what the tool returns (JSON Schema) and hints at different formats, but it doesn't cover aspects like rate limits, authentication needs, error handling, or response structure. For a tool with no annotations, this leaves gaps in behavioral understanding, though the core functionality is clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise and front-loaded, consisting of two sentences that directly state the purpose and a key usage tip. Every word earns its place, with no redundancy or unnecessary information, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (1 parameter, no output schema, no annotations), the description is somewhat complete but could be improved. It covers the basic purpose and a usage tip, but without annotations or output schema, it lacks details on behavioral traits like error handling or response format. For a simple tool, this is adequate but not fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the 'format' parameter fully documented including enum values and a default. The description adds minimal value beyond the schema by mentioning the 'agent' format as recommended for bootstrapping, but it doesn't provide additional semantic context or usage examples. With high schema coverage, a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Return the JSON Schema defining valid Edict AST programs.' This specifies the verb ('Return') and resource ('JSON Schema defining valid Edict AST programs'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from siblings like 'edict_validate' or 'edict_lint' that might also involve schema-related operations, keeping it from a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use this tool by specifying 'Use format 'agent' for one-call bootstrapping (minimal schema + compact maps + builtins + effects).' This gives a recommended usage scenario. However, it doesn't explicitly mention when not to use it or name alternatives among the many sibling tools, such as 'edict_validate' for validation instead of schema retrieval.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns structured sponsorship and support information for the Edict project
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool returns information (implying a read-only operation) but doesn't cover critical aspects like authentication needs, rate limits, error handling, or the format/structure of the returned data. For a tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence: 'Returns structured sponsorship and support information for the Edict project.' It's front-loaded with the core action and resource, with zero wasted words. Every part of the sentence contributes to understanding the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what 'structured sponsorship and support information' entails (e.g., format, content), behavioral traits like side effects or permissions, or how it fits into the broader Edict project context. For a tool in a complex server with many siblings, more detail is needed to guide the agent effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100%, so there's no need for parameter details in the description. The baseline for this scenario is 4, as the description appropriately avoids redundant information. It doesn't add meaning beyond the schema, but that's acceptable given the lack of parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Returns structured sponsorship and support information for the Edict project.' It specifies the verb ('returns') and resource ('sponsorship and support information'), distinguishing it from siblings like 'edict_check' or 'edict_compile.' However, it doesn't explicitly differentiate from all siblings (e.g., 'edict_version' might also return info), so it's not a perfect 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context (e.g., when support info is needed), or exclusions (e.g., not for debugging). With many sibling tools, this lack of differentiation leaves the agent guessing about appropriate usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate an Edict AST against the compiler's JSON schema without typing or compiling. Use this as a first pass.
| Name | Required | Description | Default |
|---|---|---|---|
| ast | Yes | The Edict JSON AST to validate |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states what the tool does (validate AST against schema) and what it doesn't do (no typing or compiling), which is helpful. However, it lacks details on error handling, output format, or performance characteristics that would be valuable for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—two sentences that are front-loaded with purpose and usage guidance. Every word earns its place, with no redundant or vague phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (validation without compilation), no annotations, and no output schema, the description is adequate but incomplete. It explains the purpose and usage well but omits details about what validation results look like (e.g., success/failure messages, error formats) that would help an agent use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents the single 'ast' parameter. The description adds no additional parameter semantics beyond what's in the schema (e.g., no format examples or constraints). This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('validate'), the target resource ('Edict AST'), and the scope ('against the compiler's JSON schema without typing or compiling'). It distinguishes this tool from siblings like 'edict_compile' or 'edict_check' by emphasizing it's a 'first pass' validation only.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides usage guidance: 'Use this as a first pass.' This indicates when to use it (early validation) and implicitly when not to use it (for full compilation or typing). It differentiates from alternatives like 'edict_compile' by specifying its limited scope.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0edict_checkedict_compileedict_composeedict_debugedict_deployedict_errorsedict_examplesedict_explainedict_exportedict_generate_testsedict_import_skilledict_invokeedict_invoke_skilledict_lintedict_packageedict_patchedict_replayedict_runedict_schemaedict_supportedict_validateedict_versionMost 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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Control plane for autonomous software labor. Agents claim objectives over MCP with audit trail.
Multi-agent coordination protocol on Solana. Swarm formation, on-chain settlement, 14 MCP tools.
Package intelligence MCP for AI agents — 22 tools, 19 ecosystems, AGPL SDK, free.
Stateless agentic tools over MCP: concept extraction, long-context, knowledge graph, planning.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Sowiedu/Edict'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
