MCP-OBERON is a moderately well-structured server with 14 tools for an Oberon ERP system. Tool naming follows verb_noun conventions (Obtener_, Buscar_, Crear_, Verificar_), which is good. Descriptions are present for all tools and generally informative (150-300 chars), but lack actionable guidance on WHEN to use each tool vs. alternatives. Schemas are well-defined with proper types, enums, and defaults. However, output schemas are not documented, the rubric requires tools to document what fields they return (e.g., 'Obtener_Clientes returns JSON parseable in field text' is vague; should specify fields like id, name, role, zone, locations). Error handling is minimal, tools do not guide recovery (e.g., no guidance on what to do if a search returns 0 results). Security is reasonable (token passed server-side), but tools lack explicit permission declarations. Tool composition is fragmented, separate 'Obtener_Clientes', 'Obtener_Cliente_por_ID', and 'Buscar_Registros_De_Funcionalidad' exist, but the LLM instructions compensate for this fragmentation via the systemPrompt, which is not scalable. Parameter descriptions are adequate but could be more precise (e.g., 'terminoBusqueda' lacks format guidance).

• Document output schemas for all tools. For each tool, specify: 'Returns a JSON object with fields: {id: string, name: string, email: string, role: {id: string, name: string}, ...}'. This enables LLMs to plan downstream calls.
• Add error recovery guidance to tool descriptions. E.g., for Obtener_Clientes: 'If no results, try searching with partial names or check that clients are active in the system.'
• Distinguish tool selection in descriptions. E.g., 'Obtener_Clientes: list all clients with filtering and pagination. Use this to discover clients or perform bulk operations. For a single client by ID, use Obtener_Cliente_por_ID instead.'
• Add JSON Schema constraints or examples to 'filtro' parameter. Provide a structured schema showing valid operators (equals, contains, between, etc.) and example filter structures.
• Implement a confirmation/dry-run pattern for Crear_Usuario. Add an optional 'dry_run' parameter (default false). When true, return a preview of the user that would be created without committing it.
• Rename GPS and temperature tools to use more explicit verbs: 'get_vehicle_gps_location' and 'get_vehicle_temperature' to reduce ambiguity.
• Add permission annotations to tool definitions. Each tool should declare required scopes (e.g., 'Requires: read:clients') in its description or metadata.
• Implement pagination result limits in tool descriptions. E.g., 'Returns up to 100 clients per page. Use pagination to handle larger result sets.'
• For Buscar_Registros_De_Funcionalidad, provide a helper tool or resource 'get_filterable_fields_for_functionality' that returns the fields available for filtering in a given functionality, along with their data types. This prevents malformed filters.

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

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