Enforce your style guide: voice and terminology fixes in Flash docs

accounts-billing/referrals.mdx

@@ -1,10 +1,10 @@
 ---
 title: "Referral, affiliate, and creator programs"
 sidebarTitle: "Referral programs"
 description: "Earn additional revenue through Runpod's referral, affiliate, and creator programs. Review account, billing, and management details for Runpod."
 ---
 
 Runpod offers three programs that help you earn additional revenue while helping us grow our community. Whether you're referring new users, creating popular templates, or driving significant traffic, there's a program that fits your contribution style.
 
 ## Runpod referral program
 
@@ -19,22 +19,22 @@
 - **Bonus credits** for both you and your referral after they load \$10 on their account. The bonus amount depends on your location:
   - **Non-European customers** receive a random weighted bonus between \$5 and \$500.
   - **European customers** receive a fixed \$5 bonus.
   - **Cross-region referrals**: If a European customer refers a non-European customer, the European customer receives \$5 and the non-European customer receives the random weighted bonus (\$5-\$500). If a non-European customer refers a European customer, the non-European customer receives the random weighted bonus and the European customer receives \$5.
 
 If you referred users before June 16, 2025, you're part of our beta program group. This means you'll continue earning commissions on their spend indefinitely, not just for 6 months.
 
 ### Eligibility requirements
 
 For a referral to qualify for rewards, the person you refer must meet all of the following requirements:
 
 - They must sign up using Google SSO. Referrals who sign up through any other method are not eligible for rewards.
-- They must be a first-time Runpod user. Users who previously had a Runpod account under the same email address, including deleted accounts, are not eligible for referral rewards.
+- They must be a first-time Runpod user. If they previously had a Runpod account under the same email address, including a deleted account, they are not eligible for referral rewards.
 - They must have signed up after June 15, 2025. Accounts created before this date are not eligible.
-- They must load at least \$10 onto their account. The bonus credits are awarded only after this minimum \$10 load.
+- They must load at least \$10 onto their account. Runpod awards the bonus credits only after they meet this minimum \$10 load.
 
 ## Runpod affiliate program
 
 The affiliate program is designed for high-performing referrers who want to earn cash instead of credits. Through our partnership with Partnerstack, eligible referrers can earn 10% cash commissions on all referral spend.
 
 ### Eligibility and rewards
 
@@ -46,7 +46,7 @@
 
 Once you opt into the affiliate program, this decision is permanent. Choose carefully based on whether you prefer cash payments or Runpod Credits.
 
 For beta program participants (users referred before June 26, 2025), a special arrangement applies. These users will be eligible for Partnerstack commissions during their first 6 months. After that period, they'll return to the standard referral program but continue generating commissions indefinitely.
 
 ## Runpod creator program
 
@@ -67,21 +67,21 @@
 Getting started with any of these programs is straightforward:
 
 1. Navigate to your [referral dashboard](https://www.console.runpod.io/user/referrals) in the Runpod console.
 2. Find your unique referral link (it will look something like `https://runpod.io?ref=5t99c9je`).
 3. Share this link with potential users through your preferred channels.
 
 For the creator program, simply publish templates through your Runpod account and promote them to potential users.
 
 ## Important details
 
 Understanding how these programs work will help you maximize your earnings:
 
 1. **Referral commissions are based on actual usage, not purchases.** If someone you refer buys \$1,000 in credits, you won't earn commission until they actually use those credits on Pods or Serverless workloads.
 2. **New accounts only.** Referral links only work for brand new Runpod users. If someone already has an account, referring them won't generate commissions.
 3. **Bonus credit distribution varies by location.** Non-European customers receive credits through a weighted random system between \$5 and \$500, while European customers receive a fixed \$5 bonus. For non-European customers, most will receive a bonus of \$5, with about 96% receiving \$10 or less.
 
 ## Support
 
 Have questions about maximizing your earnings or need help with any of these programs? [Contact our support team](https://contact.runpod.io/hc/en-us/requests/new) for assistance.
 
 Remember, if you're transitioning to the affiliate program, you'll keep all earnings accumulated through the referral program before making the switch.

api-reference-v2/migrate-from-v1.mdx

@@ -1,12 +1,12 @@
 ---
 title: "Migrate from API v1"
 sidebarTitle: "Migrate from v1"
 description: "Move your integrations from the Runpod REST API v1 to the v2 base URL, endpoints, and request and response shapes."
 ---
 
 The Runpod REST API v2 reorganizes resource paths, consolidates Pod lifecycle actions, and standardizes request and response shapes. This guide maps the v1 surface you know to its v2 equivalent so you can update your integrations with confidence.
 
 Read this guide if you have an existing integration built against the v1 API. REST API v1 is deprecated and will be retired on November 15, 2026. Migrate your integrations to v2 before that date.
 
 ## What changed at a glance
 
@@ -14,7 +14,7 @@
 
 - The OpenAPI schema also moves accordingly, from `https://rest.runpod.io/v1/openapi.json` to `https://api.runpod.io/v2/openapi.json`. Regenerate any client or tooling against the v2 schema.
 
 - Authentication is unchanged. Continue to pass your [Runpod API key](/get-started/api-keys) as an HTTP Bearer token in the `Authorization: Bearer RUNPOD_API_KEY` header. You don't need to change key management or scopes to call v2.
 
 ## Endpoint mapping
 
@@ -35,10 +35,10 @@
 v2 generalizes path parameters: where v1 used resource-specific names such as `{podId}`, `{endpointId}`, `{networkVolumeId}`, `{templateId}`, and `{containerRegistryAuthId}`, v2 uses a single generic `{id}` parameter across resources.
 
 <Warning>
-  Billing paths don't map by name. In v1, `/billing/endpoints` returns Serverless billing history; in v2, Serverless billing moves to `/v2/billing/serverless`. The v2 path `/v2/billing/endpoints` is a different, new resource — Public Endpoint billing history — so update your Serverless billing calls to the new path rather than assuming the old one carries over.
+  Billing paths don't map by name. In v1, `/billing/endpoints` returns Serverless billing history; in v2, Serverless billing moves to `/v2/billing/serverless`. The v2 path `/v2/billing/endpoints` is a different, new resource: Public Endpoint billing history. Update your Serverless billing calls to the new path rather than assuming the old one carries over.
 </Warning>
 
 ## Consolidated Pod lifecycle
 
 In v1, each Pod state change had its own endpoint: `POST /pods/{podId}/start`, `/stop`, `/reset`, and `/restart`. In v2, these collapse into a single [Pod state transition endpoint](/api-reference-v2/pods/trigger-a-pod-state-transition), `POST /v2/pods/{id}/action`, whose request body carries the desired action as `{"action":"start|stop|restart|terminate"}`. Deletion still uses [`DELETE /v2/pods/{id}`](/api-reference-v2/pods/terminate-a-pod).
 
@@ -46,7 +46,7 @@
   The v1 `reset` operation has no v2 action equivalent. The v2 action enum is limited to `start`, `stop`, `restart`, and `terminate`.
 </Note>
 
 For in-place changes to a Pod, v2 replaces v1's `POST /pods/{podId}/update` with a standard [PATCH request](/api-reference-v2/pods/update-a-pod) to `PATCH /v2/pods/{id}`. Serverless follows the same pattern: v2 drops v1's `POST /endpoints/{id}/update` in-place variant in favor of `PATCH /v2/serverless/{id}`.
 
 The following example shows how stopping a Pod changes between versions.
 
@@ -72,17 +72,17 @@
 
 ## Request and response shape changes
 
 The v2 request and response formats differ from v1. The most impactful changes are nested create bodies, wrapped list responses, and standardized error objects. Full field-by-field mapping is out of scope for this guide; see the linked reference pages for complete schemas.
 
 ### Nested create bodies
 
 - In v1, create bodies are flat, with top-level fields such as `gpuCount`, `gpuTypeIds`, `imageName`, `containerDiskInGb`, `volumeInGb`, `env`, and `ports`. The v2 `CreatePodRequest` is nested: `name` and `image` are required, GPU settings live under `gpu: {id, count}`, CPU settings under `cpu`, and storage under `mounts`. The `cloud` field defaults to `SECURE`, and you must set exactly one of `gpu` or `cpu`. See [Create a Pod](/api-reference-v2/pods/create-a-pod) for the full request schema.
 
 - Serverless endpoint creation changes more than its path. In v1, `EndpointCreateInput` requires a `templateId`. v2's `CreateEndpointRequest` still supports `templateId`: you can create an endpoint from a template ID, or provide the container details directly with `name`, `image`, and `gpu`. When you create from a template, `image` is optional because the template supplies it. Worker and scaling settings nest under `workers` and `scaling`, replacing v1's flat `workersMin`, `workersMax`, `scalerType`, and `idleTimeout`. See [Create a Serverless endpoint](/api-reference-v2/serverless/create-a-serverless-endpoint) for the full schema.
 
 - Templates share the same container-field renames as Pods: v1's `imageName`, `containerDiskInGb`, `isPublic`, and `containerRegistryAuthId` become `image`, `disk`, `public`, and a nested `registry` in v2. See [Create a template](/api-reference-v2/templates/create-a-template).
 
 - Network volume creation renames `dataCenterId` to `dataCenter` and adds an optional `type` field for selecting the storage tier (`STANDARD` or `HIGH_PERFORMANCE`). See [Create a network volume](/api-reference-v2/network-volumes/create-a-network-volume).
 
 ### Wrapped list responses
 
@@ -110,11 +110,11 @@
 
 The v2 wrapper key matches the resource: `GET /v2/pods` returns `{"pods":[...]}`, Serverless returns `{"endpoints":[...]}`, templates return `{"templates":[...]}`, network volumes return `{"networkVolumes":[...]}`, and registries return `{"registries":[...]}`. See [List Pods](/api-reference-v2/pods/list-pods) for a complete example.
 
 ### RFC 9457 error objects
 
 In v1, errors return a simple `{"message":"..."}` object. In v2, errors follow the RFC 9457 problem format with required `title`, `status`, and `detail` fields, plus an optional `errors` array of validation strings.
 
-As in v1, Runpod returns a `403` when a valid API key lacks access to the requested resource—but in v2 that response now uses the problem format shown here.
+As in v1, Runpod returns a `403` when a valid API key lacks access to the requested resource. In v2, that response now uses the problem format shown here.
 
 <CodeGroup>
 
@@ -136,7 +136,7 @@
 
 ## New in v2
 
-- The v2 API adds capabilities that have no v1 equivalent.
+The v2 API adds capabilities that have no v1 equivalent.
 
 - Catalog endpoints let you browse available compute without provisioning it: `GET /v2/catalog/gpus` and `/gpus/{id}`, `/cpus` and `/cpus/{id}`, and `/datacenters` and `/datacenters/{id}`. See [List GPU types](/api-reference-v2/catalog/list-gpu-types).
 
@@ -144,7 +144,7 @@
 
 - Serverless observability adds worker and release visibility through `GET /v2/serverless/{id}/workers`, `/workers/{workerId}/logs`, and `/releases`. See [List Serverless endpoint workers](/api-reference-v2/serverless/list-serverless-endpoint-workers), [Stream Serverless worker logs](/api-reference-v2/serverless/stream-serverless-worker-logs), and [List Serverless endpoint releases](/api-reference-v2/serverless/list-serverless-endpoint-releases).
 
 - Registry ECR delegations manage delegated registry access with `GET` and `POST /v2/registries/delegations` and `DELETE /v2/registries/delegations/{id}`. These endpoints aren't yet covered by a dedicated reference page during beta; consult the [v2 OpenAPI schema](/api-reference-v2/overview) for their request and response formats.
 
 - Expanded billing adds an aggregated history at `GET /v2/billing` alongside Serverless, Public Endpoint, and Instant Clusters histories, going beyond v1's Pods, endpoints, and network volume breakdowns. See [Get aggregated billing history](/api-reference-v2/billing/get-aggregated-billing-history).
 

flash/apps/build-app.mdx

@@ -1,10 +1,10 @@
 ---
 title: "Build a Flash app"
 sidebarTitle: "Build a Flash app"
 description: "Create a Flash app, test it locally, and deploy it to production. Review setup, configuration, deployment, and usage guidance for Runpod Flash."
 ---
 
 Flash apps let you build APIs to serve AI/ML workloads on Runpod Serverless. This guide walks you through the process of building a Flash app from scratch, from project initialization and local testing to production deployment.
 
 <Tip>
 If you haven't already, we recommend starting with the [Quickstart](/flash/quickstart) guide to get a feel for how Flash `@Endpoint` functions work.
@@ -31,7 +31,7 @@
 uv pip install runpod-flash
 ```
 
 Use the `flash init` command to generate a structured project template with a preconfigured application entry point:
 
 ```bash
 uv run flash init .
@@ -43,7 +43,7 @@
 uv run flash login
 ```
 
 This opens your browser to authorize Flash. After you approve, your credentials are saved for all Flash CLI commands.
 
 ## Step 2: Explore the project template
 
@@ -110,16 +110,16 @@
 uv run flash dev --auto-provision
 ```
 
 This eliminates cold-start delays by provisioning all serverless endpoints upfront. Endpoints are cached and reused across server restarts, making subsequent runs faster. Resources are identified by name, so the same endpoint won't be re-deployed if the configuration hasn't changed.
 
 ## Step 5: Open the API explorer
 
 Besides starting the API server, `flash dev` also starts an interactive API explorer. Point your web browser at [http://localhost:8888/docs](http://localhost:8888/docs) to explore the API.
 
 To run endpoint functions in the explorer:
 
 1. Expand one of the functions under **GPU Workers** or **CPU Workers**.
-2. Click **Try it out** and then **Execute**.
+2. Select **Try it out**, then **Execute**.
 
 You'll get a response from your workers right in the explorer.
 
@@ -127,14 +127,14 @@
 
 To customize your endpoints:
 
 1. Edit the `@Endpoint` functions in your worker files (`lb_worker.py`, `gpu_worker.py`, `cpu_worker.py`).
 2. Add new worker files for new endpoints.
 3. Test individual workers by running them as scripts (e.g., `python gpu_worker.py`).
 4. Restart the development server to pick up changes.
 
 ### Example: Adding a custom GPU endpoint
 
 To add a new GPU endpoint for image generation, create a new worker file or modify an existing one. For deployed apps, each queue-based function needs its own unique endpoint configuration:
 
 ```python
 from runpod_flash import Endpoint, GpuType
@@ -165,9 +165,9 @@
     return {"image": img_str, "prompt": prompt}
 ```
 
 This creates a new Serverless endpoint specifically for image generation. When deployed, it will be available at its own endpoint URL with its own `/run` or `/runsync` routes.
 
 ## Step 7: Deploy to Runpod
 
 When you're ready to deploy your app to Runpod, use `flash deploy`:
 
@@ -177,7 +177,7 @@
 
 This command:
 
 1. Builds your application into a deployment artifact.
 2. Uploads it to Runpod's storage.
 3. Provisions independent Serverless endpoints for each endpoint configuration.
 4. Configures service discovery for inter-endpoint communication.

flash/cli/build.mdx

@@ -1,9 +1,9 @@
 ---
 title: "build"
 sidebarTitle: "build"
 ---
 
 Build a deployment-ready artifact for your Flash application without deploying. Use this for more control over the build process or to inspect the artifact before deploying.
 
 ```bash
 flash build [OPTIONS]
@@ -49,17 +49,17 @@
 
 ## What happens during build
 
 1. **Python version resolution**: Resolves the target Python version from CLI flag, resource configs, or your local interpreter.
 2. **Function discovery**: Finds all `@Endpoint` decorated functions.
 3. **Grouping**: Groups functions by their endpoint configuration.
 4. **Manifest generation**: Creates `.flash/flash_manifest.json` with endpoint definitions.
 5. **Source fingerprinting**: Computes a SHA-256 fingerprint of your source files to detect code changes between deployments.
 6. **Dependency installation**: Installs Python packages for Linux x86_64.
 7. **Packaging**: Bundles everything into `.flash/artifact.tar.gz`.
 
 ## Built-in ignore patterns
 
 Flash automatically excludes certain files and directories from deployment artifacts. These patterns cover common development files that shouldn't be deployed to production.
 
 | Category | Patterns |
 |----------|----------|
@@ -78,9 +78,9 @@
 
 ### Local modules and the ignore filter
 
 Local (non-pip) modules that your endpoints import are bundled automatically, provided they pass the ignore filter: your `.gitignore` plus the built-in patterns listed above. During the build, Flash resolves the transitive local-import closure of every shipped Python file and checks it against the files the ignore filter already selected.
 
-If shipped code imports a local module that an ignore rule excludes (for example, a `test_*.py` sibling or a file under `tests/`), the build fails with a `LocalModuleResolutionError` instead of silently overriding your ignore rules or shipping a broken artifact. Flash names each excluded file and the file that imports it:
+If shipped code imports a local module that an ignore rule excludes (for example, a `test_*.py` sibling or a file under `tests/`), the build fails with a `LocalModuleResolutionError`. Failing early is deliberate: Flash won't silently override your ignore rules or ship a broken artifact. The error names each excluded file and the file that imports it:
 
 ```
 Shipped code imports local modules that the build ignore rules (.gitignore or built-in defaults) exclude:
@@ -89,7 +89,7 @@
 Shipping them would silently override a deliberate exclusion, and omitting them would break the worker with ModuleNotFoundError. Remove the matching ignore pattern or stop importing these modules from shipped code.
 ```
 
-If an `@Endpoint` file has a local import Flash can't resolve at all (a broken relative import, or a file outside your project root), the build also fails with a clear error. A file that fails resolution but doesn't define an endpoint is skipped with a warning and the build continues. For details on how local imports are resolved and bundled, see [Import local modules](/flash/create-endpoints#import-local-modules).
+If an `@Endpoint` file has a local import Flash can't resolve at all (for example, a broken relative import or a file outside your project root), the build fails with a clear error. If a file that doesn't define an endpoint fails resolution, Flash skips it with a warning and continues the build. For details on how local imports are resolved and bundled, see [Import local modules](/flash/create-endpoints#import-local-modules).
 
 ## Build artifacts
 
@@ -99,22 +99,22 @@
 |----------------|-------------|
 | `.flash/artifact.tar.gz` | Deployment package ready for Runpod |
 | `.flash/flash_manifest.json` | Service discovery configuration |
 | `.flash/.build/` | Build directory (kept for inspection) |
 
 ## Cross-platform builds
 
 Flash automatically handles cross-platform builds:
 
 - **Automatic platform targeting**: Dependencies are installed for Linux x86_64, regardless of your build platform.
 - **Binary wheel enforcement**: Only pre-built wheels are used, preventing compilation issues.
 
 ### Python version in deployed workers
 
 Flash workers support Python 3.10, 3.11, 3.12, and 3.13. The target version is determined by:
 
 1. **CLI flag:** The `--python-version` flag takes precedence.
 2. **Resource config:** The `python_version` parameter on your endpoint configs.
 3. **Local interpreter:** Your local Python version (from `sys.version_info`) when neither is specified.
 
 All resources in a Flash app must use the same Python version because Flash ships a single tarball for the entire app. If resources declare conflicting versions, the build fails.
 
@@ -127,19 +127,19 @@
 | 3.12 | No overhead | PyTorch pre-installed in base image |
 | 3.13 | +~7 GB on GPU | Alternative Python install required |
 | 3.11 | +~7 GB on GPU | Alternative Python install required |
 | 3.10 | +~7 GB on GPU | EOL 2026-10-31; consider migrating to 3.11+ |
 
 If your local Python version is not supported (for example, 3.9 or 3.14), the build fails with an actionable error message listing the supported versions.
 
 Image tags follow the pattern `py{version}-{tag}` (for example, `runpod/flash:py3.12-latest`).
 
 ## Managing deployment size
 
 Runpod Serverless has a **1.5GB deployment limit**. Flash automatically excludes packages that are pre-installed in the base image:
 
 - `torch`, `torchvision`, `torchaudio`, `triton`
 
 These packages are excluded at archive time, so you don't need to specify them manually.
 
 ### Manual exclusions
 
@@ -179,7 +179,7 @@
 
 ### Archive is too large
 
 Some CUDA packages (`torch`, `torchvision`, `torchaudio`, `triton`) are auto-excluded. If the archive is still too large, use `--exclude` to skip additional packages or `--no-deps` to skip transitive dependencies:
 
 ```bash
 flash build --exclude scipy,pandas
@@ -189,12 +189,12 @@
 
 If a package doesn't have Linux x86_64 wheels:
 
 1. Ensure standard pip is installed: `python -m ensurepip --upgrade`
 2. Check PyPI for Linux wheel availability.
 
 ### Need to examine generated files
 
 The build directory is kept after building. Inspect it with:
 
 ```bash
 ls .flash/.build/
@@ -202,12 +202,12 @@
 
 ## Related commands
 
 - [`flash deploy`](/flash/cli/deploy) - Build and deploy in one step (includes `--preview` option for local testing)
 - [`flash dev`](/flash/cli/dev) - Start development server
 - [`flash env`](/flash/cli/env) - Manage environments
 
 <Note>
 
-Most users should use `flash deploy` instead, which runs build and deploy in one step. Use `flash build` when you need more control or want to inspect the artifact.
+In most cases, use `flash deploy` instead, which runs build and deploy in one step. Use `flash build` when you need more control or want to inspect the artifact.
 
 </Note>

flash/create-endpoints.mdx

@@ -1,4 +1,4 @@
 ---
 title: "Create endpoints"
 sidebarTitle: "Create endpoints"
 description: "Learn how to create and configure hardware and scaling behavior with the Flash Endpoint class. Review configuration and usage details for Runpod Flash."
@@ -22,7 +22,7 @@
     return {"result": "processed"}
 ```
 
 When you call `run_model(data)`, Flash provisions a GPU <WorkerTooltip /> on Runpod (or reuses an existing one), sends your function code and input to the worker, executes it, and returns the result to your local environment.
 
 Each unique endpoint `name` creates one Serverless endpoint on Runpod with its own URL, scaling configuration, and hardware allocation. The endpoint manages workers that scale up and down based on demand.
 
@@ -81,13 +81,13 @@
 ```
 
 Load-balanced endpoints are ideal for:
 - REST APIs with multiple routes
 - Low-latency request/response patterns
 - Services requiring custom HTTP methods
 
 ### Custom Docker images
 
 Deploy pre-built Docker images (like vLLM or your own workers) and interact with them as a client:
 
 ```python
 from runpod_flash import Endpoint, GpuType
@@ -103,7 +103,7 @@
 models = await vllm.get("/v1/models")
 ```
 
 See [Custom Docker images](/flash/custom-docker-images) for complete documentation, including available images and configuration options.
 
 ### Existing endpoints
 
@@ -123,11 +123,11 @@
 result = await ep.post("/v1/completions", {"prompt": "hello"})
 ```
 
 ## GPU vs CPU
 
 Specify `gpu=` for GPU endpoints or `cpu=` for CPU endpoints. They are mutually exclusive.
 
 ### GPU endpoints
 
 ```python
 from runpod_flash import Endpoint, GpuType, GpuGroup
@@ -145,9 +145,9 @@
 async def process(data: dict) -> dict: ...
 ```
 
 If neither `gpu=` nor `cpu=` is specified, GPU defaults to `GpuGroup.ANY`.
 
 ### CPU endpoints
 
 ```python
 from runpod_flash import Endpoint, CpuInstanceType
@@ -206,7 +206,7 @@
 
 ### Import packages inside the function body
 
 You must import pip/installed packages **inside the decorated function body**, not at the top of your file. This ensures imports happen on the remote worker. This rule applies to installed packages only; local project modules can be imported at the top of the file because Flash ships their source (see [Import local modules](#import-local-modules)).
 
 **Correct:** imports inside the function.
 ```python
@@ -227,7 +227,7 @@
 
 ### System dependencies
 
 Use `system_dependencies` to install system-level packages (via apt):
 
 ```python
 @Endpoint(
@@ -244,21 +244,21 @@
 
 ## Import local modules
 
-Your endpoint can import local (non-pip) Python modules that live alongside it in your project, such as a sibling `utils.py` file or a `helpers/` package. Flash detects these imports, follows them transitively, and ships the module source to the worker for you, so an import like `import utils` or `from helpers import load` works remotely with no extra configuration.
+Your endpoint can import local (non-pip) Python modules that live alongside it in your project, such as a sibling `utils.py` file or a `helpers/` package. Flash detects these imports, follows them transitively, and ships the module source to the worker for you. Imports like `import utils` or `from helpers import load` work remotely with no extra configuration.
 
 Flash resolves local imports whether they appear at the top of the file or inside the function body, and it supports absolute imports (`import utils`), relative imports (`from . import helpers`), and dynamic imports with a literal name (`importlib.import_module("plugin")`). It also pulls in the `__init__.py` files for any packages you import. Flash can't resolve dynamic imports whose module name is computed at runtime, so it emits a warning, and you're responsible for making those modules available on the worker.
 
-Flash bundles only local project files. Standard library modules are already present in the worker image, and pip packages must still be declared through the `dependencies` parameter. This applies transitively: if a bundled local module imports a pip package at its top level, that package must still be declared in the `dependencies` of any endpoint that uses the module.
+Flash bundles only local project files. Standard library modules are already present in the worker image, and pip packages must still be declared through the `dependencies` parameter. This applies transitively. If a bundled local module imports a pip package at its top level, declare that package in the `dependencies` of any endpoint that uses the module.
 
-On `flash build` and `flash deploy`, local modules are bundled when they pass the ignore filter, and importing a local module that an ignore rule excludes (or one Flash can't resolve) fails the build. See [Local modules and the ignore filter](/flash/cli/build#local-modules-and-the-ignore-filter) for details.
+On `flash build` and `flash deploy`, Flash bundles local modules that pass the ignore filter. Importing a local module that an ignore rule excludes (or one Flash can't resolve) fails the build. See [Local modules and the ignore filter](/flash/cli/build#local-modules-and-the-ignore-filter) for details.
 
 ### Live execution size limit
 
 When you run an endpoint live (calling an `@Endpoint` function directly, or during `flash dev`), Flash ships the resolved module source inline with the request. The combined source is capped at 8 MiB. If your local dependencies exceed this limit, deploy the app with `flash deploy` instead, which bundles local modules into the build artifact rather than the request payload. See [Local module payload too large](/flash/troubleshooting#local-module-payload-too-large) for the corresponding error.
 
 ### Local modules in a parent directory
 
 On the live execution path, Flash treats a module imported by absolute name from a parent directory as external and doesn't ship it, which causes a `ModuleNotFoundError` on the worker. For example, this happens with `import shared` when `shared.py` sits above your endpoint file. To avoid it, place your endpoint at or above its local dependencies, or use `flash deploy`, which resolves imports against the whole project directory.
 
 ## Parallel execution
 
@@ -312,7 +312,7 @@
 
 ## Persistent storage
 
 Attach a network volume for persistent storage across workers. Each volume is tied to a specific datacenter. Flash uses the volume `name` to find an existing volume or create a new one:
 
 ```python
 from runpod_flash import Endpoint, GpuGroup, DataCenter, NetworkVolume
@@ -330,7 +330,7 @@
     ...
 ```
 
 For multi-datacenter deployments, pass a list of volumes (one per datacenter):
 
 ```python
 from runpod_flash import Endpoint, GpuGroup, DataCenter, NetworkVolume
@@ -356,7 +356,7 @@
 
 For a complete list of parameters available for the `Endpoint` class, see [Endpoint parameters](/flash/configuration/parameters).
 
 ## Working with jobs (client mode)
 
 When using `Endpoint(id=...)` or `Endpoint(image=...)`, you get an `EndpointJob` object for async operations:
 

flash/overview.mdx

@@ -1,4 +1,4 @@
 ---
 title: "Overview"
 sidebarTitle: "Overview"
 description: "Build autoscaling AI/ML apps using local code with Runpod Flash. Review setup, configuration, deployment, and usage guidance for Runpod Flash."
@@ -47,10 +47,10 @@
 Flash requires a Runpod account with a verified email address.
 </Note>
 
 ### Install Flash
 
 <Note>
-Flash requires [Python 3.10, 3.11, 3.12, or 3.13](https://www.python.org/downloads/) and runs natively on macOS and Linux. Windows users can run Flash through [WSL2](/flash/windows-wsl2).
+Flash requires [Python 3.10, 3.11, 3.12, or 3.13](https://www.python.org/downloads/) and runs natively on macOS and Linux. On Windows, run Flash through [WSL2](/flash/windows-wsl2).
 </Note>
 
 Install Flash using `pip` or `uv`:
@@ -74,9 +74,9 @@
 uv run flash login
 ```
 
 This saves your API key securely and allows you to use the Flash CLI and run `@Endpoint` functions.
 
 ### Coding agent integration (optional)
 
 Install the Flash skill package for AI coding agents like Claude Code, Cline, and Cursor:
 
@@ -88,24 +88,24 @@
 
 ## Flash apps
 
 When you're ready to move beyond scripts and build a production-ready API, you can create a [Flash app](/flash/apps/overview) (a collection of interconnected endpoints with diverse hardware configurations) and deploy it to Runpod.
 
 [Follow this tutorial to build your first Flash app](/flash/apps/build-app).
 
 ## Flash CLI
 
 The Flash CLI provides a set of commands for managing your Flash apps and endpoints.
 
 ```bash
 flash --help
 ```
 
 [Learn more about the Flash CLI](/flash/cli/overview).
 
 ## Limitations
 
-- Flash runs natively on macOS and Linux. Windows users can run Flash through [WSL2](/flash/windows-wsl2).
+- Flash runs natively on macOS and Linux. On Windows, run Flash through [WSL2](/flash/windows-wsl2).
 - CPU endpoints are restricted to the `EU-RO-1` datacenter. GPU endpoints can deploy to [multiple datacenters](/flash/configuration/parameters#datacenter).
 - Flash can rapidly scale workers across multiple endpoints, and you may hit your maximum worker threshold quickly. Contact [Runpod support](https://www.runpod.io/contact) to increase your account's capacity if needed.
 
 ## Tutorials

flash/quickstart.mdx

@@ -1,4 +1,4 @@
 ---
 title: "Get started with Flash"
 sidebarTitle: "Quickstart"
 description: "Run your first GPU workload with Flash in less than 5 minutes. Review setup, configuration, deployment, and usage guidance for Runpod Flash."
@@ -13,10 +13,10 @@
 - [Python 3.10, 3.11, 3.12, or 3.13](https://www.python.org/downloads/) installed.
 - [uv](https://docs.astral.sh/uv/) installed.
 
 ## Step 1: Install Flash
 
 <Note>
-Flash runs natively on macOS and Linux. Windows users can run Flash through [WSL2](/flash/windows-wsl2).
+Flash runs natively on macOS and Linux. On Windows, run Flash through [WSL2](/flash/windows-wsl2).
 </Note>
 
 Create a virtual environment and install Flash using [uv](https://docs.astral.sh/uv/):
@@ -43,7 +43,7 @@
 
 This enables your coding agent to provide more accurate Flash code suggestions and troubleshooting help.
 
 ## Step 2: Authenticate with Runpod
 
 Log in to your Runpod account:
 
@@ -54,7 +54,7 @@
 uv run flash login
 ```
 
 This opens your browser to authorize Flash. After you approve, your credentials are saved, allowing you to run Flash commands and scripts.
 
 <Tip>
 Alternatively, you can set the `RUNPOD_API_KEY` environment variable or add it to a `.env` file. See [`flash login`](/flash/cli/login) for details.
@@ -113,7 +113,7 @@
 Make sure you activate your virtual environment in the same directory where you created the `gpu_demo.py` file. If you open a new terminal, run `source .venv/bin/activate` before executing the script.
 </Warning>
 
 ## Step 4: Run it
 
 Execute the script:
 
@@ -137,7 +137,7 @@
 ✓ GPU used: NVIDIA RTX A5000
 ```
 
 The first run takes 30-60 seconds, while Runpod provisions the endpoint, installs dependencies, and starts a worker. Subsequent runs take 2-3 seconds (because the worker is already running).
 
 
 <Tip>
@@ -172,7 +172,7 @@
 
 ## Step 6: Understand what you just did
 
 Let's break down the code you just ran:
 
 ### Imports and setup
 
@@ -181,7 +181,7 @@
 from runpod_flash import Endpoint, GpuGroup
 ```
 
 - **`asyncio`**: Enables asynchronous execution (endpoint functions run async).
 - **`Endpoint`**: The class that marks functions for remote execution.
 - **`GpuGroup`**: Enum for selecting GPU types or groups of GPUs.
 
@@ -221,12 +221,12 @@
 The `@Endpoint` decorator configures everything in one place:
 
 - **`name`**: Identifies your endpoint in the [Runpod console](https://console.runpod.io/serverless).
 - **`gpu`**: Which GPU to use (`GpuGroup.ANY` accepts any available GPU for faster provisioning).
 - **`workers`**: Maximum parallel workers (allows 3 concurrent executions).
 - **`idle_timeout`**: Seconds a worker stays active after completing a request before scaling down. Setting this to 300 (5 minutes) gives you more time to iterate on your code while the worker remains warm.
 - **`dependencies`**: Python packages to install on the worker.
 - **Function body**: The matrix multiplication code runs on the remote GPU, not your local machine.
 - **Return value**: The result is returned to your local machine as a Python dictionary.
 
 See [GPU types](/flash/configuration/gpu-types) for available GPUs or [endpoint functions](/flash/create-endpoints) for all configuration options.
 
@@ -256,9 +256,9 @@
    - If no: It creates a new endpoint, initializes a worker, and installs your dependencies.
 2. Flash sends your code to the GPU worker
 3. The GPU worker executes the function with the provided inputs.
 4. The result is returned to your local machine as a Python dictionary, where it's printed in your terminal.
 
 Everything outside the `@Endpoint` function (all the `print` statements, etc.) runs **locally on your machine**. Only the decorated function runs remotely.
 
 ## Step 7: Run multiple operations in parallel
 
@@ -334,7 +334,7 @@
 
 ## Next steps
 
 You've successfully run GPU code on Runpod! Now you're ready to learn more about Flash:
 
 <CardGroup cols={2}>
   <Card title="Generate images with Flash" href="/tutorials/flash/image-generation-with-sdxl" icon="image" horizontal>
@@ -359,7 +359,7 @@
 Error: API key is not set
 ```
 
 **Solution**: Run `flash login` to authenticate with your Runpod account:
 
 ```bash
 flash login
@@ -380,7 +380,7 @@
 Error: endpoint template names must be unique
 ```
 
 **Solution**: Each endpoint needs a unique `name`. If you've deployed an endpoint before with the same name, either:
 - Use a different name for your new endpoint
 - Undeploy the existing endpoint with `flash undeploy <name> --force`
 
@@ -391,7 +391,7 @@
 [Stays in queue for >60 seconds]
 ```
 
 **Solution**: No GPUs available. Use `GpuGroup.ANY` to accept any available GPU:
 
 ```python
 @Endpoint(
@@ -427,7 +427,7 @@
 ModuleNotFoundError: No module named 'numpy'
 ```
 
 **Solution**: Move imports inside the `@Endpoint` function:
 
 ```python
 @Endpoint(name="compute", gpu=GpuGroup.ANY, dependencies=["numpy"])

flash/troubleshooting.mdx

@@ -1,4 +1,4 @@
 ---
 title: "Troubleshooting"
 sidebarTitle: "Troubleshooting"
 description: "Monitor, debug, and troubleshoot Flash deployments. Review setup, configuration, deployment, and usage guidance for Runpod Flash."
@@ -10,7 +10,7 @@
 
 ### Viewing logs
 
 When running Flash functions, logs are displayed in your terminal:
 
 ```text
 2025-11-19 12:35:15,109 | INFO  | Created endpoint: rb50waqznmn2kg - flash-quickstart
@@ -35,7 +35,7 @@
 View detailed metrics and logs in the [Runpod console](https://console.runpod.io/serverless):
 
 1. Navigate to the **Serverless** section.
-2. Click on your endpoint to view:
+2. Select your endpoint to view:
    - Active workers and queue depth.
    - Request history and job status.
    - Worker logs and execution details.
@@ -48,9 +48,9 @@
 
 1. Go to the [Serverless console](https://console.runpod.io/serverless).
 2. Select your endpoint.
-3. Click on a worker to view its logs.
+3. Select a worker to view its logs.
 
 Logs include dependency installation output, function execution output (print statements, errors), and system-level messages.
 
 ### Add logging to functions
 
@@ -84,7 +84,7 @@
 Get a key: https://docs.runpod.io/get-started/api-keys
 ```
 
 **Cause:** Flash requires a valid Runpod API key to provision and manage endpoints.
 
 **Solution:**
 
@@ -92,18 +92,18 @@
 
 2. Authenticate using one of these methods:
 
    **Option 1: Use `flash login` (recommended)**
    ```bash
    flash login
    ```
    Opens your browser for authentication and saves your credentials.
 
    **Option 2: Environment variable**
    ```bash
    export RUNPOD_API_KEY="your_api_key"
    ```
 
    **Option 3: .env file for local CLI use**
    ```bash
    echo "RUNPOD_API_KEY=your_api_key" >> .env
    ```
@@ -112,7 +112,7 @@
    Values in your `.env` file are only available locally for CLI commands. They are not passed to deployed endpoints.
    </Note>
 
    **Option 4: Shell profile for persistent local access**
    ```bash
    echo 'export RUNPOD_API_KEY="your_api_key"' >> ~/.bashrc
    source ~/.bashrc
@@ -126,9 +126,9 @@
 Run 'flash login' to re-authenticate, or delete the file and retry.
 ```
 
 **Cause:** The credentials file at `~/.runpod/config.toml` contains invalid TOML and cannot be read. This can also appear as "No API key found" even after a successful `flash login`.
 
 **Solution:** Delete the credentials file and re-authenticate:
 
 ```bash
 rm ~/.runpod/config.toml
@@ -142,9 +142,9 @@
 Load-balanced endpoints require route decorators
 ```
 
 **Cause:** Load-balanced endpoints require HTTP method decorators for each route.
 
 **Solution:** Ensure all routes use the correct decorator pattern:
 
 ```python
 from runpod_flash import Endpoint
@@ -161,16 +161,16 @@
     return {"status": "healthy"}
 ```
 
 ### Invalid HTTP method
 
 **Error:**
 ```
 method must be one of {'GET', 'POST', 'PUT', 'DELETE', 'PATCH'}
 ```
 
 **Cause:** The HTTP method specified is not supported.
 
 **Solution:** Use one of the supported HTTP methods: `GET`, `POST`, `PUT`, `DELETE`, or `PATCH`.
 
 ### Invalid path format
 
@@ -179,9 +179,9 @@
 path must start with '/'
 ```
 
 **Cause:** HTTP paths must begin with a forward slash.
 
 **Solution:** Ensure paths start with `/`:
 
 ```python
 # Correct
@@ -198,13 +198,13 @@
 Duplicate route 'POST /process' in endpoint 'my-api'
 ```
 
 **Cause:** Two functions define the same HTTP method and path combination.
 
 **Solution:** Ensure each route is unique within an endpoint. Either change the path or method of one function.
 
 ## Build errors
 
 ### Unsupported Python version
 
 **Error:**
 ```
@@ -212,13 +212,13 @@
 Pass --python-version, declare python_version on a resource config, or run flash from a supported interpreter.
 ```
 
 **Cause:** Flash supports Python 3.10, 3.11, 3.12, and 3.13. Your local Python version is outside this range.
 
 **Solution:**
 
 You have three options:
 
 1. **Use the `--python-version` CLI flag** to override local detection:
    ```bash
    flash build --python-version 3.12
    flash deploy --python-version 3.12
@@ -244,7 +244,7 @@
 Python 3.12 is recommended for best performance with no cold-start overhead. Python 3.10, 3.11, and 3.13 incur additional cold-start overhead on GPU workers because an alternative Python interpreter must be installed.
 </Tip>
 
 ### Local module could not be resolved
 
 **Error:**
 ```
@@ -260,7 +260,7 @@
 Shipping them would silently override a deliberate exclusion, and omitting them would break the worker with ModuleNotFoundError. Remove the matching ignore pattern or stop importing these modules from shipped code.
 ```
 
 **Cause:** This `LocalModuleResolutionError` has two variants: an `@Endpoint` file imports a local module that Flash can't resolve, or shipped code imports a local module that an ignore pattern excludes.
 
 **Solution:**
 
@@ -283,11 +283,11 @@
 Tarball exceeds maximum size. File size: 1.6GB, Max: 1.5GB
 ```
 
 **Cause:** The deployment package exceeds the 1.5GB limit.
 
 **Solution:**
 
 1. Check for large files that shouldn't be included (datasets, model weights, logs).
 2. Add large files to `.gitignore` to exclude them from the build.
 3. Use [network volumes](/flash/configuration/storage) to store large models instead of bundling them.
 
@@ -298,25 +298,25 @@
 File is not a valid gzip file. Expected magic bytes (31, 139)
 ```
 
 **Cause:** The build artifact is corrupted or not a valid gzip file.
 
 **Solution:** Delete the `.flash` directory and rebuild:
 
 ```bash
 rm -rf .flash
 flash build
 ```
 
 ### SSL certificate verification failed
 
 **Error:**
 ```
 SSL certificate verification failed. This usually means Python cannot find your system's CA certificates.
 ```
 
 **Cause:** Python cannot locate the system's trusted CA certificates, preventing secure connections during deployment. This commonly occurs on fresh Python installations, especially on macOS.
 
 **Solution:** Try one of these fixes:
 
 1. **Install certifi and set the certificate bundle path:**
    ```bash
@@ -324,7 +324,7 @@
    export REQUESTS_CA_BUNDLE=$(python -c "import certifi; print(certifi.where())")
    ```
 
 2. **macOS only:** Run the certificate installer that comes with Python. Find it in your Python installation folder (typically `/Applications/Python 3.x/`) and run `Install Certificates.command`.
 
 3. **Add to shell profile for persistence:**
    ```bash
@@ -343,7 +343,7 @@
 Failed to provision resources: [error details]
 ```
 
 **Cause:** Flash couldn't create the Serverless endpoint on Runpod.
 
 **Solutions:**
 
@@ -365,7 +365,7 @@
 Endpoint URL not available - endpoint may not be deployed
 ```
 
 **Cause:** The endpoint function was called before the endpoint finished provisioning.
 
 **Solutions:**
 
@@ -382,7 +382,7 @@
 Execution timeout on [endpoint] after [N]s
 ```
 
 **Cause:** The endpoint function took longer than the configured timeout.
 
 **Solutions:**
 
@@ -397,7 +397,7 @@
 
 2. **Optimize function**: Profile your function to identify bottlenecks.
 
 3. **Use queue-based endpoints**: For long-running tasks, use the `@Endpoint` decorator pattern. Queue-based endpoints are designed for longer operations.
 
 ### Connection failed
 
@@ -406,7 +406,7 @@
 Failed to connect to endpoint [name] ([url])
 ```
 
 **Cause:** Network connectivity issue between your local environment and the Runpod endpoint.
 
 **Solutions:**
 
@@ -414,14 +414,14 @@
 2. **Retry**: Transient network issues often resolve on retry. Flash includes automatic retry logic.
 3. **Check endpoint status**: Verify the endpoint is running in the [Serverless console](https://console.runpod.io/serverless).
 
 ### HTTP errors from endpoint
 
 **Error:**
 ```
 HTTP error from endpoint [name]: 500 - Internal Server Error
 ```
 
 **Cause:** The endpoint function raised an exception during execution.
 
 **Solutions:**
 
@@ -447,7 +447,7 @@
 Failed to deserialize result: [error]
 ```
 
 **Cause:** The function's return value cannot be serialized/deserialized.
 
 **Solutions:**
 
@@ -471,11 +471,11 @@
 Payload size X MB exceeds limit of 10.0 MB
 ```
 
 **Cause:** The serialized argument exceeds the 10 MB limit. Flash uses base64 encoding, which expands data by approximately 33%, so roughly 7.5 MB of raw data becomes 10 MB when encoded.
 
 **Solutions:**
 
 1. **Use network volumes for large data**: Save large data to a network volume and pass the file path:
    ```python
    @Endpoint(name="processor", gpu=GpuGroup.ANY, volume="vol_abc123")
    async def process(file_path: str) -> dict:
@@ -484,7 +484,7 @@
        return {"result": process_data(data)}
    ```
 
 2. **Compress data before sending**: For data that must be passed directly, use compression:
    ```python
    import gzip
 
@@ -502,9 +502,9 @@
 Use `flash deploy` for endpoints with large local dependencies.
 ```
 
 **Cause:** On the live execution path (calling an `@Endpoint` function directly or during `flash dev`), Flash ships your local module source inline with the request, and the combined source exceeds the 8 MiB cap.
 
 **Solution:** Deploy the app with `flash deploy`, which bundles local modules into the build artifact instead of the request payload:
 
 ```bash
 flash deploy
@@ -513,7 +513,7 @@
 uv run flash deploy
 ```
 
 See [Live execution size limit](/flash/create-endpoints#live-execution-size-limit) for details on how local module source is shipped.
 
 ### Deserialization timeout
 
@@ -522,9 +522,9 @@
 Deserialization timed out after 30s
 ```
 
 **Cause:** The deserialization process took longer than 30 seconds. This usually indicates malformed or corrupted serialized data that causes the unpickle operation to hang.
 
 **Solution:** Verify your input data is properly serialized. If you're manually constructing payloads, ensure the data was serialized using `cloudpickle` and encoded with base64. The Flash SDK handles this automatically for programmatic calls.
 
 ### Circuit breaker open
 
@@ -533,23 +533,23 @@
 Circuit breaker is open. Retry in [N] seconds
 ```
 
 **Cause:** Too many consecutive failures to the endpoint triggered the circuit breaker protection.
 
 **Solutions:**
 
 1. **Wait and retry**: The circuit breaker will automatically attempt recovery after the timeout (typically 60 seconds).
 
 2. **Check endpoint health**: Multiple failures usually indicate an underlying issue. Check logs and endpoint status.
 
 3. **Fix the root cause**: Address whatever is causing the repeated failures before retrying.
 
 ## GPU availability issues
 
 ### Job stuck in queue
 
 **Symptom:** Job status shows `IN_QUEUE` for extended periods.
 
 **Cause:** The requested GPU types are not available.
 
 **Solutions:**
 
@@ -565,7 +565,7 @@
    )
    ```
 
 2. **Use GpuGroup.ANY**: For development, accept any available GPU:
    ```python
    gpu=GpuGroup.ANY
    ```
@@ -578,14 +578,14 @@
 
 ### Module not found
 
 **Error (in worker logs):**
 ```
 ModuleNotFoundError: No module named 'transformers'
 ```
 
 **Cause:** A required dependency was not specified in the `@Endpoint` decorator.
 
 **Solution:** Add all required packages to the `dependencies` parameter:
 
 ```python
 @Endpoint(
@@ -600,11 +600,11 @@
 
 ### Version conflicts
 
 **Symptom:** Function fails with import errors or unexpected behavior.
 
 **Cause:** Dependency version conflicts between packages.
 
 **Solution:** Pin specific versions:
 
 ```python
 @Endpoint(

get-started/mcp-servers.mdx

@@ -1,34 +1,34 @@
 ---
 title: "Use Runpod's MCP servers"
 sidebarTitle: "MCP servers"
 description: "Connect AI tools to Runpod using the Model Context Protocol for infrastructure management and documentation access."
 tag: "NEW"
 ---
 
 Runpod provides two [Model Context Protocol (MCP)](https://modelcontextprotocol.io/docs/getting-started/intro) servers that connect AI tools and coding agents directly to Runpod:
 
 - **[Runpod API MCP server](#runpod-api-mcp-server):** Manage Pods, endpoints, templates, volumes, and registries through the Runpod REST API. Authenticate with Sign in with Runpod or a [Runpod API key](/get-started/api-keys).
 - **[Runpod docs MCP server](#runpod-docs-mcp-server):** Search Runpod documentation for features, code examples, and guides. No authentication required.
 
 ## Runpod API MCP server
 
 The Runpod API MCP server gives AI tools access to the [Runpod REST API](/api-reference/overview), letting you create and manage Pods, Serverless endpoints, templates, network volumes, and container registries through natural language.
 
 **Hosted endpoint:** `https://mcp.getrunpod.io/` (Streamable HTTP transport)
 
 **Local package:** `@runpod/mcp-server` (via npx)
 
 **Source code:** [github.com/runpod/runpod-mcp](https://github.com/runpod/runpod-mcp)
 
 **Authentication:** Sign in with Runpod (OAuth) for the hosted server, or a [Runpod API key](/get-started/api-keys) for the local server or as a hosted-server override.
 
 You can connect in two ways: the recommended hosted server, or a local server that runs from an npm package with an API key.
 
 ### Hosted server (recommended)
 
-The hosted server runs at `https://mcp.getrunpod.io/` and provides the same capabilities as the local server. OAuth-capable clients run a "Sign in with Runpod" flow on first connect: a browser opens, you log in to the Runpod console and approve the request, and the server obtains a session-scoped API key. Nothing is stored on disk.
+The hosted server runs at `https://mcp.getrunpod.io/` and provides the same capabilities as the local server. OAuth-capable clients run a "Sign in with Runpod" flow on first connect. A browser opens, you log in to the Runpod console and approve the request, and the server obtains a session-scoped API key. The server stores nothing on disk.
 
 The guided installer is the recommended path for supported clients. It detects your installed clients — Claude Code, Claude Desktop, Cursor, Windsurf, and VS Code — and configures each one, handling client-specific config-key differences automatically:
 
 ```bash
 npx @runpod/mcp-server@latest add
@@ -36,26 +36,26 @@
 
 To undo these changes, run `npx @runpod/mcp-server@latest remove`.
 
 #### Claude Code (hosted)
 
 ```bash
 claude mcp add --transport http runpod -s user https://mcp.getrunpod.io/
 ```
 
 #### Claude Desktop (hosted)
 
 1. Open **Settings** in Claude Desktop.
 2. Navigate to **Connectors** and select **Add custom connector**.
 3. Enter `https://mcp.getrunpod.io/` as the URL and click **Add**.
 
 #### VS Code with Copilot (hosted)
 
 1. Open the Command Palette (Ctrl+Shift+P on Windows/Linux or Cmd+Shift+P on macOS).
 2. Run **MCP: Add Server** and select **HTTP**.
 3. Enter `https://mcp.getrunpod.io/` as the URL and `Runpod` as the name.
 4. Select **Global** or **Workspace** and click **Add**.
 
 #### Other clients (hosted)
 
 For any other MCP-compatible client, use the remote URL `https://mcp.getrunpod.io/`:
 
@@ -69,7 +69,7 @@
 }
 ```
 
-Clients differ in the exact key name they use for a remote server URL. For the clients the guided installer supports, it writes the correct configuration automatically; for any other client, consult that client's MCP documentation for how to add a remote HTTP server, using the URL above.
+Clients differ in the exact key name they use for a remote server URL. For the clients the guided installer supports, it writes the correct configuration automatically. For any other client, consult that client's MCP documentation for how to add a remote HTTP server, using the URL above.
 
 <Note>
 To skip the OAuth flow, pass your API key as a bearer header. For example, in Claude Code:
@@ -82,22 +82,22 @@
 Clients configured with JSON use a `headers` block instead.
 </Note>
 
 ### Local server (API key)
 
-Use this method to run the server locally with an API key stored in your client config — for example, if your client doesn't support the hosted server's sign-in flow, or you prefer to manage the credential yourself.
+Use this method to run the server locally with an API key stored in your client config. For example, choose this method if your client doesn't support the hosted server's sign-in flow, or if you prefer to manage the credential yourself.
 
 #### Supported clients
 
 - [Claude Code](#claude-code)
 - [Codex CLI](#codex-cli)
 - [Cursor](#cursor)
 - [VS Code with Copilot](#vs-code-with-copilot)
 - [Claude Desktop](#claude-desktop)
 - [Windsurf](#windsurf)
 - [Cline](#cline)
 - [Gemini CLI](#gemini-cli)
 
 #### Claude Code
 
 ```bash
 claude mcp add runpod --scope user -e RUNPOD_API_KEY=your_api_key_here -- npx -y @runpod/mcp-server@latest
@@ -105,9 +105,9 @@
 
 Replace `your_api_key_here` with your Runpod API key. The `--scope user` flag makes the server available across all your projects. Run `/mcp` inside Claude Code to verify the connection.
 
 #### Codex CLI
 
 [Codex CLI](https://github.com/openai/codex) is OpenAI's terminal-based coding agent.
 
 ```bash
 codex mcp add runpod --env RUNPOD_API_KEY=your_api_key_here -- npx -y @runpod/mcp-server@latest
@@ -115,7 +115,7 @@
 
 #### Cursor
 
 Add the following to `.cursor/mcp.json` (project-level) or `~/.cursor/mcp.json` (global). This configuration works with both the Cursor IDE and the [Cursor Agent](https://cursor.com/docs/cli/mcp):
 
 ```json
 {
@@ -131,9 +131,9 @@
 }
 ```
 
 #### VS Code with Copilot
 
 1. Open the Command Palette (Ctrl+Shift+P on Windows/Linux or Cmd+Shift+P on macOS).
 2. Run **MCP: Add Server** and select **stdio**.
 3. Enter the following details:
    - **Name:** `Runpod`
@@ -142,7 +142,7 @@
 4. Add environment variable `RUNPOD_API_KEY` with your Runpod API key.
 5. Select **Global** or **Workspace** and click **Add**.
 
 #### Claude Desktop
 
 Add the following to your Claude Desktop config file:
 
@@ -167,7 +167,7 @@
 
 #### Windsurf
 
 Edit `~/.codeium/windsurf/mcp_config.json` (or open from **Settings** > **Cascade** > **MCP Servers** > **View raw config**):
 
 ```json
 {
@@ -202,9 +202,9 @@
 }
 ```
 
 #### Gemini CLI
 
 Add to `~/.gemini/settings.json` (global) or `.gemini/settings.json` (project-level):
 
 ```json
 {
@@ -257,21 +257,21 @@
 Stop the Pod named "ml-training-pod"
 ```
 
 ## Runpod docs MCP server
 
 The Runpod docs MCP server provides access to Runpod's documentation knowledge base, making it easier to get answers about features and how to use them.
 
 **Endpoint:** `https://docs.runpod.io/mcp`
 
 **Authentication:** None required
 
 ### Claude Code
 
 ```bash
 claude mcp add runpod-docs --scope user --transport http https://docs.runpod.io/mcp
 ```
 
 ### Codex CLI
 
 ```bash
 codex mcp add runpod-docs --url https://docs.runpod.io/mcp
@@ -291,14 +291,14 @@
 }
 ```
 
 ### VS Code with Copilot
 
 1. Open the Command Palette (Ctrl+Shift+P on Windows/Linux or Cmd+Shift+P on macOS).
 2. Run **MCP: Add Server** and select **HTTP**.
 3. Enter `https://docs.runpod.io/mcp` as the URL and `Runpod Docs` as the name.
 4. Select **Global** or **Workspace** and click **Add**.
 
 ### Claude Desktop
 
 1. Open **Settings** in Claude Desktop.
 2. Navigate to **Connectors** and select **Add custom connector**.
@@ -333,9 +333,9 @@
 }
 ```
 
 ### Gemini CLI
 
 Add to `~/.gemini/settings.json`. Note that Gemini CLI uses `httpUrl` instead of `url`:
 
 ```json
 {
@@ -349,7 +349,7 @@
 
 ### Other clients
 
 For any other MCP-compatible client, use URL `https://docs.runpod.io/mcp` (HTTP transport).
 
 ### Usage examples