Eight read-only tools with consistent naming (verb_noun pattern: search_*, get_*) and complete JSON schemas. All tools have descriptions (avg 85 chars, within 10-1024 range). Parameters are typed and described. However, descriptions are terse and lack WHEN/WHY guidance for LLM selection. No output schemas documented. Error handling is minimal, no recovery guidance or actionable error messages visible. Tool composition is sound (search → detail → history chain), but descriptions don't explain this flow. Schemas are present but sparse on constraints (no enums for canton, publication_type, process_type despite known valid values in constants.py).

• Add enum constraints to schemas for canton, publication_type, process_type, code_system. Extract from constants.py and embed in JSON Schema 'enum' arrays.
• Document output schemas for all tools. E.g., search_procurements returns {items: [ProcurementSummary], total: int, next_cursor?: string}. Include field descriptions.
• Expand tool descriptions to 100-150 chars with WHEN/WHY. E.g., 'Search for active tenders across all Swiss cantons. Use this for broad discovery; use search_procurements_detailed for filtering by process type or publication status.'
• Add error recovery hints. E.g., get_procurement_details: 'If project not found, try search_procurements first to verify the project_id and publication_id.'
• Document pagination strategy. If limit=50 is enforced, state it. If cursor-based, return next_cursor in response. If offset-based, accept offset parameter.

Inferred effective spec: 2026-07-28+.

• Relies on Logging (deprecated) - log to stderr or use OpenTelemetry