Three well-named tools with strong, detailed descriptions (194 - 250 chars each) that clearly state WHAT, WHEN, and WHY. Input schemas are present with proper JSON Schema structure and type declarations. However, output schemas are completely undocumented, LLMs cannot predict what fields to expect from responses, breaking downstream tool chaining. Parameter descriptions are good but lack explicit constraints (e.g., limit ranges, format specs). Error handling returns structured {error, retry_hint} but lacks categorization (retryable vs fatal). No tool annotations (readOnlyHint, idempotentHint) despite all three being read-only operations.

• Document output schemas for all three tools. Define FeedTender structure (id, reference, title, agency, published, open_date, close_date, region[], categories[], overview, url) and detail response structure (tender_type, coverage, department, contact, etc.) as JSON Schema objects in tool definitions.
• Add explicit min/max constraints to limit parameters: 'limit (1 - 300, default 25)' for nz_tender_open and 'limit (1 - 100, default 25)' for nz_tender_search. Include in both description and schema.
• Add tool annotations: set readOnlyHint=true and idempotentHint=true on all three tools to signal safety properties to LLMs.
• Enhance error responses with classification: return {error, category: 'retryable'|'user_fixable'|'fatal', retry_hint, suggestion} so LLMs know whether to retry, ask the user, or abort.
• Clarify transport in README and package.json. Specify HTTP endpoint, SSE support, or STDIO mode. If HTTP, document base URL and authentication (currently keyless per description).