The Oracle Cloud MCP server has 23 tools with basic JSON Schema definitions and short descriptions. However, it suffers from critical gaps in parameter documentation, missing output schema documentation, and minimal error handling guidance. Parameter descriptions are entirely absent, only type and required status are defined. Tool descriptions are present but generic (averaging ~40 chars), lacking context on WHEN to use each tool and what happens as a result. The server provides no input validation hints, error recovery guidance, or handling for destructive operations like delete_bucket. All tools are read-only or write operations but lack explicit classification in descriptions. Schemas lack minimum/maximum bounds for numeric parameters and do not define output structures. The implementation does not demonstrate the 54 Agentic Tool Patterns baseline (e.g., no recovery guides, no dependency hints, no batch variants). Naming is clear and verb-based (list_, get_, create_, delete_), which is positive, but the lack of parameter documentation means LLMs cannot safely infer what values to pass.
Tools (23)
oci_adb_getread onlyauthsource verified53/100
Get details of an Autonomous Database instance
oci_adb_listread onlyauthsource verified53/100
List Autonomous Database instances in a compartment
CRITICAL: Zero parameter documentation. All 23 tools define parameter types but include NO descriptions of what each parameter means, when to use it, or what values are valid. E.g., 'limit' appears in 15 tools with no explanation of its range or default behavior.
CRITICAL: No output schema documentation. Implementation handlers return structured objects (id, displayName, lifecycleState, etc.), but tool definitions do NOT document these output fields. LLMs cannot plan downstream calls or extract the correct data.
Add a description to EVERY input parameter. Use the format: 'The [name] of the resource (e.g., us-chicago-1). Required if [condition], defaults to [value].' Current schemas have zero parameter descriptions.
Document output schemas for all 23 tools. Specify which fields are returned and their types. E.g., 'Returns an array of instances with fields: id (string), displayName (string), lifecycleState (string), shape (string).'
Expand all tool descriptions to 100-200 characters, following the pattern: '[Action] [resource] [where/how]. Use this to [use case]. Returns [key fields].' E.g., 'List all compute instances in a compartment. Use this to discover available VMs before connecting or scaling. Returns id, displayName, shape, lifecycleState.'
Add validation constraints in parameter descriptions: 'limit (integer, 1-100, default 50)' instead of just 'limit (number, default 50)'. Document enums: 'action (string): START, power on the instance; STOP, power off; RESET, force restart; SOFTSTOP, graceful shutdown; SOFTRESET, graceful restart.'
Add tool annotations: mark read-only tools with readOnlyHint=true (e.g., all oci_*_list_* and oci_*_get_* tools). Mark destructive tools with destructiveHint=true (oci_os_delete_bucket, oci_compute_instance_action with STOP/RESET). Mark idempotent operations with idempotentHint=true.
Implement a dry-run or confirmation pattern for oci_os_delete_bucket and other WRITE/DESTRUCTIVE operations. Add a 'dry_run' boolean parameter, or return a confirmation token that must be passed in a separate confirm_delete_bucket tool.
HIGH: Destructive tool (oci_os_delete_bucket) lacks confirmation mechanism and error guidance. Description is only 34 chars ('Delete an object storage bucket'). No recovery guide if the bucket delete fails. No warning that this is irreversible.
HIGH: Generic, minimal tool descriptions (average 40 chars). None exceed 60 characters. Descriptions like 'List compute instances in a compartment' do not explain WHEN to call this tool, what distinguishes it from similar tools, or what data structure it returns. LLMs cannot make confident selection decisions.
HIGH: No input validation or constraint documentation. Parameters like 'limit' (which default to 50 or 100) have no documented min/max bounds. Parameters like 'action' in oci_compute_instance_action define an enum but the description does not explain what each action does or when to use it.
MEDIUM: No error recovery guidance. Source code shows error handling (e.g., 'Failed to initialize OCI clients'), but tool definitions provide no guidance for LLMs on how to recover, what to try next, or whether errors are retryable.
MEDIUM: Tool annotations missing. None of the 23 tools are marked with readOnlyHint, destructiveHint, or idempotentHint. This makes it harder for agents to reason about safety and retry semantics. E.g., oci_os_delete_bucket should have destructiveHint=true.
MEDIUM: No dependency hints or multi-step guidance. Many workflows require calling list_buckets before put_object, or list_compartments before list_instances. Tool descriptions do not guide LLMs through these dependencies.
MEDIUM: Required parameter 'availability_domain' in oci_bv_list_boot_volumes is not optional despite 'compartment_id' being optional. No description explains the relationship or why this parameter is required while others are not.
LOW: Parameter naming inconsistency. Some tools use 'compartment_id', others use 'bucket_name' or 'instance_id'. While these are domain-sensible, there is no pattern explanation in descriptions for when to use which identifier type.
Add error recovery guidance to tool descriptions. E.g., 'If the compartment_id is invalid, call oci_iam_list_compartments to find the correct ID.' Document which errors are retryable (e.g., transient API failures) vs which require user action.
Document parameter dependencies. E.g., in oci_bv_list_boot_volumes, explain that availability_domain is required because boot volumes are tied to specific zones, whereas block volumes may span an availability domain.
Add batch variants for tools that are often called in loops. E.g., instead of separate calls to get_instance for each instance ID, offer a batch_get_instances tool accepting an array of instance IDs.
Include example outputs (in comments, not descriptions) showing what the LLM can expect to receive and chain forward. E.g., 'oci_compute_list_instances returns instance IDs suitable for oci_compute_get_instance and oci_compute_instance_action.'
Add capability for natural identifiers (display names, IDs, or both). Current tools accept only IDs. Allow 'display_name' parameters as alternatives, or add a 'search_by' enum parameter.
Document that compartment_id defaults to the TENANCY_OCID when omitted, and explain what this means for tool scoping.