This server has 3 tools with minimal definitions. All tools are registered with names and basic descriptions, but parameter documentation is sparse and output schemas are completely undocumented. Tool names use verb conventions (get*) which is good, but descriptions are too generic (10-20 chars) and parameters lack meaningful context. No error handling guidance, no pagination support despite domain complexity, no output schema documentation. The getVouchers tool accepts an optional 'owner' parameter but the description is vague ('optionnal' spelling error, unclear what 'empty' means). The getWalletInfo tool requires a 'wallet' parameter but does not clarify format (address, name, ENS?). getLastBlock has zero parameters but its output is completely undocumented. Overall, this reads as a thin wrapper over blockchain APIs with minimal consideration for LLM-friendly design.

• Expand tool descriptions to 50-200 characters, explaining: WHAT the tool does (which blockchain data), WHEN to call it (lookup scenario), and WHAT it returns (field names). Example: 'Get Vouchers: Retrieve The Graph protocol vouchers for a subgraph owner. Returns list of voucher objects with id, owner, and token amounts. Use when querying indexing rewards or delegation records.'
• Document output schemas. For each tool, provide a JSON example or schema showing expected response structure. getLastBlock should document: {blockNumber: number, timestamp: number, hash: string}. getWalletInfo should show: {address: string, balance: string, tokens: [...]}.
• Add format guidance to parameters. Update 'wallet' parameter description to: 'Ethereum address (0x...) or ENS name (example.eth). Address takes priority if both provided.'
• Fix spelling: 'optionnal' → 'optional'. Rewrite getVouchers owner param description: 'Subgraph owner address (0x...) to filter vouchers. If omitted, returns all vouchers.'
• Add pagination to getVouchers. Include parameters: limit (1-100, default 20), offset (default 0). Return {vouchers: [...], total: number, nextOffset: number|null}.
• Add error guidance. Document what happens if wallet not found, API timeout, or invalid format. Example recovery: 'If wallet not found, try searching with partial name first.' Use a recovery-guide pattern.
• Consider adding a search_vouchers or search_wallets tool to help the agent disambiguate when full IDs are unknown. Current tools assume exact addresses, which matches LLM capabilities poorly.