zuplo 6.67.32 → 6.68.0

package/docs/articles/manual-mcp-oauth-testing.mdx

@@ -0,0 +1,193 @@
+---
+title: Manual OAuth MCP Testing
+sidebar_label: "Manual OAuth Testing"
+description:
+  Learn how to manually test OAuth flows for MCP servers using curl and OpenSSL
+  when clients don't support full dynamic registration.
+tags:
+  - authentication
+  - testing
+---
+
+MCP client OAuth support is evolving rapidly and many clients don't yet support
+the full flow for dynamic client registration, PKCE, initial tokens during DCR,
+etc.
+
+This guide shows you how you can use common tools like `curl` and `openssl` to
+manually test a configured authorization server and MCP server.
+
+## Existing auth server client ID and secret
+
+The following guide walks you through manually testing an OAuth provider with a
+client ID and secret configuration. This is also useful for debugging OAuth
+issues during authorization flows for MCP.
+
+### Prerequisites
+
+- `curl`, `jq`, and `openssl` installed on your system
+- An OAuth client ID and client Secret. For the purposes of demonstration, this
+  guide uses an Okta Application client ID and secret.
+
+### Testing Script
+
+Create a test script to verify your complete OAuth flow:
+
+```bash
+#!/bin/bash
+
+# OAuth 2.1 flow test Script for MCP with pre-configured client.
+# Based on MCP Authorization specification:
+# https://modelcontextprotocol.io/specification/2025-06-18/basic/authorization
+
+set -e
+
+# !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
+# !!!!!!! Configuration !!!!!!!!
+#
+# Update these values to your MCP server hosted on Zuplo and your auth provider
+# config values.
+
+MCP_ENDPOINT="https://your-gateway.zuplo.dev/mcp"
+CLIENT_ID="your-client-id"
+CLIENT_SECRET="your-client-secret"
+REDIRECT_URI="http://localhost:8080/authorization-code/callback"
+SCOPE="mcp:access"
+
+# !!!!! Configuration end !!!!!!
+# !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
+
+# Colors for pretty output
+RED='\033[0;31m'
+GREEN='\033[0;32m'
+BLUE='\033[0;34m'
+YELLOW='\033[1;33m'
+NC='\033[0m'
+
+echo -e "${BLUE}=== MCP OAuth 2.1 Testing ===${NC}"
+
+# Step 1: Discover OAuth configuration from MCP endpoint
+echo -e "${BLUE}Step 1: Discovering OAuth configuration...${NC}"
+MCP_RESPONSE=$(curl -s -i -X POST "${MCP_ENDPOINT}" \
+  -H 'content-type: application/json' \
+  -d '{"jsonrpc": "2.0", "id": "1", "method": "ping"}')
+
+# Extract resource metadata URL
+RESOURCE_METADATA_URL=$(echo "${MCP_RESPONSE}" | grep -i "resource_metadata=" | \
+  sed 's/.*resource_metadata=\([^[:space:]]*\).*/\1/' | tr -d '\r\n')
+
+echo "Resource metadata URL: ${RESOURCE_METADATA_URL}"
+
+# Step 2: Get authorization server info
+RESOURCE_METADATA=$(curl -s "${RESOURCE_METADATA_URL}")
+AUTH_SERVER_URL=$(echo "${RESOURCE_METADATA}" | jq -r '.authorization_servers[0]')
+
+echo "Authorization Server: ${AUTH_SERVER_URL}"
+
+# Step 3: Get OAuth endpoints
+OAUTH_METADATA=$(curl -s "${AUTH_SERVER_URL}/.well-known/oauth-authorization-server")
+AUTH_ENDPOINT=$(echo "${OAUTH_METADATA}" | jq -r '.authorization_endpoint')
+TOKEN_ENDPOINT=$(echo "${OAUTH_METADATA}" | jq -r '.token_endpoint')
+
+# Step 4: Generate PKCE parameters
+CODE_VERIFIER=$(openssl rand -base64 32 | tr '/+' '_-' | tr -d '=')
+CODE_CHALLENGE=$(echo -n "$CODE_VERIFIER" | openssl dgst -sha256 -binary | openssl base64 | tr '/+' '_-' | tr -d '=')
+STATE=$(openssl rand -hex 16)
+
+# Step 5: Build authorization URL
+AUTH_URL="${AUTH_ENDPOINT}?response_type=code&client_id=${CLIENT_ID}&redirect_uri=${REDIRECT_URI}&scope=${SCOPE}&state=${STATE}&code_challenge=${CODE_CHALLENGE}&code_challenge_method=S256"
+
+echo -e "${YELLOW}Open this URL in your browser:${NC}"
+echo "${AUTH_URL}"
+echo
+echo -e "${YELLOW}After login, copy the authorization code from the callback URL${NC}"
+read -p "Enter the authorization code: " AUTH_CODE
+
+# Step 6: Exchange code for token
+TOKEN_RESPONSE=$(curl -s -X POST "${TOKEN_ENDPOINT}" \
+  -H "Content-Type: application/x-www-form-urlencoded" \
+  -u "${CLIENT_ID}:${CLIENT_SECRET}" \
+  -d "grant_type=authorization_code&code=${AUTH_CODE}&redirect_uri=${REDIRECT_URI}&code_verifier=${CODE_VERIFIER}")
+
+ACCESS_TOKEN=$(echo "${TOKEN_RESPONSE}" | jq -r '.access_token')
+
+if [[ "$ACCESS_TOKEN" == "null" ]]; then
+    echo -e "${RED}Token exchange failed:${NC}"
+    echo "${TOKEN_RESPONSE}" | jq .
+    exit 1
+fi
+
+echo -e "${GREEN}✓ Access token obtained${NC}"
+
+# Step 7: Test MCP endpoint with token
+MCP_AUTH_RESPONSE=$(curl -s -X POST "${MCP_ENDPOINT}" \
+  -H "Authorization: Bearer ${ACCESS_TOKEN}" \
+  -H 'Accept: application/json, text/event-stream' \
+  -d '{"jsonrpc": "2.0", "id": "1", "method": "ping"}')
+
+echo -e "${GREEN}✓ MCP ping test:${NC}"
+echo "${MCP_AUTH_RESPONSE}" | jq .
+
+echo -e "${GREEN}=== OAuth flow test complete ===${NC}"
+```
+
+### Running the Test
+
+1. **Update the configuration** at the top of the script with your values:
+   - `MCP_ENDPOINT`: Your Zuplo gateway MCP endpoint
+   - `CLIENT_ID`: The ID of the client or application for the auth server
+   - `CLIENT_SECRET`: The secret for the client or application for the auth
+     server
+   - `REDIRECT_URI`: Typically, must match exactly what's configured in your
+     auth server's redirect
+
+2. **Make the script executable**: `chmod +x test-oauth.sh`
+
+3. **Run the script**: `./test-oauth.sh`
+
+4. **Follow the prompts**:
+   - Open the authorization URL in your browser from the terminal output
+   - Complete the login flow
+   - Copy the authorization code from the callback URL. It will look something
+     like:
+
+   ```
+   http://localhost:8080/authorization-code/callback?code=ABC123&state=XYZ987
+   ```
+
+   - Paste just the code part into the script
+
+   :::warning
+
+   This script does **not** include a web server and does **not** support
+   dynamically extracting the authorization callback code. You must manually
+   grab the code from the query parameter and enter it into the terminal prompt.
+
+   :::
+
+### Common Issues and Troubleshooting
+
+**"Policy evaluation failed"**: Check that your client has:
+
+- Correct redirect URI configured
+- Correct scope assigned and configured
+- Authorization code grant enabled
+- Proper access policies and rules
+
+**"Invalid client" errors**: Verify your Client ID and Client Secret are
+correct.
+
+**"Invalid redirect URI"**: The redirect URI configured in the script may need
+to exactly match what's configured in your authorization server and client.
+
+**Browser redirects immediately without login**: You may already be logged into
+your auth provider or an existing session exists. To log in from a clean state,
+try the following:
+
+- Log out from your authorization provider
+- Clear browser cookies, sessions, and caches
+- Using an incognito/private browser window
+
+**Token exchange fails**: Check that:
+
+- PKCE is enabled for your client
+- The authorization code hasn't expired (use it immediately)

package/docs/articles/mcp-quickstart.mdx

@@ -0,0 +1,135 @@
+---
+title: MCP - Quick Start Guide
+sidebar_label: "MCP - Quick start"
+---
+
+Zuplo allows you to instantly add a managed MCP Server to your existing API,
+powered by OpenAPI.
+
+If you're not familiar with Zuplo, it's recommended to go through the
+[Step 1](./step-1-setup-basic-gateway.mdx) first.
+
+<Stepper>
+
+1. Create a **new project**
+
+   Sign in to [portal.zuplo.com](https://portal.zuplo.com) and create a new
+   project.
+
+1. **Import** an **OpenAPI** document
+
+   Let's import an OpenAPI document. You can download this one here
+   [todo-openapi.json](https://download-open-api-main-fae215f.d2.zuplo.dev/todo-openapi).
+
+   ![Import OpenAPI](../../public/media/mcp-quickstart/import-openapi.png)
+
+   Select the **Code** tab (1), then choose the `routes.oas.json` file (2) and
+   choose **Import OpenAPI** (3).
+
+   <ModalScreenshot size="sm">
+
+   ![Complete Import](../../public/media/mcp-quickstart/complete-import.png)
+
+   </ModalScreenshot>
+
+   Click **Complete Import** to import the routes.
+
+   Now save your changes (press **Save** at bottom left of **CMD+S**).
+
+1. Test the **Get all todos** route
+
+   The first route you imported is called `Get all todos`. Select it and click
+   the **Test** button next to the **Path** field.
+
+   A test dialog will open, click **Test** and you should see a `200 OK`
+   response with a few todos.
+
+   This is the basic API we're going to turn into a fully functioning MCP
+   Server.
+
+1. Create an **MCP Server**
+
+   On your `routes.oas.json` file, choose **Add** and then **MCP Server** (3)
+
+   ![Add Route](../../public/media/mcp-quickstart/add-mcp-route.png)
+
+   A new route will appear. Confirm the following values:
+   - **Summary**: enter `MCP Server`
+   - **Method**: choose `POST`
+   - **Path**: enter `/mcp` (the path can be anything, but /mcp is common)
+
+   Click the **Select Tools** option for your new MCP Server endpoint (1).
+
+   ![Select Tools](../../public/media/mcp-quickstart/select-mcp-tools.png)
+
+   You should see the MCP tools dialog. Check the tools from your `*.oas.json`
+   files, that you want to surface in your MCP Server.
+
+   ![MCP Server](../../public/media/mcp-quickstart/mcp-tools-dialog.png)
+
+   Click **Update Tools** (1)
+
+   Now click Save at the bottom left. Congratulations, you just published your
+   first MCP Server!
+
+1. Connect your MCP Client
+
+   You can use any MCP client you like. We like the OpenAPI platform's
+   playground.
+
+   Go to
+   [platform.openai.com/playground](https://platform.openai.com/playground)
+   (you'll need an OpenAPI account).
+
+   ![Add tool](../../public/media/mcp-quickstart/openai-add-tool.png)
+
+   Click `Create...` next to the **Tools** label and choose **MCP Server**.
+
+   Click **Add new** to register your custom MCP Server with the playground.
+
+   You'll need the URL of your MCP server - you can get this by going back to
+   Zuplo, clicking on your MCP Server route and then clicking **Test**. At the
+   top you'll see a button to copy the URL to your clipboard.
+
+   ![Copy MCP Server URL](../../public/media/mcp-quickstart/copy-mcp-server-url.png)
+
+   Back to the OpenAPI playground...
+
+   <ModalScreenshot size="sm">
+
+   ![Connect MCP Server](../../public/media/mcp-quickstart/connect-mcp-server.png)
+
+   </ModalScreenshot>
+
+1. Enter the URL of your MCP Server
+1. Enter a label, try `todos`
+1. Choose **None** for Authentication as we didn't add auth to our API
+1. Click **Connect**
+
+   If successfully connected, you'll see your 'tools' listed in the playground.
+
+   <ModalScreenshot size="sm">
+
+   ![Add tools](../../public/media/mcp-quickstart/add-tools.png)
+
+   </ModalScreenshot>
+
+   No need to deselect any tools, let's add them all!
+
+1. Test your MCP Server via the playground
+
+   Let's prompt the LLM in the playground. Ask the model to
+
+   `list out all the todos`
+
+   The model should recognize that it needs to call the todos MCP Server and
+   will ask for your approval.
+
+   Click **Approve** and you should see the todos listed 👏
+
+   ![The prompt](../../public/media/mcp-quickstart/the-prompt.png)
+
+</Stepper>
+
+Congratulations! Now go read more about the
+[MCP Server handler](/docs/handlers/mcp-server).

package/docs/articles/metrics-plugins.mdx

@@ -0,0 +1,371 @@
+---
+title: Metrics Plugins
+---
+
+An essential part of any application is the ability to continuously monitor its
+performance in production to detect any issues. Zuplo provides support for
+sending metrics to a variety of services. If you want your logs to be sent to
+your metrics service, you can enable one of Zuplo's logging plugins. Currently,
+Zuplo supports logging to the following sources:
+
+- Datadog
+- Dynatrace
+- New Relic
+- OpenTelemetry
+
+If you would like to log to a different source, reach out to support@zuplo.com
+and we'd be happy to work with you to add a new logging plugin.
+
+To configure your logging, you must create a `zuplo.runtime.ts` file in the
+`modules`. The examples below show the content of the file with each of the
+different logging plugins.
+
+<EnterpriseFeature name="Custom metrics" />
+
+## Metrics
+
+Zuplo supports the following metrics:
+
+- request latency
+  - This measures the total time (in milliseconds) that a request takes once it
+    has entered the API Gateway. It includes any outbound calls from the
+    gateway.
+- request content length
+  - The content length of the request as reported by the content-length header.
+    May be omitted if the content-length header isn't present.
+- response content length.
+  - The content length of the response as reported by the content-length header.
+    May be omitted if the content-length header isn't present.
+
+## Plugins
+
+Below, you will find details on each metrics plugin.
+
+### Datadog
+
+By default, we send all metrics to Datadog. However, you have the option below
+to configure which metrics you want to send.
+
+Due to the pricing model of Datadog, we recommend being thrifty with what's
+being sent. Refer to
+[counting custom metrics](https://docs.Datadoghq.com/account_management/billing/custom_metrics/?tab=countrate#counting-custom-metrics)
+for more information. In general, try to avoid high-dimensionality/cardinality
+tags since those are counted as separate metrics. This
+[article by Datadog](https://www.Datadoghq.com/blog/the-power-of-tagged-metrics/)
+has some good guidelines.
+
+:::warning{title="Metrics Aggregation"}
+
+Your Zuplo API can be deployed to many edge locations. Each location will send
+metrics to Datadog independently. For low volume APIs this may be okay, but
+typically you will want to aggregate metrics before sending to Datadog. You can
+use a tool like the
+[OpenTelemetry Collector](https://opentelemetry.io/docs/collector/) for the
+aggregation.
+
+:::
+
+```ts
+import {
+  RuntimeExtensions,
+  DatadogMetricsPlugin,
+  environment,
+} from "@zuplo/runtime";
+
+export function runtimeInit(runtime: RuntimeExtensions) {
+  runtime.addPlugin(
+    new DatadogMetricsPlugin({
+      apiKey: environment.Datadog_API_KEY,
+      // You can add what tags you want.
+      // See https://docs.Datadoghq.com/tagging/#defining-tags for more information
+      tags: [
+        "app:my-service-name",
+        `environment:${environment.ENVIRONMENT ?? "DEVELOPMENT"}`,
+      ],
+      metrics: {
+        latency: true,
+        requestContentLength: true,
+        responseContentLength: true,
+      },
+      // You can also choose to add additional tags to include in the metrics.
+      // Be mindful of what other information you wish to include since it will incur costs on your cardinality
+      include: {
+        country: false,
+        httpMethod: false,
+        statusCode: false,
+      },
+    }),
+  );
+}
+```
+
+The above configuration applies globally for all metrics send to Datadog. If you
+wish to dynamically configure information for a particular ZuploContext, you can
+use the `DatadogMetricsPlugin` in your code. Currently, the only configuration
+you can set is the tags. The values you set here will be appended to those set
+globally in the `zuplo.runtime.ts` file.
+
+```ts
+import {
+  ZuploContext,
+  ZuploRequest,
+  DatadogMetricsPlugin,
+} from "@zuplo/runtime";
+
+export default async function (request: ZuploRequest, context: ZuploContext) {
+  const someValue = "hello";
+  DatadogMetricsPlugin.setContext(context, {
+    tags: [`my-custom-tag:${someValue}`],
+  });
+
+  return "What zup?";
+}
+```
+
+### Dynatrace
+
+By default, we send all metrics to Dynatrace. However, you have the option below
+to configure which metrics you want to send.
+
+:::warning{title="Strict format"}
+
+Dynatrace has a strict format for its payload, which has some _surprising_
+requirements.
+
+From
+https://docs.dynatrace.com/docs/extend-dynatrace/extend-metrics/reference/metric-ingestion-protocol#dimension
+
+> Allowed characters for the key are lowercase letters, numbers, hyphens (-),
+> periods (.), and underscores (\_). Special letters (like ö) aren't allowed.
+
+The _surprising_ part is that uppercase characters are **not** allowed.
+
+Do be mindful when you are crafting your own dimensions since an invalid
+property will cause the entire payload to be rejected.
+
+:::
+
+```ts
+import {
+  RuntimeExtensions,
+  DynatraceMetricsPlugin,
+  environment,
+} from "@zuplo/runtime";
+
+export function runtimeInit(runtime: RuntimeExtensions) {
+  runtime.addPlugin(
+    new DynatraceMetricsPlugin({
+      // You can find the documentation on how to get your URL at
+      // https://www.dynatrace.com/support/help/dynatrace-api/environment-api/metric-v2/post-ingest-metrics#example
+      url: "https://demo.live.dynatrace.com/api/v2/metrics/ingest",
+      apiToken: environment.DYNATRACE_API_TOKEN,
+      // Dimensions should conform to Dynatrace ingest protocol
+      // See https://www.dynatrace.com/support/help/extend-dynatrace/extend-metrics/reference/metric-ingestion-protocol
+      dimensions: [
+        'app="my-service-name"',
+        `environment="${environment.ENVIRONMENT ?? "DEVELOPMENT"}"`,
+      ],
+      metrics: {
+        latency: true,
+        requestContentLength: true,
+        responseContentLength: true,
+      },
+      // You can also choose to add additional tags to include in the metrics.
+      include: {
+        country: false,
+        method: false,
+        statusCode: false,
+      },
+    }),
+  );
+}
+```
+
+The above configuration applies globally for all metrics send to Dynatrace. If
+you wish to dynamically configure information for a particular ZuploContext, you
+can use the `DynatraceMetricsPlugin` in your code. Currently, the only
+configuration you can set is the dimensions. The values you set here will be
+appended to those set globally in the `zuplo.runtime.ts` file.
+
+```ts
+import {
+  ZuploContext,
+  ZuploRequest,
+  DynatraceMetricsPlugin,
+} from "@zuplo/runtime";
+
+export default async function (request: ZuploRequest, context: ZuploContext) {
+  const someValue = "hello";
+  DynatraceMetricsPlugin.setContext(context, {
+    dimentions: [`my-custom-dimension="${someValue}"`],
+  });
+
+  return "What zup?";
+}
+```
+
+### New Relic
+
+By default, we send all metrics to New Relic. However, you have the option below
+to configure which metrics you want to send.
+
+New Relic's Metric API provides a powerful way to monitor your API's
+performance. The metrics are sent to New Relic's Metric API endpoint
+(https://metric-api.newrelic.com/metric/v1) by default, but you can customize
+this if needed.
+
+```ts
+import {
+  RuntimeExtensions,
+  NewRelicMetricsPlugin,
+  environment,
+} from "@zuplo/runtime";
+
+export function runtimeInit(runtime: RuntimeExtensions) {
+  runtime.addPlugin(
+    new NewRelicMetricsPlugin({
+      apiKey: environment.NEW_RELIC_API_KEY,
+      // Optional: customize the URL if needed
+      // url: "https://metric-api.newrelic.com/metric/v1",
+      // You can add custom attributes to all metrics
+      attributes: {
+        service: "my-service-name",
+        environment: environment.ENVIRONMENT ?? "DEVELOPMENT",
+      },
+      metrics: {
+        latency: true,
+        requestContentLength: true,
+        responseContentLength: true,
+      },
+      // You can also choose to add additional attributes to include in the metrics
+      include: {
+        country: false,
+        httpMethod: false,
+        statusCode: false,
+        path: false,
+      },
+    }),
+  );
+}
+```
+
+The above configuration applies globally for all metrics sent to New Relic. If
+you wish to dynamically configure information for a particular ZuploContext, you
+can use the `NewRelicMetricsPlugin` in your code. Currently, the only
+configuration you can set is the attributes. The values you set here will be
+appended to those set globally in the `zuplo.runtime.ts` file.
+
+```ts
+import {
+  ZuploContext,
+  ZuploRequest,
+  NewRelicMetricsPlugin,
+} from "@zuplo/runtime";
+
+export default async function (request: ZuploRequest, context: ZuploContext) {
+  const someValue = "hello";
+  NewRelicMetricsPlugin.setContext(context, {
+    attributes: { "my-custom-attribute": someValue },
+  });
+
+  return "What zup?";
+}
+```
+
+:::warning{title="Metrics Aggregation"}
+
+Your Zuplo API can be deployed to many edge locations. Each location will send
+metrics to New Relic independently. For low volume APIs this may be okay, but
+typically you will want to aggregate metrics before sending to New Relic. You
+can use a tool like the
+[OpenTelemetry Collector](https://opentelemetry.io/docs/collector/) for the
+aggregation.
+
+:::
+
+### OpenTelemetry
+
+The OpenTelemetry metrics plugin sends metrics to any OpenTelemetry-compatible
+collector using the
+[OTLP HTTP JSON format](https://opentelemetry.io/docs/specs/otlp/#json-protobuf-encoding).
+This allows you to integrate with a wide variety of observability backends that
+support OpenTelemetry, including Grafana, Jaeger, Honeycomb, and many others.
+
+By default, we send all metrics to your OpenTelemetry collector. However, you
+have the option below to configure which metrics you want to send.
+
+```ts
+import {
+  RuntimeExtensions,
+  OTelMetricsPlugin,
+  environment,
+} from "@zuplo/runtime";
+
+export function runtimeInit(runtime: RuntimeExtensions) {
+  runtime.addPlugin(
+    new OTelMetricsPlugin({
+      // The OTLP HTTP endpoint URL for your collector
+      url: "https://otel-collector.example.com:4318/v1/metrics",
+      // Optional headers for authentication
+      headers: {
+        Authorization: `Bearer ${environment.OTEL_API_KEY}`,
+      },
+      // Resource attributes to include with all metrics
+      attributes: {
+        "service.name": "my-api",
+        "deployment.environment": environment.ENVIRONMENT ?? "development",
+      },
+      metrics: {
+        latency: true,
+        requestContentLength: true,
+        responseContentLength: true,
+      },
+      // You can also choose to add additional attributes to include in the metrics
+      include: {
+        country: false,
+        httpMethod: false,
+        statusCode: false,
+        path: false,
+      },
+    }),
+  );
+}
+```
+
+The plugin uses
+[OpenTelemetry semantic conventions](https://opentelemetry.io/docs/specs/semconv/)
+for metric names and attributes:
+
+| Metric                  | Name                             | Unit |
+| ----------------------- | -------------------------------- | ---- |
+| Request latency         | `http.server.request.duration`   | ms   |
+| Request content length  | `http.server.request.body.size`  | By   |
+| Response content length | `http.server.response.body.size` | By   |
+
+When `include` options are enabled, the following attributes are added:
+
+| Option       | Attribute                     |
+| ------------ | ----------------------------- |
+| `country`    | `client.geo.country_iso_code` |
+| `httpMethod` | `http.request.method`         |
+| `statusCode` | `http.response.status_code`   |
+| `path`       | `http.route`                  |
+
+The above configuration applies globally for all metrics sent to your
+OpenTelemetry collector. If you wish to dynamically configure information for a
+particular ZuploContext, you can use the `OTelMetricsPlugin` in your code.
+Currently, the only configuration you can set is the attributes. The values you
+set here will be appended to those set globally in the `zuplo.runtime.ts` file.
+
+```ts
+import { ZuploContext, ZuploRequest, OTelMetricsPlugin } from "@zuplo/runtime";
+
+export default async function (request: ZuploRequest, context: ZuploContext) {
+  const someValue = "hello";
+  OTelMetricsPlugin.setContext(context, {
+    attributes: { "my.custom.attribute": someValue },
+  });
+
+  return "What zup?";
+}
+```