Bug hunt: em dash removal, MCP guide cleanup, misc fixes (#732)

* Fix some small bugs

Signed-off-by: Dan Barr <6922515+danbarr@users.noreply.github.com>

* Update style guide TOC

Signed-off-by: Dan Barr <6922515+danbarr@users.noreply.github.com>

* Remove en dashes

Signed-off-by: Dan Barr <6922515+danbarr@users.noreply.github.com>

* Update resource list in operator index

Signed-off-by: Dan Barr <6922515+danbarr@users.noreply.github.com>

* Remove last_update from MCP server guides

* Fix broken anchors

* Rewrite Next steps and Related info as sentences

Avoids Markdown sublist ambiguity when descriptions wrap to indented
lines starting with a hyphen.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

---------

Signed-off-by: Dan Barr <6922515+danbarr@users.noreply.github.com>
Co-authored-by: Dan Barr <6922515+danbarr@users.noreply.github.com>
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Author: danbarr

.claude/commands/polish-toolhive-updates.md

@@ -42,13 +42,13 @@ Every feature should answer: **"What can I now do that I couldn't before, and wh
 
 **Bad**: "Added API management to Registry Server"
 
-**Good**: "API-based management lets you add, update, or remove registries programmatically—useful for CI/CD pipelines and infrastructure-as-code approaches"
+**Good**: "API-based management lets you add, update, or remove registries programmatically, making it easier to integrate with CI/CD pipelines and infrastructure-as-code workflows"
 
 ### 2. Honest About Maturity
 
 - Avoid claiming production-readiness prematurely
 - Use phrases like "adds more operational capabilities," "moves closer to production readiness," "foundational capabilities"
-- Don't oversell—these are incremental improvements showing project momentum
+- Don't oversell; most updates are incremental improvements showing project momentum
 
 ### 3. Accessible Language
 
@@ -152,7 +152,7 @@ For each major feature/component:
 
 **Before**: "Monitor which MCP servers behind vMCP are available and responding"
 
-**After**: "**Health monitoring** tracks which MCP servers behind vMCP are available and responding—the foundation for building alerts and dashboards"
+**After**: "**Health monitoring** tracks which MCP servers behind vMCP are available and responding, giving you the foundation to build alerts and dashboards"
 
 ### Issue: Too Much Technical Detail Too Soon
 

.claude/skills/upstream-release-docs/SKILL.md

@@ -32,7 +32,7 @@ Signed-off-by: jane marmot <jmarmot@example.org>
 
 The Signed-off-by [trailer](https://git-scm.com/docs/git-interpret-trailers) can
 be added automatically by using the
-[-s or –signoff command line option](https://git-scm.com/docs/git-commit/2.13.7#Documentation/git-commit.txt--s)
+[-s or --signoff command line option](https://git-scm.com/docs/git-commit/2.13.7#Documentation/git-commit.txt--s)
 when specifying your commit message:
 
 ```bash

DCO.md

@@ -17,6 +17,12 @@ aim to deliver clear, concise, and valuable information to project users.
   - [Links](#links)
   - [Formatting](#formatting)
 - [Screenshots and images](#screenshots-and-images)
+- [Page structure](#page-structure)
+  - [Front matter](#front-matter)
+    - [Descriptions](#descriptions)
+  - [Closing sections](#closing-sections)
+  - [Introduction pages](#introduction-pages)
+  - [Cross-references](#cross-references)
 - [Markdown style](#markdown-style)
 - [Projects](#projects)
 - [Word list \& glossary](#word-list--glossary)
@@ -264,7 +270,7 @@ Our preferred style elements include:
   Heading 2, and so on); use unique headings within a document
 - Unordered lists: use hyphens (`-`), not asterisks (`*`)
 - Ordered lists: use lazy numbering (`1.` for every item and let Markdown render
-  the final order – this is more maintainable when inserting new items)
+  the final order. This is more maintainable when inserting new items)
   - Note: this is a "soft" recommendation. It is also intended only for Markdown
     documents that are read through a rendering engine. If the Markdown will be
     consumed in raw form, use real numbering.

STYLE-GUIDE.md

@@ -53,8 +53,8 @@ secrets for sensitive values like API keys.
 ## Kubernetes Operator: Custom CA support
 
 **The
-[MCPServer CRD](/toolhive/reference/crd-spec#apiv1alpha1inlineoidcconfig)** now
-supports custom certificate authorities, enabling ToolHive to validate OAuth
+[MCPServer CRD](/toolhive/reference/crd-spec#apiv1alpha1inlineoidcsharedconfig)**
+now supports custom certificate authorities, enabling ToolHive to validate OAuth
 tokens issued by private on-premises identity provider instances, essential for
 organizations with internal PKI infrastructure.
 

blog/toolhive-updates/2026-02-02-updates.mdx

@@ -247,7 +247,7 @@ MDX Tabs component, default theme
             return 'I agree, and this line is highlighted!'
 
         return 'I am wrong.'
-        ```
+    ```
 
   </TabItem>
   <TabItem value='orange' label='Orange'>

docs/theme-preview.mdx

@@ -32,11 +32,11 @@ If authenticated clients are denied access:
    (including case and formatting)
 3. Examine any conditions in your policies to ensure they're satisfied (for
    example, required JWT claims or tool arguments)
-4. Remember that Cedar uses a default deny policy—if no policy explicitly
+4. Remember that Cedar uses a default deny policy: if no policy explicitly
    permits an action, it will be denied
 
 **Troubleshooting tip:** If access is denied, check that your policies
-explicitly permit the action. Cedar uses a default deny model—if no policy
+explicitly permit the action. Cedar uses a default deny model: if no policy
 matches, the request is denied.
 
 </details>

docs/toolhive/_partials/_auth-troubleshooting.mdx

@@ -12,7 +12,7 @@ together, the reasoning behind their design, and the benefits of this approach.
 
 :::info[Scope of this documentation]
 
-This documentation covers **client-to-MCP-server authentication**—how clients
+This documentation covers **client-to-MCP-server authentication**: how clients
 authenticate to the MCP server itself. This is about securing access to the MCP
 server's tools and resources.
 
@@ -39,7 +39,7 @@ identity can do. ToolHive helps you follow this best practice by acting as a
 gateway in front of your MCP servers. This approach lets you use proven identity
 systems for authentication, while keeping your authorization policies clear,
 flexible, and auditable. You don't need to add custom authentication or
-authorization logic to every server—ToolHive handles it for you, consistently
+authorization logic to every server. ToolHive handles it for you, consistently
 and securely.
 
 ## Why ToolHive centralizes authentication
@@ -51,9 +51,9 @@ server acts as an OAuth resource server. In practice, this model creates
 significant operational challenges:
 
 - **OAuth client registration burden:** OAuth 2.0 requires pre-registered
-  redirect URIs at each identity provider. Many providers—such as Google,
-  GitHub, and Atlassian—require manual registration of OAuth clients to obtain a
-  client ID and client secret. If each user client (for example, an IDE) were
+  redirect URIs at each identity provider. Many providers (such as Google,
+  GitHub, and Atlassian) require manual registration of OAuth clients to obtain
+  a client ID and client secret. If each user client (for example, an IDE) were
   its own OAuth client, the registration burden would be impractical at scale.
 - **No federation with external services:** While token exchange (RFC 8693) and
   federated identity providers work when the upstream service is in the same
@@ -66,9 +66,9 @@ significant operational challenges:
 
 ToolHive addresses the per-server implementation cost by centralizing
 authentication and authorization in its proxy layer. You configure ToolHive with
-your identity provider and write Cedar policies for fine-grained
-authorization—individual MCP servers don't need to implement token validation or
-scope management.
+your identity provider and write Cedar policies for fine-grained authorization.
+Individual MCP servers don't need to implement token validation or scope
+management.
 
 The [embedded authorization server](#embedded-authorization-server) addresses
 the remaining challenges. It exposes standard OAuth endpoints and handles the
@@ -87,7 +87,7 @@ This lets you connect ToolHive to any OAuth 2.1 or OIDC-compliant identity
 provider (IdP), such as Google, GitHub, Microsoft Entra ID (Azure AD), Okta,
 Auth0, or even Kubernetes service accounts. ToolHive never handles your raw
 passwords or credentials; instead, it relies on access tokens issued by your
-trusted provider—either self-contained JWT tokens or opaque tokens validated
+trusted provider, either self-contained JWT tokens or opaque tokens validated
 through token introspection.
 
 ### Why use OAuth-based authentication?
@@ -142,7 +142,7 @@ directly. ToolHive validates these tokens by querying the identity provider's
 token introspection endpoint to retrieve the associated claims.
 
 ToolHive automatically detects the token type and uses the appropriate
-validation method—attempting JWT validation first and falling back to token
+validation method, attempting JWT validation first and falling back to token
 introspection if needed.
 
 ### Authentication flow
@@ -176,17 +176,17 @@ In the standard authentication flow described above, clients obtain tokens
 independently from an external identity provider and present them to ToolHive
 for validation. The embedded authorization server provides an alternative model
 where ToolHive itself acts as an OAuth authorization server, obtaining tokens
-from an upstream provider on behalf of clients—then storing those tokens and
+from an upstream provider on behalf of clients, storing those tokens, and
 issuing its own JWTs for clients to use on subsequent requests.
 
 This solves two problems at once: it eliminates the client registration burden
 through Dynamic Client Registration (DCR), and it bridges the gap for external
 APIs like GitHub or Atlassian where no federation relationship exists with your
 identity provider.
 
-For the complete conceptual description—including the OAuth flow, token storage
+For the complete conceptual description (including the OAuth flow, token storage
 and forwarding, session storage options, and differences between MCPServer and
-VirtualMCPServer—see
+VirtualMCPServer), see
 [Embedded authorization server](./embedded-auth-server.mdx).
 
 For Kubernetes setup instructions, see
@@ -222,7 +222,7 @@ identity providers:
   supports RFC 7662 (OAuth 2.0 Token Introspection), Google's tokeninfo API, and
   GitHub's token validation API.
 
-ToolHive automatically detects the token type—it first attempts JWT validation,
+ToolHive automatically detects the token type. It first attempts JWT validation,
 and if that fails, it falls back to token introspection. This means you don't
 need to configure which validation method to use; ToolHive handles it
 automatically based on the token format.
@@ -232,8 +232,8 @@ automatically based on the token format.
 After authentication, ToolHive enforces authorization using Amazon's Cedar
 policy language. ToolHive acts as a gateway in front of MCP servers, handling
 all authorization checks before requests reach the server logic. This means MCP
-servers do not need to implement their own OAuth or custom authorization
-logic—ToolHive centralizes and standardizes access control.
+servers do not need to implement their own OAuth or custom authorization logic.
+ToolHive centralizes and standardizes access control.
 
 ### Why Cedar for authorization?
 
@@ -248,7 +248,7 @@ Cedar provides several advantages for MCP server authorization:
   to read, write, and audit.
 - **Policy enforcement point:** ToolHive blocks unauthorized requests before
   they reach the MCP server, which reduces risk and simplifies server code.
-- **Secure by default:** Authorization is explicit—if a request is not
+- **Secure by default:** Authorization is explicit: if a request is not
   explicitly permitted, it is denied. Deny rules take precedence over permit
   rules (deny overrides).
 
@@ -296,7 +296,7 @@ benefits:
 - **Integration with existing systems:** Use your existing identity
   infrastructure (SSO, IdPs, Kubernetes, etc.).
 - **Centralized, flexible policy model:** Define precise, auditable access rules
-  in a single place—no need to modify MCP server code.
+  in a single place, with no need to modify MCP server code.
 - **Secure by default:** Requests are denied unless explicitly permitted by
   policy, with deny precedence for maximum safety.
 - **Auditable and versionable:** Policies are clear, declarative, and can be

docs/toolhive/concepts/auth-framework.mdx

@@ -13,7 +13,7 @@ development.
 
 :::info[Scope of this documentation]
 
-This documentation covers **MCP-server-to-backend authentication**—how MCP
+This documentation covers **MCP-server-to-backend authentication**: how MCP
 servers authenticate to external services or APIs they call (for example, a
 GitHub MCP server authenticating to the GitHub API).
 
@@ -51,8 +51,8 @@ ToolHive sits between clients and MCP servers, and can acquire backend
 credentials on behalf of the MCP server. Depending on the pattern, it might
 exchange the client's token, run an OAuth flow against an external provider, or
 inject static credentials. In each case, the MCP server receives ready-to-use
-credentials—via an `Authorization: Bearer` header, another header, or
-environment variables, depending on the pattern—without needing to implement
+credentials (via an `Authorization: Bearer` header, another header, or
+environment variables, depending on the pattern) without needing to implement
 custom authentication logic or manage secrets directly.
 
 ## Backend authentication patterns
@@ -77,12 +77,12 @@ rotation.
 
 ### Token exchange
 
-When the backend service trusts the same IdP as your MCP clients—or federation
-is configured between the two IdPs—ToolHive can exchange the client's token for
+When the backend service trusts the same IdP as your MCP clients, or federation
+is configured between the two IdPs, ToolHive can exchange the client's token for
 one scoped to the backend service using RFC 8693 token exchange. This preserves
 the user's identity across services and provides short-lived, narrowly scoped
 tokens. Because the trust relationship is pre-configured at the IdP, the
-exchange is transparent to the end user—no consent screen required.
+exchange is transparent to the end user, with no consent screen required.
 
 #### Same IdP with token exchange
 
@@ -122,7 +122,7 @@ flowchart LR
 When the backend service trusts a different IdP, but federation is configured
 between the two IdPs, ToolHive can use the federated identity service to issue
 short-lived tokens. Examples include Google's Security Token Service (STS) for
-Google Cloud services and AWS STS for AWS services—both can issue tokens based
+Google Cloud services and AWS STS for AWS services. Both can issue tokens based
 on your corporate identity.
 
 ```mermaid
@@ -155,15 +155,15 @@ flowchart LR
 ### Embedded authorization server
 
 When the MCP server needs to call an external API where no federation
-relationship exists—such as GitHub, Google Workspace, or Atlassian APIs—the
+relationship exists (such as GitHub, Google Workspace, or Atlassian APIs), the
 embedded authorization server handles the full OAuth web flow against the
 external provider. The proxy redirects the user to authenticate directly with
 the external service, obtains tokens on behalf of the user, and automatically
 forwards the upstream token to the MCP server on each subsequent request.
 
-The embedded authorization server runs in-process within the ToolHive proxy—no
-separate infrastructure is needed. It supports Dynamic Client Registration
-(DCR), so MCP clients can register automatically with ToolHive—no manual client
+The embedded authorization server runs in-process within the ToolHive proxy with
+no separate infrastructure needed. It supports Dynamic Client Registration
+(DCR), so MCP clients can register automatically with ToolHive. No manual client
 configuration in ToolHive is required.
 
 For a full explanation of how the OAuth flow works, token storage and
@@ -312,17 +312,17 @@ ToolHive's token-based authentication patterns (token exchange and the embedded
 authorization server) provide several key advantages over static credentials:
 
 - **Secure:** MCP servers receive short-lived, properly scoped access tokens
-  instead of embedding long-lived secrets
+  instead of embedding long-lived secrets.
 - **Auditable:** Each API call is attributed to the individual user identity,
-  making audit trails clear and meaningful
+  making audit trails clear and meaningful.
 - **Multi-tenant friendly:** Token scoping naturally supports tenant isolation
-  and separation of duties
-- **Developer friendly:** MCP servers don't need custom authentication
-  logic—they just use the provided token
+  and separation of duties.
+- **Developer friendly:** MCP servers don't need custom authentication logic.
+  They just use the provided token.
 - **Least privilege:** Tokens are narrowly scoped to specific audiences and
-  permissions, reducing the blast radius if compromised
+  permissions, reducing the blast radius if compromised.
 - **Consistent:** The same pattern works across different backend services and
-  identity providers
+  identity providers.
 
 ## Choosing the right backend authentication pattern
 

docs/toolhive/concepts/backend-auth.mdx

@@ -7,9 +7,9 @@ description:
 
 The embedded authorization server is an OAuth 2.0 authorization server that runs
 in-process within the ToolHive proxy. It solves a specific problem: how to
-authenticate MCP server requests to external APIs—like GitHub, Google Workspace,
-or Atlassian—where no federation relationship exists between your identity
-provider and that external service.
+authenticate MCP server requests to external APIs (like GitHub, Google
+Workspace, or Atlassian) where no federation relationship exists between your
+identity provider and that external service.
 
 Without the embedded auth server, every MCP client would need to register its
 own OAuth application with each external provider, manage redirect URIs, and
@@ -114,7 +114,7 @@ sequenceDiagram
 ```
 
 MCP servers receive the upstream access token in the `Authorization: Bearer`
-header—they don't need to implement custom authentication logic or manage
+header. They don't need to implement custom authentication logic or manage
 secrets.
 
 ## Automatic token refresh
@@ -131,7 +131,7 @@ the OAuth flow.
 ## Key characteristics
 
 - **In-process execution:** The authorization server runs within the ToolHive
-  proxy—no separate infrastructure or sidecar containers needed.
+  proxy with no separate infrastructure or sidecar containers.
 - **Dynamic Client Registration (DCR):** Supports OAuth 2.0 DCR (RFC 7591),
   allowing MCP clients to register automatically. No manual client registration
   in ToolHive is required.
@@ -201,16 +201,16 @@ or
 ## Next steps
 
 - [Set up embedded authorization server authentication](../guides-k8s/auth-k8s.mdx#set-up-embedded-authorization-server-authentication)
-  — step-by-step setup for MCPServer resources in Kubernetes
-- [vMCP embedded authorization server](../guides-vmcp/authentication.mdx#embedded-authorization-server)
-  — configuring multiple upstream providers on a VirtualMCPServer
-- [Redis Sentinel session storage](../guides-k8s/redis-session-storage.mdx) —
-  production session storage configuration
+  for step-by-step setup of MCPServer resources in Kubernetes
+- [Configure the vMCP embedded authorization server](../guides-vmcp/authentication.mdx#embedded-authorization-server)
+  for multiple upstream providers on a VirtualMCPServer
+- [Deploy Redis Sentinel](../guides-k8s/redis-session-storage.mdx) for
+  production session storage
 
 ## Related information
 
-- [Authentication and authorization](./auth-framework.mdx) — client-to-MCP
+- [Authentication and authorization](./auth-framework.mdx) covers client-to-MCP
   authentication concepts and the overall framework
-- [Backend authentication](./backend-auth.mdx) — all backend authentication
+- [Backend authentication](./backend-auth.mdx) covers all backend authentication
   patterns, including when to choose the embedded auth server
-- [Cedar policies](./cedar-policies.mdx) — authorization policy configuration
+- [Cedar policies](./cedar-policies.mdx) for authorization policy configuration