Skip to main content
Glama
patternfly

PatternFly MCP Server

Official
by patternfly
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

searchPatternFlyDocs

Search PatternFly documentation, component names, and resource URIs by keyword, version, or wildcard, then pass results to the retrieval tool for guides and schemas.

Instructions

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

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
collectionNoFilter results by a primary collection of records (e.g. "patternfly-api", "patternfly-component-schemas", "patternfly-docs", "ai-handbook")
searchQueryYesCase-insensitive query for full or partial keywords, resource names, versions and more (e.g., "button", "card v6", "react", "*")

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv2.5.0
    • addedInput schema / properties / collection
      Added value: +{
+  "description": "Filter results by a primary collection of records (e.g. \"patternfly-api\", \"patternfly-component-schemas\", \"patternfly-docs\", \"ai-handbook\")",
+  "type": "string"
+}
    • changedInput schema / properties / searchQuery / description
      Previous 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\", \"*\")"
    • removedInput schema / properties / version
      Removed value: -{
-  "description": "Filter results by a specific PatternFly version (e.g. \"current\", \"latest\", \"v6\")",
-  "enum": [
-    "current",
-    "latest",
-    "v6"
-  ],
-  "type": "string"
-}
  2. Addedv1.1.0

TDQS

A3.9/5.0
Behavior3/5

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.

Conciseness4/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines5/5

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.

Deploy Server

Other Tools