MCP server for Oracle Identity Cloud Service (IDCS) integration, providing tools to manage users, applications, OAuth configuration, and audit events
The IDCS MCP server exhibits pervasive gaps in definition quality across all 10 tools. Naming conventions are inconsistent and sometimes misleading (e.g., 'get_clientId_getClientSecret' violates verb_noun pattern and contains 'and'). Descriptions exist but are often vague or incomplete, most lack context about prerequisites, when to use them, or what they return. Input schemas are present but parameters frequently lack descriptions (critical tools like 'get_sso_audit_events' have minimal param documentation). Output schemas are completely undocumented, LLMs cannot predict what these tools return. Error handling is primitive (string errors with no recovery guidance). Security is a major concern: client_secret is hardcoded in source code, credentials are not properly protected, and there is no audit trail capability. Tool composition is poor: 'create_user' and 'create_app' are complex multi-parameter operations with many undescribed fields. The server reads like a POC, not production-ready tooling.
Add two numbers together.
Attach a Sign-On Policy (with dynamic rule & policy names) to an App via SCIM Bulk API.
Create an OAuth application using a Postman-style template.
Create a user using a Postman-style template.
Fetch OAuth2 access token and store it in memory (instead of .env).
Get information of client ID and Client Secret from idcs-60a843b60b554e459d385c21af0589a6.identity.oraclecloud.com.
Critical naming violation: 'get_clientId_getClientSecret' contains 'and' pattern combining two responsibilities and uses non-standard camelCase within verb_noun structure. Should be split into 'get_client_id' and 'get_client_secret' (or kept as single resource lookup if both always returned together).
Client secret hardcoded in source code (src/server.py line: client_secret = 'idcscs-69478cb9-a1d8-4441-b6db-0e0b392134fe'). Secrets must never appear in source or tool parameters. Use environment variables and server-side secret injection.
No output schema documentation for any tool. LLMs cannot predict return types or plan downstream tool calls. Tools return raw strings (e.g., 'get_users' returns response.text directly) or unstructured error messages. Implement structured return types with documented schemas.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 44 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 41 | - | v1 |
Get information about this MCP server.
Fetches all users from Oracle IDCS using the access token from .env
Fetches all users from Oracle IDCS using the access token from .env
Greet a person by name.
Minimal parameter descriptions. Tools like 'get_sso_audit_events' have parameter 'filter' described only as 'Filter string for audit events query', does not specify format, valid operators, or example patterns. LLMs will guess.
Complex tools like 'create_app' expose 10 parameters (tenant, displayName, description, clientType, isOAuthClient, allowedGrants, redirectUris, logoutUri, postLogoutRedirectUris, isActive) but most lack validation rules or constraints. No enum for clientType or isOAuthClient. No range/length constraints. LLMs will pass invalid values.
Error handling returns raw exception strings or HTTP status codes with no recovery guidance. Example from 'get_users': 'Failed to fetch users: {response.status_code} {response.text}', does not tell LLM what to do next. No categorization of retryable vs fatal errors.
No pagination support for list-like tools. 'get_users' and 'get_sso_audit_events' lack limit, offset, or page_size parameters and do not document whether they return all results or cap at a limit. If IDCS returns 10,000 users, response will explode context window.
Irreversible operations ('create_user', 'create_app', 'attach_signon_policy') lack dry-run, confirmation, or idempotency hints. Agents cannot safely test these tools and risk creating duplicate resources on retry.
Tool descriptions do not indicate state mutation. 'get_access_token' mutates global state (ACCESS_TOKEN_MEMORY) but does not document this in the description. Agents need to know which calls are safe to retry.
No audit logging or permission gates. Tools that create users and applications have no logging of who called them, no permission checks, and no audit trail. Critical for compliance and security.
Template-based operations ('create_user', 'create_app') reference external template files (load_template) not visible in source. If templates are missing or malformed, tool fails with cryptic FileNotFoundError. No in-code schema definition or fallback.