DartMCP has a single tool 'greet' with critical gaps across all definition quality dimensions. The tool has a trivial description (12 chars: 'A basic tool that can respond with "greet!"'), an empty input schema (ObjectSchema() with no properties), and no parameter descriptions. The tool is a toy example, not a production-grade tool. The input schema is explicitly instantiated as ObjectSchema() in the code (lib/src/server.dart line 32), confirming it has no fields or validation.
A basic tool that can respond with "greet!"
Tool description is trivial (12 characters: 'A basic tool that can respond with "greet!"'). LLMs cannot determine when or why to select this tool.
Input schema is empty (ObjectSchema() with no properties, no constraints). Even trivial tools need documented parameters or an explicit statement that the tool takes no input.
Tool name 'greet' does not follow verb_noun convention. It should be 'send_greeting' or 'get_greeting' to clarify the action. Current name is too generic and does not reflect the action being taken.
No output schema documentation. LLMs need to know what the tool returns (a text response, an object, etc.) to plan downstream calls and extract data. The CallToolResult returns TextContent but this is not documented in the tool definition.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 23 | 2026-07-28+ | v2 |
No error handling or recovery guidance. If the tool fails, the LLM has no context for retry or fallback behavior.