docs: fix Context7 suggestions

llms-full.txt

@@ -78674,6 +78674,14 @@ database's distributed architecture, read operations can be performed with
 reduced latency, as data retrieval occurs from the closest available Read
 Region.
 
+Lua scripts follow the same routing: [`EVAL`](/docs/redis/commands/scripting/eval) and
+[`EVALSHA`](/docs/redis/commands/scripting/evalsha) always execute on the Primary
+Region, while [`EVAL_RO`](/docs/redis/commands/scripting/eval-ro) and
+[`EVALSHA_RO`](/docs/redis/commands/scripting/evalsha-ro) are served by the nearest
+Read Region. Because the script in an `EVAL_RO` call cannot write, declare
+read-only scripts with `EVAL_RO` so that reads keep being served close to the
+client.
+
 The Global database's design thus aids in minimizing read operation latency by
 efficiently distributing data across multiple regions and enabling requests to
 be processed from the nearest Read Region.
@@ -78683,7 +78691,10 @@ performance, you should select the primary region in the same location where
 your writes happen. Select the read regions where your clients that read the
 Redis located. You may have your database with a single primary region but no
 read regions which would be practically same with a single region (regional)
-database. You can add or remove regions on a running Redis database.
+database. After creation you can only add or remove read regions on a running
+database; the primary region cannot be changed. A regional database also cannot
+be upgraded in place to a global one (see
+[Upgrade from Regional to Global](#upgrade-from-regional-to-global)).
 
 Here the list of regions currently supported:
 
@@ -79088,6 +79099,13 @@ curl https://us1-merry-cat-32748.upstash.io/set/foo/bar \
  -H "Authorization: Bearer 2553feg6a2d9842h2a0gcdb5f8efe9934"
 ```
 
+<Note>
+  If you connected your database through the
+  [Vercel integration](/docs/redis/tutorials/nextjs_with_redis),
+  the same values are injected as `KV_REST_API_URL` and `KV_REST_API_TOKEN`
+  instead of `UPSTASH_REDIS_REST_URL` and `UPSTASH_REDIS_REST_TOKEN`.
+</Note>
+
 The above script executes a `SET foo bar` command. It will return a JSON
 response:
 
@@ -79121,6 +79139,8 @@ Here are some examples:
 
 * `MGET foo1 foo2 foo3` -> `REST_URL/mget/foo1/foo2/foo3`
 
+* `INCR foo` -> `REST_URL/incr/foo`
+
 * `HGET employee:23381 salary` -> `REST_URL/hget/employee:23381/salary`
 
 * `ZADD teams 100 team-x 90 team-y` ->
@@ -87319,6 +87339,14 @@ docker run \
     hiett/serverless-redis-http:latest
 ```
 
+Your application then connects to SRH with the same environment variables it
+would use against Upstash, pointing the URL at the local proxy:
+
+```bash
+UPSTASH_REDIS_REST_URL=http://localhost:8080
+UPSTASH_REDIS_REST_TOKEN=your_token_here
+```
+
 ### Via Docker Compose
 
 If you wish to run in Kubernetes, this should contain all the basics would need

redis/features/globaldatabase.mdx

@@ -24,6 +24,14 @@ database's distributed architecture, read operations can be performed with
 reduced latency, as data retrieval occurs from the closest available Read
 Region.
 
+Lua scripts follow the same routing: [`EVAL`](/redis/commands/scripting/eval) and
+[`EVALSHA`](/redis/commands/scripting/evalsha) always execute on the Primary
+Region, while [`EVAL_RO`](/redis/commands/scripting/eval-ro) and
+[`EVALSHA_RO`](/redis/commands/scripting/evalsha-ro) are served by the nearest
+Read Region. Because the script in an `EVAL_RO` call cannot write, declare
+read-only scripts with `EVAL_RO` so that reads keep being served close to the
+client.
+
 The Global database's design thus aids in minimizing read operation latency by
 efficiently distributing data across multiple regions and enabling requests to
 be processed from the nearest Read Region.
@@ -33,7 +41,10 @@ performance, you should select the primary region in the same location where
 your writes happen. Select the read regions where your clients that read the
 Redis located. You may have your database with a single primary region but no
 read regions which would be practically same with a single region (regional)
-database. You can add or remove regions on a running Redis database.
+database. After creation you can only add or remove read regions on a running
+database; the primary region cannot be changed. A regional database also cannot
+be upgraded in place to a global one (see
+[Upgrade from Regional to Global](#upgrade-from-regional-to-global)).
 
 Here the list of regions currently supported:
 

redis/features/restapi.mdx

@@ -23,6 +23,13 @@ curl https://us1-merry-cat-32748.upstash.io/set/foo/bar \
  -H "Authorization: Bearer 2553feg6a2d9842h2a0gcdb5f8efe9934"
 ```
 
+<Note>
+  If you connected your database through the
+  [Vercel integration](/redis/tutorials/nextjs_with_redis),
+  the same values are injected as `KV_REST_API_URL` and `KV_REST_API_TOKEN`
+  instead of `UPSTASH_REDIS_REST_URL` and `UPSTASH_REDIS_REST_TOKEN`.
+</Note>
+
 The above script executes a `SET foo bar` command. It will return a JSON
 response:
 
@@ -56,6 +63,8 @@ Here are some examples:
 
 - `MGET foo1 foo2 foo3` -> `REST_URL/mget/foo1/foo2/foo3`
 
+- `INCR foo` -> `REST_URL/incr/foo`
+
 - `HGET employee:23381 salary` -> `REST_URL/hget/employee:23381/salary`
 
 - `ZADD teams 100 team-x 90 team-y` ->

redis/sdks/ts/developing.mdx

@@ -46,6 +46,14 @@ docker run \
     hiett/serverless-redis-http:latest
 ```
 
+Your application then connects to SRH with the same environment variables it
+would use against Upstash, pointing the URL at the local proxy:
+
+```bash
+UPSTASH_REDIS_REST_URL=http://localhost:8080
+UPSTASH_REDIS_REST_TOKEN=your_token_here
+```
+
 ### Via Docker Compose
 
 If you wish to run in Kubernetes, this should contain all the basics would need