Loading ToolBench
A Next.js application for managing EVM smart contracts, generating MCP and GPT action schemas, and providing contract interaction endpoints
EVM TensorKit is a Next.js application exposing smart contract interaction tools via HTTP APIs, not a traditional MCP server. The tool definitions lack rigor across naming, parameter descriptions, and output schemas. Most tools have generic or missing descriptions, parameter types are inconsistent (many lack explicit type definitions), and output schemas are not documented. 7 of 10 tools lack proper input validation hints. Only 2 tools (importContract, createProject) have complete-looking parameter sets; the rest are either READ_ONLY stubs or incomplete. The server mixes concerns (tool generation, contract introspection, project management) without clear compositional boundaries.
Creates a new project for organizing smart contracts
Generates a Dockerfile for the TypeScript server
Generates a package.json for the TypeScript server
Generates TypeScript server files for a smart contract
Generates TypeScript server code from MCP schema
Retrieves MCP or GPT schema for a contract by address and executes contract functions
Retrieves contract schema and metadata by contract address
Imports a smart contract via Etherscan link or manual entry
Tool definitions lack input schemas or have empty input schemas (generateDockerfile: {}, generatePackageJson: only contractName). LLMs cannot infer parameter types or validate input without explicit schema.
Output schemas are not documented for any of the 10 tools. LLMs have no visibility into what fields are returned, preventing composition and downstream tool chaining. This violates baselines where 100% of A+ tools have documented return types.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 40 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 36 | - | v1 |
Lists all projects for the authenticated user
Updates custom descriptions for smart contract functions
Multiple tools are duplicates or have overlapping responsibilities: generateTypeScriptServer, generateServerFiles, and generatePackageJson all appear to generate server artifacts but lack clear distinction. getContractServer and getContractServerByAddress both retrieve contract schemas by address. Tool composition violates single-responsibility pattern.
Parameter descriptions are missing or generic for 7 tools. Examples: 'action' parameter in getContractServer has no description; mcpSchema in generateTypeScriptServer is described only as 'JSON string containing MCP schema actions' without format or validation guidance. Baselines show 100% of A+ tools have descriptions for all parameters.
getContractServer combines two distinct operations ('Retrieves MCP or GPT schema' AND 'executes contract functions'). This violates single-responsibility and makes LLM selection ambiguous. Should split into getContractSchema and executeContractFunction.
listProjects lacks pagination parameters (limit, offset) and does not document result count or cursors. Without pagination, unbounded result sets will exhaust context windows. Violates pattern:paginated-result baseline.
Parameter constraints are undocumented or missing. Examples: contractAddress parameters are typed 'string' with no validation that it is a valid EVM address format; no length limits or character restrictions stated. LLMs have no guidance on what constitutes valid input and will pass hallucinated values.
Tool descriptions are under 50 characters for 3 tools (generateDockerfile: 'Generates a Dockerfile...'), violating baseline of 194 chars average. Too short leaves LLMs without context for tool selection and use case.
updateContractFunctionDescriptions is defined in a React component (ContractFunctionEditor.tsx), not explicitly registered as an MCP tool with schema. Tool existence is inferred from source code structure rather than explicit registration.