Server has 11 tools with complete input schemas and descriptions. Naming follows verb_noun convention (listar_*, consultar_*, criar_*, etc.). Descriptions are substantive (100-250 chars typical), explaining WHAT and WHEN. However, output schemas are entirely undocumented, no tool declares what fields it returns, forcing LLMs to infer structure. Parameters lack granular constraints (enums, min/max ranges). Error handling is minimal: generic HTTP status codes without recovery guidance. Security is strong (credentials via env vars, audit logging), but composition has gaps: sienge_api is a generic passthrough that duplicates specialized tools, and no pagination metadata (total count, next_cursor) is documented.

• Document output schemas for all 11 tools. Example: listar_solicitacoes_compra should declare it returns {items: [{id, numero, obra, departamento, solicitante, status, data}], total, limit, offset}.
• Add min/max constraints to numeric parameters. E.g. limit: {type: 'integer', minimum: 1, maximum: 200, description: '...'}. Specify default values explicitly.
• Replace 'filtros' (additionalProperties: true) with explicit, documented filter parameters (e.g. status, dateFrom, dateTo) or an enum of valid filter keys.
• Enhance error handling: return structured errors with error_code, message, and recovery_hint. E.g. {error_code: 'INVALID_FILTER', message: 'Unknown filter key', recovery_hint: 'Valid filters: status, date_from, date_to'}.
• Consider deprecating sienge_api or clearly document when to use it vs. specialized tools. Add a note: 'Use specialized tools (listar_*, criar_*, etc.) when available. Use sienge_api only for endpoints not covered by specialized tools.'

Inferred effective spec: <=2025-11-25.

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