diff --git a/docs/platform/enterprise-manager/policies/registry.mdx b/docs/platform/enterprise-manager/policies/registry.mdx index e6631c0d..b19d887a 100644 --- a/docs/platform/enterprise-manager/policies/registry.mdx +++ b/docs/platform/enterprise-manager/policies/registry.mdx @@ -10,8 +10,8 @@ registry can be a self-hosted [Registry Server](../../../toolhive/guides-registry/index.mdx), the upstream MCP registry, or any MCP-compatible registry. -You'll need your registry's URL (for example, `https://registry.acme.com`) and -the Enterprise Manager already [deployed](../configure.mdx) and reachable by +You'll need your registry's URL (for example, `https://registry.example.com`) +and the Enterprise Manager already [deployed](../configure.mdx) and reachable by clients. ## Configure the registry directive @@ -25,7 +25,7 @@ enterpriseConfig: registry: value: # The registry API URL all clients connect to - api_url: 'https://registry.acme.com' + api_url: 'https://registry.example.com' # "enforced" blocks local overrides; "default" lets users override locally enforcement: 'enforced' ``` @@ -48,7 +48,7 @@ Suggest the registry URL as an org-wide default while allowing local overrides: enterpriseConfig: registry: value: - api_url: 'https://registry.acme.com' + api_url: 'https://registry.example.com' enforcement: 'default' ``` @@ -62,7 +62,7 @@ responses: enterpriseConfig: registry: value: - api_url: 'https://registry.internal.acme.com' + api_url: 'https://registry.internal.example.com' allow_private_ip: true enforcement: 'enforced' ``` diff --git a/docs/platform/enterprise-manager/policies/telemetry.mdx b/docs/platform/enterprise-manager/policies/telemetry.mdx index 977e5586..8200baef 100644 --- a/docs/platform/enterprise-manager/policies/telemetry.mdx +++ b/docs/platform/enterprise-manager/policies/telemetry.mdx @@ -11,7 +11,7 @@ ToolHive's OpenTelemetry support, see the guide. You'll need the OTLP HTTP endpoint for your collector (for example, -`https://otel.acme.com`) and the Enterprise Manager already +`https://otel.example.com`) and the Enterprise Manager already [deployed](../configure.mdx) and reachable by clients. ## Configure the telemetry directive @@ -25,7 +25,7 @@ enterpriseConfig: telemetry: value: # Required: OTLP HTTP endpoint for your OpenTelemetry collector - otel_endpoint: 'https://otel.acme.com' + otel_endpoint: 'https://otel.example.com' # Fraction of traces to sample: 0.0 = none, 1.0 = all sampling_rate: 0.1 tracing_enabled: true @@ -66,7 +66,7 @@ override them: enterpriseConfig: telemetry: value: - otel_endpoint: 'https://otel.acme.com' + otel_endpoint: 'https://otel.example.com' sampling_rate: 0.1 tracing_enabled: true metrics_enabled: true @@ -82,7 +82,7 @@ set `insecure: true`: enterpriseConfig: telemetry: value: - otel_endpoint: 'http://otel.internal.acme.com:4318' + otel_endpoint: 'http://otel.internal.example.com:4318' insecure: true tracing_enabled: true metrics_enabled: true diff --git a/docs/toolhive/guides-cli/client-configuration.mdx b/docs/toolhive/guides-cli/client-configuration.mdx index 427db24f..a9a6e6f4 100644 --- a/docs/toolhive/guides-cli/client-configuration.mdx +++ b/docs/toolhive/guides-cli/client-configuration.mdx @@ -30,19 +30,6 @@ To view the current status of detected and configured clients, run: thv client status ``` -:::note - -ToolHive previously included an "auto-discovery" mode. We removed this mode in -v0.1.0 to simplify client configuration and ensure consistent control and -behavior. If you previously enabled client auto-discovery, ToolHive will -explicitly register all detected clients the first time you run v0.1.0 and -higher. - -Going forward, use the `thv client setup` command to manage your client -configurations. - -::: - ## Alternative client registration If you prefer to register clients manually or in an automated script, use the diff --git a/docs/toolhive/guides-cli/network-isolation.mdx b/docs/toolhive/guides-cli/network-isolation.mdx index 677c101a..5f16a8cd 100644 --- a/docs/toolhive/guides-cli/network-isolation.mdx +++ b/docs/toolhive/guides-cli/network-isolation.mdx @@ -211,8 +211,7 @@ Network isolation is a bridge-network construct: the egress, DNS, and ingress sidecars only work when the MCP container lives on a container-runtime bridge. When you pass `--network host` or `--network none`, the container shares the host network namespace or has no network at all, so the isolation sidecars have -no way to intercept traffic. In v0.40.0 and later, ToolHive reconciles the two -flags automatically: +no way to intercept traffic. ToolHive reconciles the two flags automatically: | `--network` mode | `--isolate-network` source | Behavior | | -------------------------- | --------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------- | @@ -221,18 +220,6 @@ flags automatically: | `host` or custom | explicit `--isolate-network=true` | `thv run` fails fast with an error naming both flags. Drop `--network host` to keep enforced isolation, or set `--isolate-network=false` to keep host networking. | | `none` | any | Isolation is silently dropped (`none` is already maximally confined; isolation would be redundant). | -:::info[Changed in v0.40.0] - -Before v0.40.0, `thv run --network host` silently built the isolation sidecars -against an internal-only network, breaking outbound DNS and connectivity. -Isolation is now dropped for `host`/`none` modes so host-networked workloads -keep working. If you rely on host networking, no change is needed. If you -previously combined `--isolate-network` with `--network host` explicitly, pick -one: drop `--network host` to keep enforced isolation, or set -`--isolate-network=false` to keep host networking. - -::: - ## Example: Enable network isolation using registry defaults Many MCP servers in the ToolHive registry have default permission profiles that diff --git a/docs/toolhive/integrations/aws-sts.mdx b/docs/toolhive/integrations/aws-sts.mdx index a37e6191..8f87136f 100644 --- a/docs/toolhive/integrations/aws-sts.mdx +++ b/docs/toolhive/integrations/aws-sts.mdx @@ -1,8 +1,8 @@ --- title: AWS STS authentication for the AWS MCP Server description: - Learn how to centralize AWS credential management by using ToolHive to - exchange OIDC tokens for temporary AWS credentials via STS. + Centralize AWS credential management by using ToolHive to exchange OIDC tokens + for temporary AWS credentials via STS. --- This tutorial shows you how to use ToolHive as an authentication proxy for the diff --git a/docs/toolhive/integrations/ingress-ngrok.mdx b/docs/toolhive/integrations/ingress-ngrok.mdx index 02aca2d1..8e5e4ddf 100644 --- a/docs/toolhive/integrations/ingress-ngrok.mdx +++ b/docs/toolhive/integrations/ingress-ngrok.mdx @@ -1,8 +1,8 @@ --- title: Configure secure ingress for MCP servers on Kubernetes description: - A guide to setting up secure ingress for MCP servers running on a Kubernetes - cluster using the ToolHive Operator. + Set up secure ingress for MCP servers running on a Kubernetes cluster using + the ToolHive Operator. --- In this tutorial, you'll configure secure ingress for MCP servers running on a diff --git a/docs/toolhive/integrations/vault.mdx b/docs/toolhive/integrations/vault.mdx index 02eb48f1..b1804e37 100644 --- a/docs/toolhive/integrations/vault.mdx +++ b/docs/toolhive/integrations/vault.mdx @@ -1,8 +1,8 @@ --- title: HashiCorp Vault integration description: - Learn how to securely manage MCP server secrets using HashiCorp Vault with - ToolHive Kubernetes Operator. + Securely manage MCP server secrets using HashiCorp Vault with the ToolHive + Kubernetes Operator. --- This tutorial shows how to integrate HashiCorp Vault with the ToolHive