MCP server exposing a DappQL project to AI coding agents — contract introspection, multicall reads, write simulation, and optional gated write execution.
The @dappql/mcp server has critical gaps in tool definitions. While 14 tools are listed, the provided source code does NOT include the actual tool registration code, schemas, or descriptions. Only package.json files are visible. Without access to the tool implementation in packages/mcp/src/tools/*.ts, I cannot verify schemas, parameter types, descriptions, or error handling. The server lists 14 tools across metadata.ts, chain.ts, and codegen.ts, but without the actual TypeScript source showing schemas, descriptions, and parameter definitions, the quality cannot be assessed.
NO TOOL DEFINITIONS VISIBLE IN SOURCE CODE. All 14 tools are listed by filename but actual tool registration code (with schemas, descriptions, parameter types) is not provided. Cannot verify any tool meets definition quality standards.
MISSING INPUT SCHEMAS for all tools. Without TypeScript source showing tool.input() or InputSchema definitions, cannot verify parameter types, constraints, or required vs optional fields.
MISSING PARAMETER DESCRIPTIONS for all tools. Without seeing the actual tool implementation, cannot verify each parameter has a description explaining what it does, what format/range is expected, and how it affects behavior.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 28 | 2026-07-28+ | v2 |
MISSING TOOL DESCRIPTIONS for all tools. The 14 tool names are inferred from filenames only (metadata.ts, chain.ts, codegen.ts). No descriptions visible explaining what each tool does, when to call it instead of similar tools, or what it returns.
UNDEFINED OUTPUT SCHEMAS. No evidence of documented return types, response field naming, pagination support (for list_* tools), or structured output schemas. LLMs cannot plan downstream calls without knowing what fields to expect.
NO VISIBLE ERROR HANDLING DOCUMENTATION. Tools like callWriteTool and simulateWriteTool (marked WRITE risk) have no visible error recovery guidance or categorization (retryable vs user-fixable vs fatal).
WRITE OPERATIONS LACK CONFIRMATION/DRY-RUN SUPPORT. callWriteTool and regenerateTool are destructive but no evidence of dry-run simulation, confirmation steps, or undo tools visible in source.
UNCLEAR TOOL COMPOSITION. With 14 tools spanning metadata queries, chain reads, writes, events, and codegen, it's unclear how tools chain together. searchMethodsTool returns what? Are IDs chained to callReadTool? Without visible output schemas, composition cannot be verified.
AMBIGUOUS NAMING FOR SIMILAR TOOLS. 'callReadTool' vs 'multicallTool', unclear distinction. Are they variants of the same operation or fundamentally different? 'simulateWriteTool' vs 'callWriteTool', when to use one vs the other? Names should answer this without reading descriptions.
NOUN-ONLY NAMING CONVENTION. All tool names end with 'Tool' suffix (getDappqlReferenceTool, projectInfoTool, etc.). This is non-standard. Standard convention is action_noun (get_dappql_reference, project_info). The 'Tool' suffix is redundant and violates verb_noun convention.