edict-lang

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.21.0
Disambiguation4/5
Most tools have distinct purposes clearly described, such as edict_compile for compilation and edict_run for execution. However, some overlap exists between edict_deploy (which includes validation, checking, and compilation) and other tools like edict_validate and edict_compile, which could cause confusion about when to use each. The descriptions generally help clarify boundaries, but the pipeline overlap is noticeable.
Naming Consistency5/5
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.
Tool Count3/5
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.
Completeness4/5
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.
Average 3.4/5 across 22 of 22 tools scored. Lowest: 1/5.
See the Tool Scores section below for per-tool breakdowns.
- 3 of 4 community issues answered or closed in the last 6 months
- 4 commits in the last 12 weeks
- Last stable release on April 15, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior1/5
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.
Conciseness1/5
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.
Completeness1/5
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.
Parameters1/5
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.
Purpose1/5
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.
Usage Guidelines1/5
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.
Behavior1/5
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.
Conciseness1/5
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.
Completeness1/5
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.
Parameters1/5
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.
Purpose1/5
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.
Usage Guidelines1/5
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.
Behavior1/5
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.
Conciseness1/5
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.
Completeness1/5
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.
Parameters1/5
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.
Purpose1/5
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.
Usage Guidelines1/5
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.
Behavior2/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines3/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters4/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters4/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines4/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![Edict MCP server](https://glama.ai/mcp/servers/Sowiedu/Edict/badges/card.svg)](https://glama.ai/mcp/servers/Sowiedu/Edict)

Score Badge

Copy to your README.md:

[![Edict MCP server](https://glama.ai/mcp/servers/Sowiedu/Edict/badges/score.svg)](https://glama.ai/mcp/servers/Sowiedu/Edict)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

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