Provides PatternFly rules, documentation, and component schemas through MCP tools for search and retrieval.
Search PatternFly collections for components, docs, resource URIs, and guidance URLs (supports partial, version-specific, and wildcard queries).
Fetch markdown documentation and component JSON schemas by component/resource name or up to 15 patternfly:// URIs/URLs.
Filter results by collection (e.g., patternfly-api, patternfly-component-schemas, patternfly-docs, ai-handbook) or collection version (v5, v6).
Integrate with MCP clients/IDEs via npx or HTTP transport, or embed in Node.js applications.
Inspect and test the MCP interface using the MCP inspector.
Provides access to PatternFly React component documentation, design guidelines, accessibility information, and JSON schemas for PatternFly components.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@PatternFly MCP Server show me the schema for the Button component"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Model Context Protocol (MCP) server that provides access to PatternFly rules and documentation, built with Node.js.
The PatternFly MCP server is a comprehensive library resource for PatternFly. It is intended to be extensible to meet the needs of different teams and projects, from simple to complex, from design to development. Read more about our roadmap and how we've structured the server in our architecture docs.
NPM (or equivalent package manager)
Related MCP server: PatternFly MCP Server
The PatternFly MCP Server supports multiple configurations; see the usage documentation for details.
Unable to update to the required Node.js version? See pinned MCP configuration examples for earlier Node.js versions.
Minimal configuration
{
"mcpServers": {
"patternfly-mcp": {
"command": "npx",
"args": ["-y", "@patternfly/patternfly-mcp@latest"],
"description": "PatternFly rules and documentation"
}
}
}HTTP transport mode
{
"mcpServers": {
"patternfly-mcp": {
"command": "npx",
"args": ["-y", "@patternfly/patternfly-mcp@latest", "--http", "--port", "8080"],
"description": "PatternFly rules and documentation (HTTP transport)"
}
}
}See the MCP Server Configuration documentation for more examples.
Run the latest published package immediately via npx:
npx -y @patternfly/patternfly-mcp@latestOr with options
npx -y @patternfly/patternfly-mcp@latest --log-stderr --verbose# clone the repo, change the directory, npm install, npm run build, then in the repo context run...
npm startVisualize and test the packaged MCP interface:
npx -y @modelcontextprotocol/inspector npx -y @patternfly/patternfly-mcp@latestBuild from source and test a local built MCP interface:
# clone the repo, change the directory, npm install, npm run build, then in the repo context run...
npx -y @modelcontextprotocol/inspector node dist/cli.jsimport { start } from '@patternfly/patternfly-mcp';
// Remember to avoid using console.log and info, they pollute STDOUT
async function main() {
const server = await start();
// Graceful shutdown
process.on('SIGINT', async () => {
await server.stop();
process.exit(0);
});
}
main();See the development documentation for additional examples, CLI and embedded server options.
For comprehensive usage, development, and project state read the docs.
Architecture: Learn about our architecture, collections, and data sources.
Usage: Detailed guide on built-in tools, resources, and troubleshooting for general use.
Development: Reference for CLI options and tool plugins.
See SECURITY.md for vulnerability reporting and GOVERNANCE.md for how contributions are reviewed.
Contributing? Guidelines can be found here CONTRIBUTING.md.
If you're using an AI assistant to help with development in this repository, please prompt it to review the repo guidelines to ensure adherence to project conventions.
Guidelines for developer-agent interaction can be found in CONTRIBUTING.md.
Search collections and get component names with documentation and guidance URLs. Supports case-insensitive partial, version-specific (e.g., "card v5"), and all ("*") matches.
**Usage**:
1. Input a "searchQuery" to find documentation and guideline URLs, resource URIs, and component names.
2. Use the returned resource names OR URLs OR URIs OR version with the "usePatternFlyDocs" tool to get markdown documentation, guidelines, and component JSON schemas.
**Returns**:
- Component and resource names that can be used with "usePatternFlyDocs"
- Documentation and guideline URLs that can be used with "usePatternFlyDocs"
- Resource URIs that can be used with "usePatternFlyDocs" or directly as MCP resources
| Name | Required | Description | Default |
|---|---|---|---|
| collection | No | Filter results by a primary collection of records (e.g. "patternfly-api", "patternfly-component-schemas", "patternfly-docs", "ai-handbook") | |
| searchQuery | Yes | Case-insensitive query for full or partial keywords, resource names, versions and more (e.g., "button", "card v6", "react", "*") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full disclosure burden. It does characterize matching behavior (case-insensitive partial, version-specific like "card v5", wildcard "*") and enumerates the return categories, but it says nothing about result limits, pagination, or the read-only nature of the call.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core purpose, then structured Usage and Returns sections. Slightly repetitive in listing 'names OR URLs OR URIs OR version', but every section is short and carries information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the Returns section usefully enumerates what comes back and how each value type is consumed downstream. Combined with the workflow steps, an agent has enough to call the tool correctly; only pagination/limit behavior is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters are already documented in the schema. The description echoes the query semantics (partial keywords, versions, "*") but adds little syntax beyond what the schema examples already provide.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence states a specific verb and resource: searching collections to retrieve component names plus documentation and guidance URLs. It also names the downstream sibling usePatternFlyDocs, so the agent can distinguish this discovery tool from the retrieval tool, though it doesn't explicitly say what this tool is NOT for.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
A numbered usage section gives explicit workflow steps: supply searchQuery, then feed the returned names/URLs/URIs/versions into usePatternFlyDocs. The when-to-use condition and the handoff to the sibling are both spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get markdown documentation and component JSON schemas for PatternFly resources and components.
**Usage**:
1. Input a component or resource name (e.g., "Button", "Writing") OR a list of up to 15 patternfly:// URIs or documentation URLs at a time (typically from searchPatternFlyDocs results).
**Returns**:
- Markdown documentation
- Component JSON schemas, if available
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | The name of a PatternFly component or patternfly:// URI resource to fetch documentation for (e.g., "Button", "patternfly://docs/Button") | |
| urlList | No | The list of patternfly:// URIs or URLs to fetch the documentation from (max 15 at a time) | |
| version | No | Filter results by a specific collection version (e.g. "v5", "v6") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full disclosure burden. It does disclose the output shape (markdown docs, optional component JSON schemas) and the 15-item batch cap, but says nothing about authentication, rate limits, error behavior, or read-only status beyond the implied 'Get'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with a clear one-sentence purpose, then bolded Usage and Returns sections. Slightly header-heavy for a three-field tool, but every block conveys actionable information and there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Return values are summarized, which matters since there is no output schema. However, the description omits the version filter entirely and does not clarify what happens if both name and urlList are supplied or if neither is (0 required parameters) — a real gap given the schema allows an empty call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents name, urlList, and version thoroughly, including examples and the max-15 constraint. The description repeats the input forms but adds no new semantics, and it never mentions the version parameter at all.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: fetch markdown documentation and component JSON schemas for PatternFly components. The relationship to searchPatternFlyDocs is hinted at ('typically from searchPatternFlyDocs results'), suggesting this is the retrieval step after a search, but the distinction is not stated explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The Usage section clearly explains the two input modes (a name or a list of up to 15 URIs) and where the URIs come from (searchPatternFlyDocs results). It does not state when to prefer this tool over searchPatternFlyDocs, but the workflow context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v2.5.0searchPatternFlyDocs3 fields changedInput schema / properties / collectionAdded value: +{
+ "description": "Filter results by a primary collection of records (e.g. \"patternfly-api\", \"patternfly-component-schemas\", \"patternfly-docs\", \"ai-handbook\")",
+ "type": "string"
+}Input schema / properties / searchQuery / descriptionPrevious value: -"Full or partial resource or component name to search for (e.g., \"button\", \"react\", \"*\")"New value: +"Case-insensitive query for full or partial keywords, resource names, versions and more (e.g., \"button\", \"card v6\", \"react\", \"*\")"Input schema / properties / versionRemoved value: -{
- "description": "Filter results by a specific PatternFly version (e.g. \"current\", \"latest\", \"v6\")",
- "enum": [
- "current",
- "latest",
- "v6"
- ],
- "type": "string"
-}usePatternFlyDocs2 fields changedInput schema / properties / version / descriptionPrevious value: -"Filter results by a specific PatternFly version (e.g. \"current\", \"latest\", \"v6\")"New value: +"Filter results by a specific collection version (e.g. \"v5\", \"v6\")"Input schema / properties / version / enumRemoved value: -[
- "current",
- "latest",
- "v6"
-]v2.0.1usePatternFlyDocs5 fields changedInput schema / properties / name / descriptionPrevious value: -"The name of a PatternFly component or resource to fetch documentation for (e.g., \"Button\", \"Table\", \"Writing\")"New value: +"The name of a PatternFly component or patternfly:// URI resource to fetch documentation for (e.g., \"Button\", \"patternfly://docs/Button\")"Input schema / properties / urlList / descriptionPrevious value: -"The list of URLs to fetch the documentation from (max 15 at a time"New value: +"The list of patternfly:// URIs or URLs to fetch the documentation from (max 15 at a time)"Input schema / properties / urlList / items / formatAdded value: +"uri"Input schema / properties / urlList / items / maxLengthAdded value: +1500Input schema / properties / urlList / items / minLengthAdded value: +11v1.1.0componentSchemasfetchDocssearchPatternFlyDocsusePatternFlyDocs5 fields changedInput schema / properties / nameAdded value: +{
+ "description": "The name of a PatternFly component or resource to fetch documentation for (e.g., \"Button\", \"Table\", \"Writing\")",
+ "maxLength": 256,
+ "type": "string"
+}Input schema / properties / urlList / descriptionPrevious value: -"The list of urls to fetch the documentation from"New value: +"The list of URLs to fetch the documentation from (max 15 at a time"Input schema / properties / urlList / maxItemsAdded value: +15Input schema / properties / versionAdded value: +{
+ "description": "Filter results by a specific PatternFly version (e.g. \"current\", \"latest\", \"v6\")",
+ "enum": [
+ "current",
+ "latest",
+ "v6"
+ ],
+ "type": "string"
+}Input schema / requiredRemoved value: -[
- "urlList"
-]v1.0.0componentSchemasfetchDocsusePatternFlyDocsScored across 2 tools
The pair follows a clean search-then-fetch split: searchPatternFlyDocs returns names/URIs/URLs, usePatternFlyDocs consumes them. The only slight fuzziness is that 'usePatternFlyDocs' alone doesn't signal 'fetch content' without reading the description, but the two tools are not confusable in practice.
Both names use camelCase with a verb+PatternFly+Docs structure (searchPatternFlyDocs, usePatternFlyDocs), giving a predictable, parallel pattern. No mixed conventions or vague one-word verbs.
Two tools is deliberately minimal but justified: this is the canonical search/fetch pattern for a documentation server, and each tool has a distinct, non-redundant role. It sits at the thin end of the range but is well scoped.
Discovery (search, including wildcard and version-specific queries) plus retrieval of markdown docs and JSON schemas covers the core documentation use case with no dead ends. Minor gaps exist, such as no explicit enumeration of available versions or collections, but '*' search largely compensates.
Live React design-system APIs, patterns, and code validation so AI agents build real UI, not slop.
The Cortex MCP server provides read-only access to real-time engineering context from the Cortex developer portal, allowing AI coding assistants to answer natural language questions about your organization's catalog (microservices, libraries, domains, teams, infrastructure), scorecards (engineering standards and best practices), initiatives (goals and deadlines), and Engineering Intelligence metrics. It includes tools for querying documentation, tracking personal entities, and accessing AI-assisted insights across the entire Cortex ecosystem.
Patterns for designing and reviewing AI skills, agents, and multi-agent workflows. Find guidance on context economy, delegation, verification, and tool design; inspect claims, worked examples, maturity labels, and source references. Five read-only tools let agents discover relevant patterns, compare concise cards, read specific sections, and explore relationships. Hosted Streamable HTTP at https://agentic-atlas.dev/mcp/ — no installation, account, or API key required. Browse the atlas at https://agentic-atlas.dev/.
Your org's AI agents, tasks, runs, search, and brain files as MCP tools and resources.
