Four tools with clear, domain-specific descriptions (legal case lookup in Tucumán SAE). All tools have input schemas with types and descriptions. Naming follows verb_noun pattern (sae_consultar, sae_buscar, sae_traer, sae_listar). However, parameter descriptions lack actionable constraints (e.g., 'maxMovimientos' has min/max but no guidance on typical values or performance impact). Output schemas are not formally documented, responses are formatted as text strings rather than structured objects. Error handling is present but generic (SaeError type exists but recovery guidance is minimal). No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite all tools being read-only. Parameter relationships (e.g., url vs procid+jurisdiction) are documented but could be clearer.

• Convert text-formatted responses to structured JSON objects. E.g., sae_consultar_causa should return {caratula, nro_expediente, actor, demandado, juzgado, tipo_proceso, movimientos: [{histid, fecha, dscr, firm, hasAttachment}]} instead of a formatted string. This enables reliable field extraction and downstream tool chaining.
• Add readOnlyHint: true to all four tool definitions in the MCP server registration. This signals to clients that these tools are safe to cache and retry without side effects.
• Enumerate valid 'fuero' values in sae_buscar_por_numero description, or add a note: 'Call sae_listar_fueros first to see available jurisdictions for your centro.' This prevents hallucinated fuero names.
• Enhance error messages with recovery guidance. E.g., if fuero is invalid, return: 'Invalid fuero. Available: [list]. Call sae_listar_fueros to discover all options.' instead of a generic error.
• Document parameter relationships explicitly in schema descriptions. For sae_consultar_causa and sae_traer_documento, state: 'Provide either url OR (procid + jurisdiction), not both. If you have a URL, url takes precedence.'

Inferred effective spec: 2026-07-28+.

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