Skip to content

Options

Options for @kubb/plugin-mcp, which generates an MCP server where each OpenAPI operation becomes a typed tool handler.

Option Type Default Description
output Output { path: 'mcp', barrel: { type: 'named' } } Where the generated handlers are written and exported
group Group Split output into per-tag or per-path folders
client 'fetch' | 'axios' Which registered client plugin the handlers call
include Array<Include> Keep only operations that match
exclude Array<Exclude> Skip operations that match
override Array<Override> Apply different options per pattern
resolver ResolverPatch<ResolverMcp> Customize generated names and file paths
macros Array<Macro> Rewrite AST nodes before printing

output

Where the generated MCP handler files are written and how they are exported.

output.path

Folder where the plugin writes its files, resolved against the global output.path on defineConfig and defaulting to mcp. To write everything into a single file, set output.mode: 'file' and give path a file name with its extension, such as mcp.ts.

output.mode

How the plugin consolidates its generated code. 'file' (the default) writes everything into a single file whose output.path must include the extension, and 'directory' writes one file per operation under output.path.

output.barrel

Toggle the export style and depth to see the generated barrels.

  • src/gen/
  • models/
  • Pet.ts
  • User.ts
  • clients/
  • pet/
  • getPetById.ts
  • store/
  • getInventory.ts
src/gen/index.ts

Controls how the generated index.ts (barrel) re-exports the output. Defaults to { type: 'named' }, and also accepts { type: 'all' }, { nested: true }, or false.

output.banner

Text added to the top of every generated file, such as a license header or @ts-nocheck directive. Pass a string, or a function (meta: BannerMeta) => string that receives the document info (title, description, version, baseURL) and per-file context (filePath, baseName, isBarrel, isAggregation), so a directive can skip barrel files.

Text added to the bottom of every generated file (string or (meta: BannerMeta) => string), like banner but for closing comments. Pair banner: '/* eslint-disable */' with footer: '/* eslint-enable */' to scope a lint disable to the generated file.

group

Switch the mode to see where these operations land on disk.

clients/pet/
  • getPetById
  • addPet
clients/store/
  • getInventory
clients/order/
  • placeOrder
  • getOrderById
clients/user/
  • loginUser
group: { type: "tag" } splits the output by the operation tag, so placeOrder follows its order tag.

Splits generated files into subfolders by the operation's tag or URL path, each under {output.path}/{groupName}/. Without group, every file lands directly in output.path. It applies only to output.mode: 'directory'.

IMPORTANT

Combining group with output.mode: 'file' stops the build with a KUBB_INVALID_PLUGIN_OPTIONS error.

group.type

Property used to assign each operation to a group ('tag' | 'path'), required whenever group is set. An operation with no tag goes in the default group.

  • 'tag' uses the operation's first tag.
  • 'path' uses the first URL segment, such as pet for /pet/{petId}.

group.name

Function that turns a group key into the subdirectory name under output.path. It defaults to the camelCased tag for tag groups and the first URL segment as-is for path groups. The server.ts and .mcp.json files keep their fixed names at the root of output.path.

client

Selects which registered client plugin the handlers call, 'fetch' for @kubb/plugin-fetch or 'axios' for @kubb/plugin-axios. Each handler calls that client's generated <op> for the operation, passing one grouped { path, query, headers, body } object. A lone registered client plugin is auto-detected, so set this only to disambiguate when both are registered, and transport options such as baseURL live on the client plugin itself.

NOTE

The handlers call a client plugin's functions, so register @kubb/plugin-fetch or @kubb/plugin-axios alongside this one.

include

Generates only the operations and schemas that match at least one entry, and skips the rest. Each entry filters by tag, operationId, path, method, contentType, or schemaName, with a pattern that is a string (exact) or a RegExp (fuzzy).

Type definition
typescript
export type Include = {
  type: 'tag' | 'operationId' | 'path' | 'method' | 'contentType' | 'schemaName'
  pattern: string | RegExp
}

exclude

Skips any operation or schema that matches at least one entry, the opposite of include. Entries use the same type and pattern fields as include, and when both options match an item, exclude wins.

override

Applies different plugin options to operations that match a pattern. Each entry takes the same type and pattern as include, plus an options object that accepts any plugin option except override, so rules cannot nest. The first matching entry merges onto the plugin defaults, and later entries do not stack.

Type definition
typescript
export type Override = {
  type: 'tag' | 'operationId' | 'path' | 'method' | 'contentType' | 'schemaName'
  pattern: string | RegExp
  options: Omit<Partial<Options>, 'override'>
}

resolver

Changes how the plugin names generated files and symbols. Pass a partial patch. Override only the members you want, and anything you omit keeps resolverMcp. See Override a resolver for the this context and how a patch layers over the default.

TIP

Inside a method this is the full resolver, so this.default.name(name) reuses the built-in casing.

Partial override
typescript
type ResolverMcpPatch = {
  name?(name: string): string
  file?: {
    baseName?(params: { name: string; extname: string }): string
    path?(params: { baseName: string; output: Output }): string
  }
  handler?: {
    name?(node: OperationNode): string     // → 'showPetByIdHandler'
  }
}

macros

Rewrites AST nodes before they are printed, without forking the generator. Each macro callback (such as schema or operation) receives the node and a context object, and returns a replacement or undefined to leave it as is. Omitted callbacks keep their defaults, and macros run in order, so a later one sees the output of an earlier one.