Part 2: Update Registry Server docs for v1.0.0–v1.1.0

docs/toolhive/contributing.mdx

@@ -70,8 +70,9 @@ actively being developed and tested.
 ### Registry server
 
 The Registry Server is an API server that implements the official MCP Registry
-API. It provides standardized access to MCP servers from multiple backends,
-including file-based and other API-compliant registries.
+API. It provides standardized access to MCP servers and skills from multiple
+backends, including Git repositories, API endpoints, files, managed sources, and
+Kubernetes clusters.
 
 **Repository**:
 [stacklok/toolhive-registry-server](https://github.com/stacklok/toolhive-registry-server)

docs/toolhive/guides-k8s/remote-mcp-proxy.mdx

@@ -801,7 +801,7 @@ Learn how to customize MCP tools using
 [filters and overrides](./customize-tools.mdx).
 
 Discover your deployed MCP servers automatically using the
-[Kubernetes registry](../guides-registry/configuration.mdx#kubernetes-registry)
+[Kubernetes source](../guides-registry/configuration.mdx#kubernetes-source)
 feature in the ToolHive Registry Server.
 
 ## Related information

docs/toolhive/guides-k8s/telemetry-and-metrics.mdx

@@ -175,7 +175,7 @@ spec:
 
 :::note
 
-`caBundleRef` cannot be used when `insecure` is set to `true` - they are
+`caBundleRef` cannot be used when `insecure` is set to `true` — they are
 mutually exclusive.
 
 :::

docs/toolhive/guides-registry/authentication.mdx

@@ -10,6 +10,14 @@ OAuth mode to protect your registry. You can configure authentication to fit
 different deployment scenarios, from development environments to production
 deployments with enterprise identity providers.
 
+:::tip[Looking for authorization?]
+
+This page covers **authentication** (verifying caller identity). For
+**authorization** (controlling what callers can do), including role-based access
+control and claims-based scoping, see [Authorization](./authorization.mdx).
+
+:::
+
 ## Authentication modes
 
 The server supports two authentication modes configured via the required `auth`
@@ -346,11 +354,14 @@ anonymous mode in production.**
 The following endpoints are **always accessible without authentication**,
 regardless of the auth mode:
 
-- `/health` - Health check endpoint
-- `/readiness` - Readiness probe endpoint
-- `/version` - Version information
+- `/openapi.json` - OpenAPI specification
 - `/.well-known/*` - OAuth discovery endpoints (RFC 9728)
 
+The `/health`, `/readiness`, and `/version` endpoints are served on a separate
+internal server (default port 8081) and are not exposed on the main API port.
+See the [command-line flags](./configuration.mdx#command-line-flags) for the
+`--internal-address` option.
+
 You can configure additional public paths using the `publicPaths` field in your
 OAuth configuration. See the
 [Registry API reference](../reference/registry-api.mdx) for complete endpoint
@@ -499,6 +510,14 @@ providers:
     caCertPath: /etc/ssl/certs/internal-ca.crt
 ```
 
+## Next steps
+
+- [Configure authorization](./authorization.mdx) to set up role-based access
+  control and claims-based scoping
+- [Set up the database](./database.mdx) for production storage and migrations
+- [Configure telemetry](./telemetry-metrics.mdx) for distributed tracing and
+  metrics collection
+
 ## Troubleshooting
 
 ### 401 Unauthorized errors
@@ -544,9 +563,3 @@ If tokens from some providers work but others don't:
 4. Review server logs to identify which specific provider validation is failing
 5. Test each provider's JWKS endpoint accessibility:
    `curl ${issuerUrl}/.well-known/openid-configuration`
-
-## Next steps
-
-- [Set up the database](./database.mdx) for production storage and migrations
-- [Configure telemetry](./telemetry-metrics.mdx) for distributed tracing and
-  metrics collection