diff --git a/.github/copilot-instructions.md b/.github/copilot-instructions.md
deleted file mode 100644
index 57703cfa..00000000
--- a/.github/copilot-instructions.md
+++ /dev/null
@@ -1,203 +0,0 @@
-# Project overview
-
-This is the user-facing documentation for ToolHive, an open source tool that helps you run and manage Model Context Protocol (MCP) servers easily and securely.
-
-## Tech stack
-
-- Docusaurus 3, based on React 19 and TypeScript
-- Node.js 24 (exact version required - see `package.json` engines field)
-- npm for package management
-- Vercel for deployment and hosting
-
-## Folder structure
-
-- `/docs`: contains the main documentation files. Each file corresponds to a page in the documentation.
-- `/blog/toolhive-updates`: contains weekly update posts from the ToolHive team. These posts follow a slightly different voice (see "Tone and voice" section).
-- `/static`: contains static assets like images, icons, and other files that are served directly.
-- `/src`: contains the source code for the website, including components, styles, and customizations.
-
-## Primary configuration files
-
-- `/docusaurus.config.ts`: the main configuration file for Docusaurus, where you define site metadata, theme, plugins, and other settings.
-- `/sidebars.ts`: defines the structure of the documentation sidebar, including which pages appear in the sidebar and their order.
-- `/vercel.json`: configuration file for Vercel deployment, specifying build settings and redirects.
-
-## Commands
-
-Development commands:
-
-- `npm run start`: starts a local development server with hot reloading.
-- `npm run build`: runs a production build of the site to verify there are no build errors. Run this before creating a PR to ensure the site builds successfully.
-
-Code quality commands (note: pre-commit hooks run these automatically on staged files):
-
-- `npm run prettier` and `npm run prettier:fix`: check and fix code formatting issues (all file types).
-- `npm run eslint` and `npm run eslint:fix`: check and fix code quality issues (`.js`, `.jsx`, `.ts`, `.tsx`, `.mdx` files only).
-- `npm run markdownlint` and `npm run markdownlint:fix`: check and fix Markdown style issues (`.md` files only - DO NOT use with `.mdx` files).
-
-## Contribution guidelines
-
-- Use the GitHub flow for contributions: create a branch, make changes, open a pull request (PR).
-- Use the pull request template (`/.github/pull_request_template.md`) when opening a PR on behalf of the user.
-- Ensure all changes pass linting and formatting checks before submitting a PR.
-- Write concise commit messages, limited to 50 characters for the subject line, with a detailed body only if necessary.
-- Do NOT use conventional commits style; use imperative mood in the subject line (e.g., "Add", "Fix", "Update").
-
-## Automated quality checks
-
-The project uses automated tooling to enforce code quality and formatting standards:
-
-- **Pre-commit hooks**: lint-staged runs automatically on `git commit`, applying prettier and appropriate linters to staged files.
-- **GitHub Actions**: All PRs trigger automated checks (ESLint, markdownlint, Prettier).
-- **No manual formatting needed**: The pre-commit hook handles formatting automatically - you do not need to run formatters manually.
-
-File type to linter mapping (handled automatically by pre-commit hooks):
-
-- `.md` files: Prettier + markdownlint
-- `.mdx` files: Prettier + ESLint (NOT markdownlint)
-- `.js`, `.jsx`, `.ts`, `.tsx` files: Prettier + ESLint
-- `.css`, `.json`, `.jsonc`, `.yaml`, `.yml` files: Prettier only
-
-## Git workflow
-
-- **Main branch**: `main` - all feature branches should be created from and merged into main
-- **Branch naming**: Use descriptive names (e.g., `fix-broken-link`, `add-vmcp-docs`)
-- **Pre-commit hooks**: Automatically format and lint staged files on commit
-- **Before pushing**: Run `npm run build` to verify the site builds successfully
-- **Default branch for PRs**: Target `main` unless working on a specific release branch
-
-## Audience
-
-The primary audience is developers and DevOps professionals who want to run and manage Model Context Protocol (MCP) servers using ToolHive. They may be new to MCP servers or have some experience with them.
-
-The documentation should be accessible to a wide range of technical users, including those who may not be familiar with the specific technologies used in ToolHive.
-
-## Information architecture
-
-This project follows the [Diataxis framework](https://diataxis.fr/) for documentation organization. Diataxis divides documentation into four types based on user needs:
-
-1. **Tutorials** (`/docs/toolhive/tutorials/`) - Learning-oriented, step-by-step lessons that guide users through completing a project or learning a concept.
-2. **How-to guides** (`/docs/toolhive/guides-*/`) - Task-oriented, practical guides that show how to solve specific problems or accomplish specific tasks.
-3. **Reference** (`/docs/toolhive/reference/`) - Information-oriented, technical descriptions of the machinery and how to operate it (API docs, CLI commands, configuration options).
-4. **Explanation/Concepts** (`/docs/toolhive/concepts/`) - Understanding-oriented, explanations that clarify and illuminate topics, provide background and context.
-
-### When to create new pages
-
-Create a new documentation page when:
-
-- The content addresses a distinct task, concept, or reference topic that doesn't fit within existing pages.
-- An existing page would become too long or cover too many disparate topics.
-- The information architecture requires it (e.g., a new MCP server guide, a new tutorial).
-- The content belongs to a different Diataxis category than existing content.
-
-Always consider where the new page fits in the Diataxis framework and place it in the appropriate directory. Update `/sidebars.ts` to include the new page in the navigation.
-
-## Review process
-
-When you are asked to review documentation changes, you are a subject matter expert (SME) for the content and a technical writer. Your role is to ensure that the content is accurate, clear, and consistent with the project's goals and standards.
-
-- Prioritize clarity, accuracy, and consistency.
-- Ensure that the content is easy to understand, follows the writing style guide.
-- Do not consider markdown formatting or syntax, as these will be handled by the code quality tools.
-
-## Writing style guide
-
-The primary goal of the documentation is to be clear, concise, and user-friendly. The writing style should be approachable and easy to understand, while still providing the necessary technical details.
-
-The project's official language is US English.
-
-### Tone and voice
-
-- Strive for a casual and conversational tone without becoming overly informal.
-- Be friendly and relatable while retaining credibility and professionalism.
-- Avoid slang and colloquial expressions.
-- Use clear, straightforward language and avoid overly complex jargon to make content accessible to a wide audience.
-- Use active voice instead of passive voice.
-- Address the reader using the second person ("you", "your"). Avoid the first person ("we", "our") and third person ("the user", "a developer").
- - Exception: In `/blog/toolhive-updates` posts, use first person ("we", "our") to communicate updates from the ToolHive team. This creates a direct connection between the team and the community.
-
-### Capitalization
-
-- Capitalize proper nouns like names, companies, and products. Generally, don't capitalize features or generic terms.
-- Use sentence case in titles and headings.
-- Use `ALL_CAPS` to indicate placeholder text/parameters, where the reader is expected to change a value.
-- Expand acronyms on first use, then use the acronym in subsequent references.
- - Exception: MCP is used ubiquitously in this project, so it does not need to be expanded on first use.
-
-### Punctuation
-
-- Use the Oxford comma (aka serial commas) when listing items in a series.
-- Use one space between sentences.
-- Use straight double quotes and apostrophes. Replace smart quotes (“ ”) and curly apostrophes (’ ’) with straight quotes (") and straight apostrophes (').
-
-### Links
-
-- Use descriptive link text. Besides providing clear context to the reader, this improves accessibility for screen readers.
-- When referencing other docs/headings by title, use sentence case so the reference matches the corresponding title or heading.
-
-### Images
-
-- Use images sparingly and only when they add value to the content.
-- Use images to illustrate complex concepts, provide examples, or enhance understanding.
-- Use screenshots to show UI elements or workflows, but ensure they are clear, relevant, and add value to the content.
-- Don't use images of text, code samples, or terminal output. Use actual text so readers can copy/paste and find the contents via search engines.
-- Add alt text to images to describe their content and purpose. This improves accessibility for users with visual impairments.
-
-### Examples
-
-- Use examples to clarify complex concepts or demonstrate how to use a feature.
-- Prefer practical, real-world examples over abstract or contrived ones.
-
-### Formatting
-
-- Bold: use when referring to UI elements; prefer bold over quotes.
-- Italics: emphasize particular words or phrases, such as when introducing/defining a term.
-- Underscore: do not use; reserved for links.
-- Use inline code formatting for short code elements, such as variable names, function names, or command-line options.
-- Use block code formatting for longer code snippets or examples.
-
-### Word list
-
-ALWAYS use these exact terms and capitalizations. When editing documentation, replace any variations with the preferred terms listed here:
-
-- ToolHive - this project, an open source tool that helps you run and manage MCP servers easily and securely
-- Stacklok - the company behind ToolHive
-- GitHub Copilot
-- Model Context Protocol (MCP)
-- open source (not "open-source")
-- large language model (LLM)
-- Visual Studio Code ("VS Code" after first use)
-- Virtual MCP Server (vMCP) - a feature of ToolHive that aggregates multiple MCP servers into a single endpoint; use "Virtual MCP Server (vMCP)" on first use, "vMCP" thereafter
-
-If you encounter a term not listed here that appears frequently in the documentation, consider adding it to this list for consistency.
-
-## Markdown style
-
-Prettier and markdownlint are used to enforce the following Markdown style conventions.
-
-- Headings: use "ATX-style" headings
-- Use unique headings within a document
-- Unordered lists: use hyphens (`-`), not asterisks (`*`)
-- Bold: Use the `**` syntax for bold text, not `__`
-- Italics: Use the `__` syntax for italic text, not `*`
-- Ordered lists: use lazy numbering for long or verbose lists.
- - 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 like a repo README file, use real numbering.
-- Code blocks: use fenced code blocks (` ``` ` to begin/end) and always declare the language. If the language is unknown or plain text like log output, use `text` as the language.
-- Add blank lines around headings, lists, and code blocks.
-- No trailing whitespace on lines.
- - Use the `\` character at the end of a line for a single-line break, not the two-space syntax which is easy to miss.
-- Line limit: wrap lines at 80 characters; exceptions for links, tables, headings, and code blocks
-
-### Docusaurus specifics
-
-This website is built using Docusaurus, which has some specific requirements and conventions for Markdown files:
-
-- Heading 1 is reserved for the page title, typically defined in the Markdown front matter section. Sections within a page begin with Heading 2 (`##`).
-- Use relative file links (with .md/.mdx extensions) when referring to other pages.
-- Use the .mdx extension for pages containing JSX includes.
-- Use the front matter section on all pages. At a minimum, set the `title` (this is rendered into the page as an H1) and a short `description`.
-- Use the `admonition` component for notes, tips, warnings, and other annotations. This provides a consistent look and feel across the site.
- - Use the `:::type` syntax to define the admonition type, such as `note`, `tip`, `info`, `warning`, or `danger`. Use square brackets to add a title, e.g. `:::info[Title]`. Add empty lines around the start and end directives.
-- Place images in `static/img` using WebP, PNG, or SVG format.
-- Use the `ThemedImage` component to provide both light and dark mode screenshots for apps/UIs that support both.
-- Use the `Tabs` and `TabItem` components to create tabbed content sections.
diff --git a/.github/copilot-instructions.md b/.github/copilot-instructions.md
new file mode 120000
index 00000000..be77ac83
--- /dev/null
+++ b/.github/copilot-instructions.md
@@ -0,0 +1 @@
+../AGENTS.md
\ No newline at end of file
diff --git a/docs/toolhive/guides-cli/index.mdx b/docs/toolhive/guides-cli/index.mdx
index 7a4f69f6..3a0fc7f1 100644
--- a/docs/toolhive/guides-cli/index.mdx
+++ b/docs/toolhive/guides-cli/index.mdx
@@ -10,7 +10,7 @@ import DocCardList from '@theme/DocCardList';
## Introduction
The ToolHive CLI (`thv`) is a command-line tool that allows you to deploy and
-manage MCP servers on your local machines or in development environments. It
+manage MCP servers on your local machine or in development environments. It
provides quick deployment of MCP servers and supports advanced features like
custom permissions, network access filtering, and telemetry.
diff --git a/docs/toolhive/guides-registry/index.mdx b/docs/toolhive/guides-registry/index.mdx
index bec656ea..15ce6288 100644
--- a/docs/toolhive/guides-registry/index.mdx
+++ b/docs/toolhive/guides-registry/index.mdx
@@ -9,8 +9,8 @@ import DocCardList from '@theme/DocCardList';
## Introduction
-The ToolHive Registry server implements the official
-[Model Context Protocol (MCP) Registry API specification](https://github.com/modelcontextprotocol/registry/blob/main/docs/reference/api/generic-registry-api.md)
+The ToolHive Registry Server is an implementation of the official
+[Model Context Protocol (MCP) Registry API specification](https://github.com/modelcontextprotocol/registry/blob/main/docs/reference/api/generic-registry-api.md).
It provides a standardized REST API for discovering and accessing MCP servers
from multiple backend sources, including Kubernetes clusters, Git repositories,
API endpoints, and local files.
diff --git a/docs/toolhive/index.mdx b/docs/toolhive/index.mdx
index 1977b454..4fe3c77d 100644
--- a/docs/toolhive/index.mdx
+++ b/docs/toolhive/index.mdx
@@ -37,17 +37,43 @@ import ThemedImage from '@theme/ThemedImage';
# What is ToolHive?
-ToolHive simplifies the deployment and management of Model Context Protocol
-(MCP) servers. It ensures ease of use, consistency, and security by running
-containers in a locked-down environment with minimal permissions.
+ToolHive is an enterprise-grade open source (Apache 2.0) platform for running
+and managing Model Context Protocol (MCP) servers.
Follow the [getting started guide](./tutorials/quickstart-ui.mdx) to install
-ToolHive and run your first MCP server.
+ToolHive locally and run your first MCP server.
To learn more about the Model Context Protocol, see our
[MCP primer](./concepts/mcp-primer.mdx).
-ToolHive is available in three modes to suit different use cases:
+## ToolHive components
+
+ToolHive includes everything you need to use MCP servers in production. It's
+made up of four key components: the Runtime, Registry Server, Gateway, and
+Portal.
+
+
+**Runtime:**
-## Key features
+- Run local MCP servers instantly from the built-in registry of vetted MCP
+ servers, any Docker container, or directly from package managers
+- Deploy MCP servers in the cloud via Kubernetes for enterprise scalability
+- Proxy remote MCP servers securely for unified management
+- Apply fine-grained permissions and network access filtering
+- Protect sensitive data with built-in secrets management and enterprise OAuth
+ integrations
+- Leverage OpenTelemetry and Prometheus for observability and audit logging
-ToolHive includes a range of features to help you run and manage MCP servers
-effectively:
+**Registry Server:**
-- **Streamlined deployment**: Deploy MCP servers instantly using Docker
- containers or directly from package managers via protocol schemes (`uvx://`,
- `npx://`, `go://`). Access a curated registry of verified MCP servers that you
- can discover and run effortlessly.
+- Curate a catalog of trusted MCP servers from multiple sources: the official
+ MCP Registry, other public registries, and custom files
+- Group servers based on role or use case
+- Manage your registry with an API-driven interface
+- Preset configurations and permissions for a frictionless user experience
-- **Seamless integration**: Configure popular development tools automatically,
- including GitHub Copilot and Cursor, to streamline your workflow with minimal
- setup.
+**Gateway:**
-- **Comprehensive security**: Run MCP servers in isolated containers with
- customizable, fine-grained permissions and network access filtering using JSON
- profiles. Securely manage secrets and configurations using built-in encrypted
- storage or 1Password integration, eliminating plaintext secrets in
- configuration files.
+- Orchestrate multiple tools with a deterministic workflow engine
+- Centralize control of security policy, authentication, authorization,
+ auditing, etc.
+- Customize and filter tools and descriptions to improve performance and reduce
+ token usage
-- **Enterprise readiness**: Implement robust OAuth-based authorization controls
- for enterprise environments that integrate seamlessly with existing
- infrastructure.
+**Portal:**
-- **Kubernetes deployment**: Deploy and manage MCP servers in Kubernetes
- clusters using the ToolHive operator.
+- Cross-platform [desktop app](https://github.com/stacklok/toolhive-studio) and
+ browser-based [cloud UI](https://github.com/stacklok/toolhive-cloud-ui)
+- Make it easy for end users to discover and deploy MCP servers
+- Install MCP servers with a single click
+- Connect with local clients like Claude Desktop, Cursor, VS Code, and many more
## Additional resources
@@ -132,9 +191,15 @@ with other ToolHive users, ask questions, and share your experiences.
Source code and issue tracking:
-- ToolHive UI
- - [GitHub repository](https://github.com/stacklok/toolhive-studio)
- - [Issue tracker](https://github.com/stacklok/toolhive-studio/issues)
- ToolHive CLI & K8s Operator
- [GitHub repository](https://github.com/stacklok/toolhive)
- [Issue tracker](https://github.com/stacklok/toolhive/issues)
+- ToolHive UI
+ - [GitHub repository](https://github.com/stacklok/toolhive-studio)
+ - [Issue tracker](https://github.com/stacklok/toolhive-studio/issues)
+- ToolHive Registry Server
+ - [GitHub repository](https://github.com/stacklok/toolhive-registry-server)
+ - [Issue tracker](https://github.com/stacklok/toolhive-registry-server/issues)
+- ToolHive Cloud UI (experimental)
+ - [GitHub repository](https://github.com/stacklok/toolhive-cloud-ui)
+ - [Issue tracker](https://github.com/stacklok/toolhive-cloud-ui/issues)
diff --git a/src/components/ProductCard/assets/product-card-hover.png b/src/components/ProductCard/assets/product-card-hover.png
deleted file mode 100644
index e6ca5c3b..00000000
Binary files a/src/components/ProductCard/assets/product-card-hover.png and /dev/null differ
diff --git a/src/components/ProductCard/assets/product-card-hover.svg b/src/components/ProductCard/assets/product-card-hover.svg
new file mode 100644
index 00000000..11622dd0
--- /dev/null
+++ b/src/components/ProductCard/assets/product-card-hover.svg
@@ -0,0 +1,44 @@
+
diff --git a/src/components/ProductCard/index.tsx b/src/components/ProductCard/index.tsx
index 0066120a..cfb18349 100644
--- a/src/components/ProductCard/index.tsx
+++ b/src/components/ProductCard/index.tsx
@@ -135,7 +135,7 @@ export default function ProductCard(props: ProductCardProps) {
logoDark,
logoAlt = '',
logoTitle = '',
- invertLogoOnHover = true,
+ invertLogoOnHover = false,
description,
} = props;
diff --git a/src/components/ProductCard/styles.module.css b/src/components/ProductCard/styles.module.css
index cce46af2..4abd7198 100644
--- a/src/components/ProductCard/styles.module.css
+++ b/src/components/ProductCard/styles.module.css
@@ -5,7 +5,10 @@
/* CSS Custom Properties for theming */
.card {
- --card-background: var(--product-card-background-color, #e2e2dc);
+ --card-background: var(
+ --product-card-background-color,
+ var(--ifm-card-background-color)
+ );
--card-text-color: var(--product-card-text-color, var(--ifm-color-content));
--card-primary-color: var(
--product-card-primary-color,
@@ -41,14 +44,10 @@
/* Default hover effect */
.card:hover {
border-color: var(--card-primary-color);
- /* disabled for now
- background-color: var(--ifm-color-emphasis-100);
- background-image: url('./assets/product-card-hover.png');
+ background-image: url('./assets/product-card-hover.svg');
background-repeat: no-repeat;
- background-size: cover;
+ background-size: 80% auto;
background-position: bottom right;
- color: #ffffff;
-*/
text-decoration: none;
}
@@ -117,14 +116,6 @@
transition: color var(--ifm-transition-fast)
var(--ifm-transition-timing-default);
}
-/*
-.card:hover .titleHeading {
- color: #ffffff;
-}
-*/
-.card--hover-none:hover .titleHeading {
- color: var(--card-text-color);
-}
/* Logo inversion on hover (only in light mode and when specified) */
[data-theme='light'] .card:hover .invertOnHover {
@@ -146,11 +137,7 @@
transition: color var(--ifm-transition-fast)
var(--ifm-transition-timing-default);
}
-/*
-.card:hover .body {
- color: #ffffff;
-}
-*/
+
.card--hover-none:hover .body {
color: var(--card-text-color);
}
@@ -168,11 +155,7 @@
.card .link::after {
content: ' ↗';
}
-/*
-.card:hover .link {
- color: #ffffff;
-}
-*/
+
.card--hover-none:hover .link {
color: var(--card-text-color);
}
diff --git a/src/css/custom.css b/src/css/custom.css
index 87f86470..fb762ec8 100644
--- a/src/css/custom.css
+++ b/src/css/custom.css
@@ -311,17 +311,12 @@ details summary:hover {
}
/* Card components for category generated-index pages */
-/*
.card:hover {
- background-image: url('/img/card-hover.png');
+ background-image: url('/img/doc-card-hover.svg');
background-repeat: no-repeat;
- background-size: cover;
-}
-
-[data-theme='light'] .card:hover {
- color: #FAFEFA;
+ background-size: 50% auto;
+ background-position: bottom right;
}
-*/
/* Theme-aware icon styling for inline SVG icons */
.theme-icon {
diff --git a/src/pages/index.module.css b/src/pages/index.module.css
index 32f7dd07..4f666187 100644
--- a/src/pages/index.module.css
+++ b/src/pages/index.module.css
@@ -13,7 +13,9 @@
text-align: center;
position: relative;
overflow: hidden;
- background: url('/img/stacklok-pattern-2.svg') no-repeat center center;
+ background-color: #b2e4bc !important;
+ background: url('/img/stacklok-pattern-2-transparent.svg') no-repeat center
+ center;
background-size: cover;
color: #212121;
}
diff --git a/src/pages/index.tsx b/src/pages/index.tsx
index 71db21ec..4026f3e2 100644
--- a/src/pages/index.tsx
+++ b/src/pages/index.tsx
@@ -42,7 +42,6 @@ export default function Home(): ReactNode {
href='/toolhive'
logo='/img/logos/toolhive-default-black.svg'
logoDark='/img/logos/toolhive-default-white.svg'
- invertLogoOnHover={false}
logoAlt='ToolHive logo'
logoTitle='ToolHive logo'
linkText='Read documentation'
@@ -54,13 +53,12 @@ export default function Home(): ReactNode {
}}
alt='ToolHive symbol'
style={{
- width: '150px',
+ width: '120px',
height: 'auto',
float: 'right',
marginLeft: '1.5rem',
display: 'block',
maxWidth: '40%',
- borderRadius: '25px',
}}
/>
ToolHive simplifies the deployment and management of Model Context
@@ -70,12 +68,38 @@ export default function Home(): ReactNode {
-
- Yardstick is an MCP server and client reference implementation for
- deterministic testing.
+ A Buildkite plugin to run MCP servers in your CI/CD pipelines using
+ ToolHive.