Server exhibits critical definition gaps across all dimensions. Tool names lack consistent verb prefixes (listar_agentes_tess vs executar_agente_tess use Portuguese verbs inconsistently). Descriptions are present but generic (10-50 chars, well below 194-char baseline). Input schemas exist but lack rigor: many parameters are typed as 'string' when they should be constrained (e.g., temperature as string '0-1' instead of number with min/max). No output schemas documented. Error handling is absent, no recovery guidance, no categorization. The codebase shows mixed implementation (Rust WASM + Node.js + Python FastAPI) with tool definitions scattered across files, making verification difficult. Tool 'executar_agente_tess' accepts 'messages' as string (should be structured array) and 'tools' as string (should be array). No evidence of idempotency, permission gates, or audit logging.

• Convert all numeric parameters to proper JSON Schema types with min/max constraints. E.g., temperature: {type: 'number', minimum: 0, maximum: 1, description: '...'}
• Document output schemas for all tools. Include field names, types, and descriptions. E.g., listar_agentes_tess should return {type: 'object', properties: {agents: {type: 'array', items: {type: 'object', properties: {id, name, ...}}}}}
• Expand descriptions to 100-200 characters with WHAT/WHEN/WHY guidance. E.g., 'Retrieves a list of all available TESS agents. Call this first to discover agent IDs before executing. Returns paginated results (default 15 per page, max 100).'
• Implement structured error responses with recovery hints. E.g., {error: 'Agent not found', code: 'AGENT_NOT_FOUND', suggestion: 'Call listar_agentes_tess to see available agents', retryable: false}
• Consolidate tool definitions into a single MCP server implementation (choose Rust or Python, not both). Use explicit tool registration with full schemas and descriptions.

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

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