A Model Context Protocol server for interacting with Starknet, enabling block information retrieval and more
Single tool 'get_block' has critical gaps. Tool naming is acceptable but description is minimal (60 chars). Input schema is present but incomplete: blockNumber parameter lacks description and is not required despite being the only meaningful input. Parameter is numeric but has no min/max constraints. Output is entirely missing, no documented schema for return value. Error handling exists but lacks recovery guidance. The tool ignores its own input parameter (always fetches 'latest' block) making the blockNumber parameter misleading. This is a structural mismatch between signature and implementation.
Get a block from the Starknet blockchain
Input parameter 'blockNumber' is ignored in implementation, tool always fetches 'latest' block regardless of parameter value. This makes the parameter misleading and wastes the LLM's reasoning effort.
Tool description is 60 characters, too minimal to guide LLM selection. This description lacks WHAT the tool does precisely, WHEN to use it, and prerequisite knowledge.
Parameter 'blockNumber' has no type constraints, no min/max bounds, no enum, no pattern. Numeric parameters without bounds allow LLMs to pass absurd values (negative, zero, 999999999999).
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-21 | F | 41 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 10 | - | v1 |
Output schema completely undocumented. LLMs need to know what fields to expect.' Tool returns text summary but no structured schema is declared. LLM cannot plan downstream calls or extract structured data.
Error handling exists (McpError, StarknetError) but lacks recovery guidance.