evernode-mcp

Check Xahau Hook / WASM compatibility

check_hook_compat

Read-onlyIdempotent

Determines if a dApp's Xahau account uses a Hook and outputs the workflow to build, simulate, and prove spend invariants.

Instructions

When a dApp settles value on Xahau through a Hook-guarded account, hands off to the trifecta: build/lint the Hook with xahc, simulate it with xahau-mcp, and PROVE the spend invariant with xahc-prover. Returns the recommended workflow.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "involves_hook": "<involves_hook>"
    },
    "name": "check_hook_compat"
  }
}

Input Schema

Name	Required	Description	Default
`what`	No	what the hook should enforce, e.g. 'per-tx spend limit'
`involves_hook`	Yes	does the dApp's Xahau account run a Hook?

Output Schema

Name	Required	Description	Default
`repos`	No
`workflow`	No
`involvesHook`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.5.0Jul 29, 2026

TDQS

A3.9/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations declare readOnlyHint=true and idempotentHint=true, which are consistent with the description's mention of 'returns the recommended workflow' (no destructive actions). The description adds that the tool 'hands off to the trifecta' (build, simulate, prove) but does not clarify whether it actually executes these steps or merely recommends them. The return of a workflow is transparent. No contradictions with annotations.

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 two sentences covering the usage scenario and return value. It is fairly concise but could be more direct by starting with 'Checks compatibility by recommending a workflow...' rather than the scenario-first structure. Still, no superfluous content.

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 moderate complexity, presence of an output schema, and well-described parameters, the description covers the high-level purpose and behavior. It explains the three steps of the workflow (build, simulate, prove) and states the return. It doesn't detail the output schema format, but the output schema itself handles that. The description is complete enough for an agent to understand what the tool does.

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 coverage is 100%, with each parameter having a clear description in the schema. The tool description does not add additional context or constraints beyond what the schema provides. For example, 'what' is described as 'what the hook should enforce' in both schema and description, with the schema providing an example. No further enrichment.

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 states that the tool returns a recommended workflow for checking hook compatibility when a dApp settles value on Xahau through a Hook-guarded account. The title 'Check Xahau Hook / WASM compatibility' aligns with this. However, the description is somewhat indirect and doesn't explicitly state 'this tool checks compatibility', relying on the scenario and implied purpose. It does not explicitly differentiate from sibling tools like check_determinism, but the specific Hook scenario provides some distinction.

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 specific usage context: 'When a dApp settles value on Xahau through a Hook-guarded account'. This clearly indicates when the tool is applicable. It does not explicitly mention when not to use it or suggest alternative tools, but given the sibling list and unique purpose, the guidance is adequate.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server