wso2 · lasanthaS · Jul 13, 2026 · Jul 9, 2026 · Jul 9, 2026 · Jul 9, 2026
@@ -29,6 +29,7 @@ Base URLs:
 - [Get a theme asset](organization-content.md#get-a-theme-asset)
 - [Apply a theme](organization-content.md#apply-a-theme)
 - [Reset theme to defaults](organization-content.md#reset-theme-to-defaults)
+- [Download the current theme](organization-content.md#download-the-current-theme)
 
 ### [APIs](apis.md)
 

@@ -48,11 +48,11 @@ This operation requires <strong>Basic Auth</strong> authentication.
 
 |Name|In|Type|Required|Description|
 |---|---|---|---|---|
-|body|body|object|true|API metadata upload. Send either `artifact`, or `api` with `apiDefinition`, or `apiMetadata` with `apiDefinition`. `schemaDefinition` is used for MCP APIs and GraphQL schema updates.|
+|body|body|object|true|API metadata upload. Send either `artifact`, or `api` with `apiDefinition`, or `apiMetadata` with `apiDefinition`. `schemaDefinition` carries a GraphQL SDL schema. (MCP servers are created via `/mcp-servers` with the dedicated `McpServerMultipartBody`, not this body.)|
 |» api|body|string(binary)|false|API metadata YAML file.|
 |» apiDefinition|body|string(binary)|false|API definition file.|
 |» artifact|body|string(binary)|false|Full API ZIP artifact containing metadata and definition files.|
-|» schemaDefinition|body|string(binary)|false|Schema definition file, used by MCP APIs.|
+|» schemaDefinition|body|string(binary)|false|GraphQL SDL schema definition file.|
 |» apiMetadata|body|string|false|JSON string accepted by the service when the `api` YAML file is not supplied. Accepted top-level fields: `name`, `version`, `description`, `type`, `agentVisibility`, `status`, `referenceId`, `id`, `tags`, `labels`, `owners`, `endPoints` (productionURL, sandboxURL), and `subscriptionPlans` (array of `{ id }` objects — only `id` is read; the plan must already exist in the organization). `id` becomes the API's stored handle; when the API is created from a YAML artifact instead, the handle is always taken from `metadata.name`.|
 
 > Example responses
@@ -594,11 +594,11 @@ This operation requires <strong>Basic Auth</strong> authentication.
 
 |Name|In|Type|Required|Description|
 |---|---|---|---|---|
-|body|body|object|true|API metadata upload. Send either `artifact`, or `api` with `apiDefinition`, or `apiMetadata` with `apiDefinition`. `schemaDefinition` is used for MCP APIs and GraphQL schema updates.|
+|body|body|object|true|API metadata upload. Send either `artifact`, or `api` with `apiDefinition`, or `apiMetadata` with `apiDefinition`. `schemaDefinition` carries a GraphQL SDL schema. (MCP servers are created via `/mcp-servers` with the dedicated `McpServerMultipartBody`, not this body.)|
 |» api|body|string(binary)|false|API metadata YAML file.|
 |» apiDefinition|body|string(binary)|false|API definition file.|
 |» artifact|body|string(binary)|false|Full API ZIP artifact containing metadata and definition files.|
-|» schemaDefinition|body|string(binary)|false|Schema definition file, used by MCP APIs.|
+|» schemaDefinition|body|string(binary)|false|GraphQL SDL schema definition file.|
 |» apiMetadata|body|string|false|JSON string accepted by the service when the `api` YAML file is not supplied. Accepted top-level fields: `name`, `version`, `description`, `type`, `agentVisibility`, `status`, `referenceId`, `id`, `tags`, `labels`, `owners`, `endPoints` (productionURL, sandboxURL), and `subscriptionPlans` (array of `{ id }` objects — only `id` is read; the plan must already exist in the organization). `id` becomes the API's stored handle; when the API is created from a YAML artifact instead, the handle is always taken from `metadata.name`.|
 |apiId|path|string|true|The API's handle (unique per org). Resolves only to REST/SOAP/WS/WebSub/GraphQL APIs — MCP servers are addressed via `/mcp-servers`.|
 

@@ -19,20 +19,19 @@ curl -X POST https://localhost:3000/api/v0.9/mcp-servers \
 
 ```
 
-Creates Developer Portal MCP server metadata. Mirrors `POST /api/v0.9/apis` — same artifact ZIP, YAML (`api.yaml` / `devportal.yaml` / `mcp.yaml`), and `apiMetadata` JSON input formats — but the created record is always typed `MCP`. Via the JSON `apiMetadata` field, `type` must be explicitly `MCP`; an omitted type or any other value is rejected with a 400 (use `POST /api/v0.9/apis` instead).
+Creates Developer Portal MCP server metadata. Accepts the same metadata input formats as `POST /api/v0.9/apis` (artifact ZIP, `api.yaml` / `devportal.yaml` / `mcp.yaml`, or `apiMetadata` JSON), but the created record is always typed `MCP`. An MCP server's contract is its `schemaDefinition` — the tools, resources, and prompts it exposes — not an OpenAPI-style `apiDefinition`; a `schemaDefinition` is required and any `apiDefinition` sent is ignored. Via the JSON `apiMetadata` field, `type` must be explicitly `MCP`; an omitted type or any other value is rejected with a 400 (use `POST /api/v0.9/apis`).
 
 > Payload
 
 ```yaml
 api: string
-apiDefinition: string
 artifact: string
 schemaDefinition: string
-apiMetadata: '{"name":"Weather API","version":"v1","description":"Weather
-  forecast API","type":"REST","agentVisibility":"VISIBLE",
-  "status":"PUBLISHED","tags":["weather"],"labels":["default"],"endPoints":{
-  "productionURL":"https://api.example.com/weather",
-  "sandboxURL":"https://sandbox.example.com/weather"},"subscriptionPlans":[{"id":"Gold"}]}'
+apiMetadata: '{"name":"Travel Assistant MCP","version":"v1","description":"MCP
+  server for travel planning
+  tools","type":"MCP","agentVisibility":"VISIBLE","status":"PUBLISHED",
+  "tags":["mcp"],"labels":["default"],"endPoints":{"productionURL":"https://mcp.example.com",
+  "sandboxURL":"https://mcp.example.com"},"subscriptionPlans":[{"id":"Gold"}]}'
 
 ```
 
@@ -47,12 +46,11 @@ This operation requires <strong>Basic Auth</strong> authentication.
 
 |Name|In|Type|Required|Description|
 |---|---|---|---|---|
-|body|body|object|true|API metadata upload. Send either `artifact`, or `api` with `apiDefinition`, or `apiMetadata` with `apiDefinition`. `schemaDefinition` is used for MCP APIs and GraphQL schema updates.|
-|» api|body|string(binary)|false|API metadata YAML file.|
-|» apiDefinition|body|string(binary)|false|API definition file.|
-|» artifact|body|string(binary)|false|Full API ZIP artifact containing metadata and definition files.|
-|» schemaDefinition|body|string(binary)|false|Schema definition file, used by MCP APIs.|
-|» apiMetadata|body|string|false|JSON string accepted by the service when the `api` YAML file is not supplied. Accepted top-level fields: `name`, `version`, `description`, `type`, `agentVisibility`, `status`, `referenceId`, `id`, `tags`, `labels`, `owners`, `endPoints` (productionURL, sandboxURL), and `subscriptionPlans` (array of `{ id }` objects — only `id` is read; the plan must already exist in the organization). `id` becomes the API's stored handle; when the API is created from a YAML artifact instead, the handle is always taken from `metadata.name`.|
+|body|body|object|true|MCP server upload. Provide the server metadata via `apiMetadata` (JSON), an `api` YAML file, or a full `artifact` ZIP, together with its `schemaDefinition` — the tools, resources, and prompts the server exposes. An MCP server has no OpenAPI-style `apiDefinition`; its `schemaDefinition` IS its contract, so it is required on create (and replaces the stored schema when supplied on update).|
+|» api|body|string(binary)|false|MCP server metadata YAML file (kind MCP).|
+|» artifact|body|string(binary)|false|Full MCP server ZIP artifact containing the metadata and the schemaDefinition.|
+|» schemaDefinition|body|string(binary)|false|MCP tools schema (YAML or JSON) listing the tools, resources, and prompts the server exposes. Required on create; when supplied on update it replaces the stored schema.|
+|» apiMetadata|body|string|false|JSON string accepted when the `api` YAML file is not supplied. Accepted top-level fields: `name`, `version`, `description`, `type` (must be `MCP`), `agentVisibility`, `status`, `referenceId`, `id`, `tags`, `labels`, `owners`, `endPoints` (productionURL, sandboxURL), and `subscriptionPlans` (array of `{ id }` objects — only `id` is read; the plan must already exist in the organization). `id` becomes the MCP server's stored handle.|
 
 > Example responses
 
@@ -561,20 +559,19 @@ curl -X PUT https://localhost:3000/api/v0.9/mcp-servers/{mcpServerId} \
 
 ```
 
-Updates Developer Portal MCP server metadata and its stored definition. Mirrors `PUT /api/v0.9/apis/{apiId}`, including `type` being required and immutable — it must stay `MCP`; any other value is rejected with `400`, via the same resolveTypeOrReject check `POST /mcp-servers` uses.
+Updates Developer Portal MCP server metadata and, when a `schemaDefinition` is supplied, its stored tools schema. `type` is required and immutable — it must stay `MCP`; any other value is rejected with `400` via the same resolveTypeOrReject check `POST /mcp-servers` uses. An MCP server has no `apiDefinition`; any `apiDefinition` sent on update is ignored.
 
 > Payload
 
 ```yaml
 api: string
-apiDefinition: string
 artifact: string
 schemaDefinition: string
-apiMetadata: '{"name":"Weather API","version":"v1","description":"Weather
-  forecast API","type":"REST","agentVisibility":"VISIBLE",
-  "status":"PUBLISHED","tags":["weather"],"labels":["default"],"endPoints":{
-  "productionURL":"https://api.example.com/weather",
-  "sandboxURL":"https://sandbox.example.com/weather"},"subscriptionPlans":[{"id":"Gold"}]}'
+apiMetadata: '{"name":"Travel Assistant MCP","version":"v1","description":"MCP
+  server for travel planning
+  tools","type":"MCP","agentVisibility":"VISIBLE","status":"PUBLISHED",
+  "tags":["mcp"],"labels":["default"],"endPoints":{"productionURL":"https://mcp.example.com",
+  "sandboxURL":"https://mcp.example.com"},"subscriptionPlans":[{"id":"Gold"}]}'
 
 ```
 
@@ -589,12 +586,11 @@ This operation requires <strong>Basic Auth</strong> authentication.
 
 |Name|In|Type|Required|Description|
 |---|---|---|---|---|
-|body|body|object|true|API metadata upload. Send either `artifact`, or `api` with `apiDefinition`, or `apiMetadata` with `apiDefinition`. `schemaDefinition` is used for MCP APIs and GraphQL schema updates.|
-|» api|body|string(binary)|false|API metadata YAML file.|
-|» apiDefinition|body|string(binary)|false|API definition file.|
-|» artifact|body|string(binary)|false|Full API ZIP artifact containing metadata and definition files.|
-|» schemaDefinition|body|string(binary)|false|Schema definition file, used by MCP APIs.|
-|» apiMetadata|body|string|false|JSON string accepted by the service when the `api` YAML file is not supplied. Accepted top-level fields: `name`, `version`, `description`, `type`, `agentVisibility`, `status`, `referenceId`, `id`, `tags`, `labels`, `owners`, `endPoints` (productionURL, sandboxURL), and `subscriptionPlans` (array of `{ id }` objects — only `id` is read; the plan must already exist in the organization). `id` becomes the API's stored handle; when the API is created from a YAML artifact instead, the handle is always taken from `metadata.name`.|
+|body|body|object|true|MCP server upload. Provide the server metadata via `apiMetadata` (JSON), an `api` YAML file, or a full `artifact` ZIP, together with its `schemaDefinition` — the tools, resources, and prompts the server exposes. An MCP server has no OpenAPI-style `apiDefinition`; its `schemaDefinition` IS its contract, so it is required on create (and replaces the stored schema when supplied on update).|
+|» api|body|string(binary)|false|MCP server metadata YAML file (kind MCP).|
+|» artifact|body|string(binary)|false|Full MCP server ZIP artifact containing the metadata and the schemaDefinition.|
+|» schemaDefinition|body|string(binary)|false|MCP tools schema (YAML or JSON) listing the tools, resources, and prompts the server exposes. Required on create; when supplied on update it replaces the stored schema.|
+|» apiMetadata|body|string|false|JSON string accepted when the `api` YAML file is not supplied. Accepted top-level fields: `name`, `version`, `description`, `type` (must be `MCP`), `agentVisibility`, `status`, `referenceId`, `id`, `tags`, `labels`, `owners`, `endPoints` (productionURL, sandboxURL), and `subscriptionPlans` (array of `{ id }` objects — only `id` is read; the plan must already exist in the organization). `id` becomes the MCP server's stored handle.|
 |mcpServerId|path|string|true|The MCP server's handle (unique per org).|
 
 > Example responses

@@ -206,3 +206,67 @@ This operation requires <strong>Basic Auth</strong> authentication.
 |---|---|---|---|
 |204|[No Content](https://tools.ietf.org/html/rfc7231#section-6.3.5)|Theme reset successfully.|None|
 |500|[Internal Server Error](https://tools.ietf.org/html/rfc7231#section-6.6.1)|Internal server error.|[ErrorResponse](schemas.md#schemaerrorresponse)|
+
+## Download the current theme
+
+<a id="opIdexportTheme"></a>
+
+`GET /views/{viewId}/export-theme`
+
+> Code samples
+
+```shell
+
+curl -X GET https://localhost:3000/api/v0.9/views/{viewId}/export-theme \
+  -u {username}:{password} \
+  -H 'Accept: application/zip' \
+  -H 'Authorization: Bearer {access-token}'
+
+```
+
+Bundles the view's current custom theme assets into a single ZIP archive for download. The archive is wrapped in a top-level folder so it can be re-uploaded via the apply-theme endpoint. Returns 404 when the view has no custom theme.
+
+### Authentication
+
+<aside class="warning">
+This operation requires <strong>Basic Auth</strong> authentication.
+
+</aside>
+
+<h3 id="download-the-current-theme-parameters">Parameters</h3>
+
+|Name|In|Type|Required|Description|
+|---|---|---|---|---|
+|viewId|path|string|true|The view's handle (unique per org). Not the internal database uuid.|
+
+> Example responses
+
+> 200 Response
+
+> 404 Response
+
+```json
+{
+  "status": "error",
+  "code": "ORG_NOT_FOUND",
+  "message": "Organization not found."
+}
+```
+
+> 500 Response
+
+```json
+{
+  "status": "error",
+  "code": "INTERNAL_SERVER_ERROR",
+  "message": "An unexpected error occurred."
+}
+```
+
+<h3 id="download-the-current-theme-responses">Responses</h3>
+
+|Status|Meaning|Description|Schema|
+|---|---|---|---|
+|200|[OK](https://tools.ietf.org/html/rfc7231#section-6.3.1)|Theme archive.|string|
+|404|[Not Found](https://tools.ietf.org/html/rfc7231#section-6.5.4)|Resource not found.|[ErrorResponse](schemas.md#schemaerrorresponse)|
+|500|[Internal Server Error](https://tools.ietf.org/html/rfc7231#section-6.6.1)|Internal server error.|[ErrorResponse](schemas.md#schemaerrorresponse)|
@@ -20,13 +20,15 @@ Well-written LLM Instructions reduce agent errors and improve the quality of AI-
 
 ## Configuring LLM Instructions
 
-LLM Instructions are configured at the view level in the portal's admin settings.
+LLM Instructions are configured per view, from the organization's admin settings.
 
 1. Sign in to the Developer Portal as an admin.
-2. Navigate to **Admin Settings** for your view (`/<orgName>/views/<viewName>/admin/settings`).
-3. Select the **LLM Instructions** tab.
-4. Enter your instructions in the text editor.
-5. Click **Publish**.
+2. Navigate to **Settings** (`/<orgName>/settings`).
+3. Select **LLM Instructions** from the sidebar.
+4. If your organization has more than one view, the **View-scoped setting** banner at the top shows which view you're currently editing — use the pill selector to switch views. Each view has its own LLM Instructions.
+5. Use the **Portal is AI-discoverable** toggle to control whether `llms.txt` and the agent-facing content endpoints are served for this view at all. When turned off, those endpoints return `404` to agents — turning it off doesn't just hide the setting, it takes the portal out of agent discovery entirely.
+6. Enter a **Portal name** and **Description** to orient agents.
+7. Click **Publish** — this is always available, even when AI-discoverable is turned off, so you can save that you've intentionally disabled discovery for this view.
 
 Changes take effect immediately — the updated instructions are reflected in `llms.txt` as soon as you save.