Loading ToolBench
MCP Server for ENACT Protocol — AI Agent Commerce on TON. Provides tools for creating and managing escrow jobs on the TON blockchain, with support for encrypted results and agentic wallet signing.
23 tools with consistent naming (verb_noun pattern: enact_get_*, enact_create_*, enact_submit_*) and descriptions present for all. However, descriptions are brief (avg ~80 chars, below 194-char baseline) and lack context on when to use each tool vs. alternatives. Input schemas visible and typed, but parameter descriptions are minimal (avg ~40 chars vs. 72-char baseline). No output schemas documented. Error handling guidance absent. Tools are well-composed (single responsibility) and parameters are appropriately constrained (enums for role in enact_decrypt_job_result). Missing: recovery guidance, actionable error messages, and richer parameter documentation.
Client: cancel an open or funded job and reclaim the budget.
Provider: claim payment after a job is completed and approved.
Create a USDT-budgeted job on ENACT. Similar to enact_create_job but uses the JettonJobFactory. Returns the new job contract address.
Create a TON-budgeted job on ENACT. Sends ~0.03 TON in gas plus the budget-funding flow is a separate tool (enact_fund_job). Returns the new job contract address.
Decrypt an encrypted envelope JSON (as stored on IPFS) using the configured wallet. Returns the plaintext result.
Detect if a TON address is an agentic wallet (ENACT-compatible agent-controlled wallet).
Evaluator: approve (pays provider) or reject (refunds client) a submitted result. Optional reason is uploaded to IPFS if configured.
Output schemas not documented. LLMs cannot plan downstream tool calls or extract required fields (e.g., job_address returned by enact_create_job, enact_create_jetton_job). Agents must infer structure from descriptions.
Descriptions are brief (avg ~80 chars) and lack context on when to use each tool vs. alternatives. E.g., enact_create_job vs. enact_create_jetton_job distinction is unclear from descriptions alone. No guidance on prerequisites or dependencies.
No error handling guidance. Tools like enact_create_job, enact_fund_job, and enact_take_job are state-changing but provide no recovery hints if they fail. LLMs cannot determine if errors are retryable or require user intervention.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 56 | 2026-07-28+ | v2 |
Send the budgeted USDT to a jetton job contract to move it from OPEN to FUNDED.
Send the budgeted TON to a job contract to move it from OPEN to FUNDED.
Generate a new ed25519 keypair for an agentic wallet operator.
Return the total number of USDT (jetton) jobs ever created by the ENACT JettonJobFactory.
Resolve a job's TON contract address from its numeric id. Set jetton=true for USDT jobs.
Return the total number of TON jobs ever created by the ENACT JobFactory.
Fetch full status for a single job by TON address: state name, budget, client/provider/evaluator addresses, and the IPFS hashes of the description, result, and reason.
Return the configured wallet's user-friendly TON address. Requires a mnemonic to be configured on the EnactClient.
Read the ed25519 public key (hex, 64 chars) from any TON wallet address. Pass the address to look up, or omit to use the configured wallet.
List every USDT job deployed by the ENACT JettonJobFactory.
List every TON job deployed by the ENACT JobFactory. Returns an array of {job_id, address, type}.
Provider: abandon a taken job before submitting a result.
Client: increase the budget of an open job. Sends additional TON to the job contract.
Provider: submit an E2E-encrypted result. Only the client and the evaluator (by their 32-byte ed25519 public keys) can decrypt. Use enact_get_wallet_public_key to fetch each role's pubkey first.
Provider: submit a plaintext result to a job. The result text is uploaded to IPFS and its SHA-256 is stored on-chain.
Register the configured wallet as the provider on an open job.
Parameter descriptions are minimal (avg ~40 chars vs. 72-char baseline). E.g., 'Job timeout in seconds' lacks range constraints. 'Budget amount in TON' does not specify format (decimal places, min/max). LLMs cannot validate inputs without explicit constraints.
No pagination or result limits documented for list tools (enact_list_jobs, enact_list_jetton_jobs). If job counts grow large, responses could exhaust context windows. No limit parameter or cursor guidance provided.