Server has 4 well-named tools with complete input schemas and reasonable descriptions. Tool names follow verb_noun pattern (search_notices, get_notice_summary, get_notice_full, get_expiring_soon). All tools have descriptions 50-100 chars. Input schemas are properly typed with enums and constraints (notice_type, procurement_type, procedure_type). However, output schemas are not documented, callers cannot see what fields to expect from responses. Error handling is minimal; no recovery guidance or actionable error messages visible. No tool annotations (readOnlyHint, destructiveHint). Parameter descriptions are adequate but lack format/range details (e.g., 'days' has no min/max bounds). Missing pagination documentation for search_notices despite accepting 'top' and 'skip' parameters.

• Document output schemas for all 4 tools. Specify the structure of HilmaNotice objects returned by search_notices and get_expiring_soon, and the structure returned by get_notice_summary and get_notice_full. Include field names, types, and which fields are always present vs. optional.
• Add min/max bounds to numeric parameters: days (1 - 365), hours (1 - 8760), top (1 - 100), skip (0 - 10000). Include these constraints in parameter descriptions so LLMs understand valid ranges.
• Implement structured error responses with recovery guidance. E.g., 'API key invalid. Check HILMA_API_KEY environment variable.' or 'Notice not found (ID: 12345). Try search_notices() to find valid IDs.' Return error category (retryable, user-fixable, fatal) so agents know next steps.
• Add tool annotations to schema. Mark all 4 tools with readOnlyHint: true since they only read data and are safe to retry. This enables agents to optimize retry logic and avoid unnecessary confirmation prompts.
• Enhance search_notices description to explain pagination: 'Returns up to `top` results (default 20, max 100). Use `skip` to paginate. Response includes total count via @odata.count. Iterate until results < top or @odata.count exhausted.'