The Oracle EPM Cloud MCP server has well-intentioned tool definitions with reasonable descriptions and clear naming. However, several significant quality gaps prevent it from reaching production-grade status. All 7 tools are explicitly registered with names, descriptions, and input schemas visible in server/index.js. Tool names follow verb_noun convention (get_*, list_*, run_*, check_*, export_*, update_*) which is positive. However, parameter descriptions are minimal or absent in most cases, and output schemas are completely undocumented. The tools return raw JSON dumps of API responses without any structure guidance for LLM parsing. Error handling is absent, there are no recovery guides, error classifications, or actionable error messages. The lack of pagination support on list_applications and export_data_slice creates risks of context window exhaustion. While descriptions average ~100 chars (within baseline), they lack the specificity and LLM-optimization patterns needed for confident tool selection in complex scenarios.

• Document output schema for each tool as a JSON Schema or structured table. For example, list_applications should declare: 'Returns { items: [ { name: string, type: string, status: string, description: string, createdBy: string, lastModified: ISO8601 } ], count: integer }'. This enables LLMs to extract fields and chain results.
• Add detailed parameter descriptions with format, constraints, and valid values. Replace 'Application name (default: Vision)' with 'Application name (string, case-sensitive; e.g. Vision, VisionFCCS, VisionPBCS; defaults to Vision if omitted). Call list_applications to discover available names.'
• Add error handling with recovery guidance. Wrap epmFetch calls in try-catch blocks. Return structured error objects: { error: true, code: 'APP_NOT_FOUND', message: 'Application Vision not found', suggestion: 'Try list_applications to see available applications.' }
• Add pagination to list_applications: accept 'limit' (1 - 100, default 20) and 'offset' (default 0) parameters. Return { items: [...], total: N, offset: M, hasMore: boolean }. Update description: 'Returns max 20 applications per call; use offset to fetch additional pages.'
• Add input validation. Define enums or patterns for dimension members in export_data_slice (e.g. scenario ENUM: [Actual, Budget, Forecast]). Validate jobId is numeric in check_job_status. Return actionable error: 'Invalid scenario: got "FakeScenario". Valid values: Actual, Budget, Forecast' instead of raw API error.
• Add dry-run or confirmation for destructive tools. update_substitution_variable should accept 'dryRun=true' parameter that shows the change without applying it. run_business_rule could return an intermediate state asking for confirmation before actually queueing the job.