Loading ToolBench
Model Context Protocol server for Oracle Cloud Infrastructure — live resource discovery, dependency mapping, and Terraform generation, with security modes and access-control flags.
The server defines 8 tools with moderate-to-good naming conventions and descriptions. All tools follow verb_noun patterns (list_, search_, get_, generate_, build_) and descriptions are present and substantive (ranging 70-290 chars). However, significant gaps remain: (1) Output schemas are entirely undocumented, no structured response definitions are visible in the source, (2) Parameter descriptions lack granularity and formatting constraints, (3) Error handling is generic (catch-all in server.ts that returns text), (4) No pagination/result limits documented for discovery tools that could return large datasets. Tools are logically decomposed (separate discovery, terraform, and graph operations) with clear single responsibilities. Input schemas are present and mostly complete with required/optional flags, but lack enum constraints for resource types and search modes.
Discover a compartment's resources and return a node/edge dependency graph plus a suggested provisioning order (dependencies first).
Discover every resource in a compartment and emit a Terraform module (provider variables + one block per resource) to reproduce it. Unrecognised types become annotated skeletons.
Generate a Terraform (HCL) resource block for a single OCI resource by type and OCID. Fetches the resource's attributes and maps them to the matching oci_* resource.
Fetch detailed attributes for a resource by type and OCID. Known types (Vcn, Subnet, Instance) return full attributes; others return the identifier. Secrets are redacted.
Enumerate every resource in a compartment (via Resource Search).
Output schemas completely undocumented. No response field definitions, types, or examples visible for any tool. LLMs cannot infer what fields to expect or plan downstream operations.
search_resources accepts 'freeText' boolean but lacks enum for query mode or documentation of structured query syntax. Parameter description says 'structured query (e.g. ...) or free text' but doesn't clarify how freeText flag changes parsing behavior or what syntax is valid.
get_resource 'resourceType' parameter accepts arbitrary strings with no enum. Description lists examples ('Vcn, Subnet, Instance') but doesn't limit valid values. LLMs will hallucinate unsupported types.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 59 | 2026-07-28+ | v2 |
List compartments in the tenancy (recursively). Compartments outside the allowlist are filtered out.
List the regions this tenancy is subscribed to.
Search tenancy resources using OCI Resource Search. Provide either a structured query (e.g. "query instance resources where displayName =~ 'prod'") or free text.
No pagination/result limits documented for list_* and search_* tools. These can return large datasets from OCI tenancies (thousands of resources). No mention of limit parameter, offset, page size, or result capping. Large responses will exhaust context windows.
Error handling is generic and non-actionable. src/server.ts catches all errors and returns plain text. No recovery guidance, error classification (retryable vs user-fixable), or suggestion of alternative tools. 'Policy denied: ...' tells agent nothing about what to try next.
Parameter descriptions lack formatting constraints and validation rules. E.g., compartmentId and ocid are described as 'Compartment OCID' and 'The resource OCID' but don't specify format (e.g., 'Must be a valid OCI OCID string starting with ocid1.') or what happens if invalid. No minLength, pattern, or examples.
get_resource description states 'Known types (Vcn, Subnet, Instance) return full attributes; others return the identifier' and 'Secrets are redacted' but no parameter constraints document which resource types are supported or what fields are returned for each. LLM cannot plan downstream steps with confidence.
generate_compartment_terraform description states unrecognized types become 'annotated skeletons' but doesn't document the skeleton format or what fields are included. Output schema is completely absent.
No documentation of tool chaining. If list_compartment_resources returns resource OCIDs, can LLM pass them directly to get_resource? Are field names consistent? If get_resource returns a 'resourceType' field, does generate_terraform accept that exact string? Missing chaining IDs or mismatched field names force discovery detours.