用于与 Kong Konnect API 交互的模型上下文协议 (MCP) 服务器，允许 AI 助手查询和分析 Kong Gateway 配置、流量和分析。
https://github.com/user-attachments/assets/19c2f716-49b5-46c3-9457-65b3784e2111
Related MCP server: RL-MCP
该项目提供了一个模型上下文协议 (MCP) 服务器，使 Claude 等 AI 助手能够与 Kong Konnect 的 API 网关进行交互。它提供了一套工具，用于查询分析数据、检查配置详细信息以及通过自然语言对话管理控制平面。
主要特点：
使用可自定义的过滤器查询 API 请求分析
列出并检查网关服务、路由、消费者和插件
管理控制平面和控制平面组
与 Claude 和其他兼容 MCP 的 AI 助手集成
Konnect MCP 是一项正在进行的工作，我们将在每个版本中添加额外的功能和改进。
src/
├── index.ts # Main entry point
├── api.ts # Kong API client
├── tools.ts # Tool definitions
├── parameters.ts # Zod schemas for tool parameters
├── prompts.ts # Detailed tool documentation
├── operations/
│ ├── analytics.ts # API request analytics operations
│ ├── configuration.ts # Services, routes, consumers, plugins
│ └── controlPlanes.ts # Control plane management
└── types.ts # Common type definitionsNode.js 20 或更高版本
具有 API 访问权限的 Kong Konnect 帐户
具有 MCP 功能的客户端（例如 Claude Desktop、Cursor 等...）
# Clone the repository
git clone https://github.com/Kong/mcp-konnect.git
cd mcp-konnect
# Install dependencies
npm install
# Build the project
npm run build设置以下环境变量来配置 MCP 服务器：
# Required: Your Kong Konnect API key
export KONNECT_ACCESS_TOKEN=kpat_api_key_here
# Optional: The API region to use (defaults to US)
# Possible values: US, EU, AU, ME, IN
export KONNECT_REGION=us该服务器提供的工具分为三类：
使用可定制的过滤器查询和分析 Kong API 网关请求。
Inputs:
- timeRange: Time range for data retrieval (15M, 1H, 6H, 12H, 24H, 7D)
- statusCodes: Filter by specific HTTP status codes
- excludeStatusCodes: Exclude specific HTTP status codes
- httpMethods: Filter by HTTP methods
- consumerIds: Filter by consumer IDs
- serviceIds: Filter by service IDs
- routeIds: Filter by route IDs
- maxResults: Maximum number of results to return分析特定消费者发出的 API 请求。
Inputs:
- consumerId: ID of the consumer to analyze
- timeRange: Time range for data retrieval
- successOnly: Show only successful (2xx) requests
- failureOnly: Show only failed (non-2xx) requests
- maxResults: Maximum number of results to return列出与控制平面相关的所有服务。
Inputs:
- controlPlaneId: ID of the control plane
- size: Number of services to return
- offset: Pagination offset token列出与控制平面相关的所有路由。
Inputs:
- controlPlaneId: ID of the control plane
- size: Number of routes to return
- offset: Pagination offset token列出与控制平面相关的所有消费者。
Inputs:
- controlPlaneId: ID of the control plane
- size: Number of consumers to return
- offset: Pagination offset token列出与控制平面相关的所有插件。
Inputs:
- controlPlaneId: ID of the control plane
- size: Number of plugins to return
- offset: Pagination offset token列出您组织中的所有控制平面。
Inputs:
- pageSize: Number of control planes per page
- pageNumber: Page number to retrieve
- filterName: Filter control planes by name
- filterClusterType: Filter by cluster type
- filterCloudGateway: Filter by cloud gateway capability
- labels: Filter by labels
- sort: Sort field and direction获取有关特定控制平面的详细信息。
Inputs:
- controlPlaneId: ID of the control plane to retrieve列出属于特定组的所有控制平面。
Inputs:
- groupId: Control plane group ID
- pageSize: Number of members to return per page
- pageAfter: Cursor for pagination检查控制平面是否是任何组的成员。
Inputs:
- controlPlaneId: Control plane ID to check要将此 MCP 服务器与 Claude for Desktop 一起使用：
创建或编辑 Claude Desktop 配置文件：
MacOS： ~/Library/Application Support/Claude/claude_desktop_config.json
Windows： %APPDATA%\Claude\claude_desktop_config.json
添加以下配置：
{
"mcpServers": {
"kong-konnect": {
"command": "node",
"args": [
"/absolute/path/to/mcp-konnect/build/index.js"
],
"env": {
"KONNECT_ACCESS_TOKEN": "kpat_api_key_here",
"KONNECT_REGION": "us"
}
}
}
}重启 Claude 桌面版
Kong Konnect 工具现在可供 Claude 使用
首先，列出所有控制平面：
Please list all control planes in my Kong Konnect organization.然后，列出特定控制平面的服务：
List all services for control plane [CONTROL_PLANE_NAME/ID].查询特定服务的 API 请求：
Show me all API requests for service [SERVICE_NAME/ID] in the last hour that had 5xx status codes.列出控制平面的消费者：
List all consumers for control plane [CONTROL_PLANE_NAME/ID].分析特定消费者的请求：
Show me all requests made by consumer [CONSUMER_NAME/ID] in the last 24 hours.检查常见错误或模式：
What are the most common errors experienced by this consumer?在parameters.ts中定义参数
在prompts.ts中添加文档
在operations/中的相应文件中创建操作逻辑
在tools.ts中注册该工具
在index.ts中处理工具执行
连接错误
验证您的 API 密钥是否有效并具有必要的权限
检查 API 区域是否正确指定
确保您的网络可以连接到 Kong Konnect API
身份验证错误
在 Kong Konnect 门户中重新生成您的 API 密钥
检查环境变量是否正确设置
未找到数据
验证请求中使用的 ID 是否正确
检查指定控制平面中是否存在资源
确保时间范围对于分析查询有效
由 Kong 构建。灵感来自 Stripe 的Agent Toolkit 。
Check if a control plane is a member of any group.
INPUT:
controlPlaneId: String - ID of the control plane to check
OUTPUT:
controlPlaneId: String - ID of the control plane that was checked
groupMembership: Object - Membership information including:
isMember: Boolean - Whether the control plane is a member of any group
groupId: String - ID of the group this control plane belongs to (if any)
groupName: String - Name of the group this control plane belongs to
status: String - Membership status (OK, CONFLICT, etc.)
message: String - Status message
conflicts: Array - List of configuration conflicts if any
relatedTools: Array - List of related tools for group management
| Name | Required | Description | Default |
|---|---|---|---|
| controlPlaneId | Yes | Control plane ID to check (can be obtained from list-control-planes tool) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries burden. It details output fields including conflicts, but does not state whether the operation is read-only or if there are side effects. Basic transparency but incomplete.
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 purpose, includes separate input/output sections, but slightly verbose by repeating input parameter description already in schema.
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?
Given no output schema, description provides detailed output structure with nested fields. However, lacks error handling or behavior for missing control plane ID, and no explanation of 'relatedTools'.
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 has 100% coverage for the single parameter, and the description repeats the schema's text. Adds no additional meaning beyond what schema provides.
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 description clearly states the tool checks if a control plane is a member of any group. It uses a specific verb and resource, and distinguishes from the sibling 'list_control_plane_group_memberships' which lists all memberships for a group.
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?
No explicit guidance on when to use this tool versus alternatives like 'list_control_plane_group_memberships' or 'list_control_planes'. Context is implied but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve and analyze API requests made by a specific consumer.
INPUT:
consumerId: String - ID of the consumer to analyze. The format of this field must be "controlPlaneID:consumerId".
timeRange: String - Time range for data retrieval (15M, 1H, 6H, 12H, 24H, 7D)
successOnly: Boolean - Filter to only show successful (2xx) requests (default: false)
failureOnly: Boolean - Filter to only show failed (non-2xx) requests (default: false)
maxResults: Number - Maximum number of results to return (1-1000)
OUTPUT:
metadata: Object - Contains consumerId, totalRequests, timeRange, and filters
statistics: Object - Usage statistics including:
averageLatencyMs: Number - Average response time in milliseconds
successRate: Number - Percentage of successful requests
statusCodeDistribution: Array - Breakdown of requests by status code
serviceDistribution: Array - Breakdown of requests by service
requests: Array - List of requests with details for each request
| Name | Required | Description | Default |
|---|---|---|---|
| timeRange | No | Time range for data retrieval (15M = 15 minutes, 1H = 1 hour, etc.) | 1H |
| consumerId | Yes | Consumer ID to filter by (obtainable from analyze-failed-requests or query-api-requests tools) | |
| maxResults | No | Number of items to return per page | |
| failureOnly | No | Show only failed (non-2xx) requests | |
| successOnly | No | Show only successful (2xx) requests |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Given no annotations, the description carries full burden. It details input and output but omits safety aspects (e.g., read-only nature, error handling, rate limits).
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?
Well-structured with INPUT/OUTPUT sections, but could be more concise; some parameter descriptions are repeated between schema and description.
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?
Covers all 5 parameters and output structure adequately for a complex analytics tool, though no output schema provided.
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 coverage is 100%, but description adds format constraint for consumerId and default values, going beyond the schema.
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 description clearly states the tool retrieves and analyzes API requests for a specific consumer, distinguishing it from siblings like query_api_requests or list_consumers.
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?
While it mentions consumerId can be obtained from other tools, it lacks explicit guidance on when to use this tool versus siblings like query_api_requests.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific control plane.
INPUT:
controlPlaneId: String - ID of the control plane to retrieve
OUTPUT:
controlPlaneDetails: Object - Detailed information including:
controlPlaneId: String - Unique identifier for the control plane
name: String - Display name of the control plane
description: String - Description of the control plane
type: String - Type of the control plane
clusterType: String - Underlying cluster type
controlPlaneEndpoint: String - URL endpoint for the control plane
telemetryEndpoint: String - URL endpoint for telemetry
hasCloudGateway: Boolean - Whether cloud gateway is enabled
labels: Object - Labels assigned to this control plane
metadata: Object - Creation and update timestamps
relatedTools: Array - List of related tools for further analysis
| Name | Required | Description | Default |
|---|---|---|---|
| controlPlaneId | Yes | Control Plane ID (obtainable from list-control-planes tool) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not state that the operation is read-only or disclose any behavioral traits such as permissions, rate limits, or side effects. The output format is detailed, but behavioral transparency is lacking.
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?
The description is structured with a clear first sentence followed by input and output bullet lists. It is somewhat verbose but each section adds value, especially the detailed output fields.
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?
The description covers input and output adequately but lacks context on error handling, prerequisites, or typical use cases. Given low complexity and no annotations, more completeness (e.g., mentioning read-only nature) would be expected.
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%, and the input schema already describes the parameter with format and origin. The tool description merely repeats the parameter name and type, adding no new meaning beyond what the schema provides.
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 description begins with 'Get detailed information about a specific control plane', using a specific verb and resource. It clearly distinguishes from sibling tools like list_control_planes (which lists all) and others dealing with different entities.
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?
No explicit guidance on when to use this tool vs alternatives. The input schema mentions obtaining the ID from list-control-planes, but the tool description does not, leaving usage context implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all consumers associated with a control plane.
INPUT:
controlPlaneId: String - ID of the control plane
size: Number - Number of consumers to return (1-1000, default: 100)
offset: String (optional) - Pagination offset token from previous response
OUTPUT:
metadata: Object - Contains controlPlaneId, size, offset, nextOffset, totalCount
consumers: Array - List of consumers with details for each including:
consumerId: String - Unique identifier for the consumer
username: String - Username for this consumer
customId: String - Custom identifier for this consumer
tags: Array - Tags associated with the consumer
enabled: Boolean - Whether the consumer is enabled
metadata: Object - Creation and update timestamps
relatedTools: Array - List of related tools for consumer analysis
| Name | Required | Description | Default |
|---|---|---|---|
| size | No | Number of consumers to return | |
| offset | No | Offset token for pagination (from previous response) | |
| controlPlaneId | Yes | Control Plane ID (obtainable from list-control-planes tool) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It explains the read-only listing behavior, pagination via offset, and output structure. It does not mention authorization or rate limits, but the core behavior is transparent.
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?
The description is well-structured with INPUT and OUTPUT sections, making it easy to scan. It is mostly concise but includes detailed output field descriptions that could be shortened without losing clarity.
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?
Given three parameters and no output schema, the description comprehensively covers input usage, output structure (including pagination metadata and consumer fields), and provides enough detail for correct invocation without missing critical information.
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 coverage is 100%, so baseline is 3. The description adds value by stating default values (size: 100), range (1-1000), and source for controlPlaneId (from list-control-planes tool), going beyond the schema.
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 description clearly states 'List all consumers associated with a control plane,' specifying the verb (list) and resource (consumers). It distinguishes from sibling tools like list_control_planes and list_services by targeting a different resource.
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 description provides clear context for when to use the tool (to list consumers for a given control plane) and includes practical guidance (controlPlaneId obtainable from list-control-planes tool). However, it does not explicitly exclude alternatives or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all control planes that are members of a specific control plane group.
INPUT:
groupId: String - ID of the control plane group (control plane that acts as the group)
pageSize: Number - Number of members to return per page (1-1000, default: 10)
pageAfter: String (optional) - Cursor for pagination after a specific item
OUTPUT:
metadata: Object - Contains groupId, pageSize, pageAfter, nextPageAfter, totalCount
members: Array - List of member control planes with details for each including:
controlPlaneId: String - Unique identifier for the control plane
name: String - Display name of the control plane
description: String - Description of the control plane
type: String - Type of the control plane
clusterType: String - Underlying cluster type
membershipStatus: Object - Group membership status including:
status: String - Current status (OK, CONFLICT, etc.)
message: String - Status message
conflicts: Array - List of configuration conflicts if any
metadata: Object - Creation and update timestamps
relatedTools: Array - List of related tools for group management
| Name | Required | Description | Default |
|---|---|---|---|
| groupId | Yes | Control plane group ID (the ID of the control plane that acts as the group) | |
| pageSize | No | Number of members to return per page | |
| pageAfter | No | Cursor for pagination after a specific item |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It explains pagination parameters, output structure including metadata and members array, and does not contradict any annotations. It could explicitly state it's read-only, but the behavior is well-described.
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?
The description is well-structured with headings (INPUT, OUTPUT) and front-loaded with the purpose. While somewhat lengthy, each section provides useful information without redundancy.
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?
Given 3 parameters, no output schema, and no annotations, the description is thorough: it covers input parameters, output structure with nested fields like membershipStatus, and pagination behavior. It is complete for a list tool.
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%, and the description adds value by explaining parameters in natural language, e.g., clarifying that groupId is the ID of a control plane acting as the group, which goes beyond the schema.
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 description explicitly states 'List all control planes that are members of a specific control plane group,' using a clear verb and resource. This distinguishes it from siblings like 'check_control_plane_group_membership' and 'list_control_planes'.
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 description provides clear context on input parameters and output, implying usage for listing members of a group. It does not explicitly state when not to use this tool or mention alternatives, but the intent is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all control planes in your organization.
INPUT:
pageSize: Number - Number of control planes per page (1-1000, default: 10)
pageNumber: Number (optional) - Page number to retrieve
filterName: String (optional) - Filter control planes by name
filterClusterType: String (optional) - Filter by cluster type (kubernetes, docker, etc.)
filterCloudGateway: Boolean (optional) - Filter by cloud gateway capability
labels: String (optional) - Filter by labels (format: 'key:value,existCheck')
sort: String (optional) - Sort field and direction (e.g. 'name,created_at desc')
OUTPUT:
metadata: Object - Contains pageSize, pageNumber, totalPages, totalCount, filters, sort
controlPlanes: Array - List of control planes with details for each including:
controlPlaneId: String - Unique identifier for the control plane
name: String - Display name of the control plane
description: String - Description of the control plane
type: String - Type of the control plane
clusterType: String - Underlying cluster type
controlPlaneEndpoint: String - URL endpoint for the control plane
telemetryEndpoint: String - URL endpoint for telemetry
hasCloudGateway: Boolean - Whether cloud gateway is enabled
labels: Object - Labels assigned to this control plane
metadata: Object - Creation and update timestamps
usage: Object - Information about how to use these results
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | Sort field and direction (e.g. 'name,created_at desc') | |
| labels | No | Filter by labels (format: 'key:value,existCheck') | |
| pageSize | No | Number of control planes per page | |
| filterName | No | Filter control planes by name (contains) | |
| pageNumber | No | Page number to retrieve | |
| filterClusterType | No | Filter by cluster type (e.g., 'kubernetes', 'docker') | |
| filterCloudGateway | No | Filter by cloud gateway capability |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and comprehensively discloses behavior: pagination, filtering, output structure. It clearly indicates a read-only list operation with no destructive hints.
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?
The description is well-structured with INPUT/OUTPUT sections and bullet points. It is front-loaded with the core purpose, though the output list is fairly detailed. Could be slightly more concise.
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?
Given 7 parameters, no output schema, and no annotations, the description fully covers input options and output structure, including pagination metadata. It is complete for a list endpoint.
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 coverage is 100% and repeats the same descriptions (e.g., labels format, pageSize default). The description adds minimal new meaning beyond ensuring clarity in the structured input section.
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 description clearly states 'List all control planes in your organization,' which is a specific verb+resource pair. It distinguishes itself from sibling tools like get_control_plane (singular) by implying a plural listing operation.
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 description provides no guidance on when to use this tool versus alternatives (e.g., get_control_plane for a single resource). It lists filters but does not explain scenarios where filtering is preferred over other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all plugins associated with a control plane.
INPUT:
controlPlaneId: String - ID of the control plane
size: Number - Number of plugins to return (1-1000, default: 100)
offset: String (optional) - Pagination offset token from previous response
includeRawConfig: Boolean - Requests raw plugin configuration values. Defaults to false and only takes effect when the server policy env var allows raw config responses.
OUTPUT:
metadata: Object - Contains controlPlaneId, size, offset, nextOffset, totalCount, raw-config policy flags, and warnings when applicable
plugins: Array - List of plugins with details for each including:
pluginId: String - Unique identifier for the plugin
name: String - Name of the plugin (e.g., rate-limiting, cors, etc.)
enabled: Boolean - Whether the plugin is enabled
configIncluded: Boolean - Whether raw config values were included
configKeys: Array - Returned by default to summarize configuration without exposing raw values
configEntryCount: Number - Returned by default to summarize configuration size
config: Object - Raw plugin-specific configuration, only when includeRawConfig is explicitly true and server policy allows it
protocols: Array - Protocols this plugin applies to
tags: Array - Tags associated with the plugin
scoping: Object - Defines plugin scope including:
consumerId: String - Consumer this plugin applies to (if any)
serviceId: String - Service this plugin applies to (if any)
routeId: String - Route this plugin applies to (if any)
global: Boolean - Whether this is a global plugin
metadata: Object - Creation and update timestamps
relatedTools: Array - List of related tools for plugin configuration
Raw config is excluded by default. Raw config is only returned when includeRawConfig is explicitly true and the server is configured with KONNECT_ALLOW_RAW_PLUGIN_CONFIG=true. Even then, plugin configuration may contain sensitive values.
| Name | Required | Description | Default |
|---|---|---|---|
| size | No | Number of plugins to return | |
| offset | No | Offset token for pagination (from previous response) | |
| controlPlaneId | Yes | Control Plane ID (obtainable from list-control-planes tool) | |
| includeRawConfig | No | Include raw plugin configuration values. Disabled by default because configuration may contain sensitive data. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description fully discloses behavior: raw config exclusion by default, enabling only with includeRawConfig=true and server env var, pagination via offset, size limits, and warnings about sensitive data. This exceeds what the schema provides.
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?
The description is long but well-structured with INPUT/OUTPUT sections. Each sentence is informative; some redundancy with schema (e.g., size default) but not excessive. Front-loaded purpose makes it easy to scan. Could be slightly more concise, but overall efficient.
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?
Despite lacking an output schema, the description fully details the output structure including conditional fields (config). It covers pagination, raw config behavior, and scoping fields. No gaps are evident for an agent to invoke the tool correctly.
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 baseline is 3. The description adds value by explaining includeRawConfig policy dependency and controlPlaneId as obtainable from another tool. It also clarifies the offset as a token from previous response. This adds useful context beyond schema.
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?
Description starts with 'List all plugins associated with a control plane' – a clear verb and resource. Sibling tools are all for different resources (control planes, consumers, routes, etc.), so this tool is distinct and unambiguously about plugins.
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 description does not explicitly state when to use this versus alternatives, but sibling tools cover different resources, making the context clear. The detailed input/output sections help the agent understand usage. Lacks explicit 'use when' or 'instead of' guidance, but the resource specificity is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all routes associated with a control plane.
INPUT:
controlPlaneId: String - ID of the control plane
size: Number - Number of routes to return (1-1000, default: 100)
offset: String (optional) - Pagination offset token from previous response
OUTPUT:
metadata: Object - Contains controlPlaneId, size, offset, nextOffset, totalCount
routes: Array - List of routes with details for each including:
routeId: String - Unique identifier for the route
name: String - Display name of the route
protocols: Array - Protocols this route accepts (http, https, grpc, etc.)
methods: Array - HTTP methods this route accepts
hosts: Array - Hostnames this route matches
paths: Array - URL paths this route matches
stripPath: Boolean - Whether to strip the matched path prefix
preserveHost: Boolean - Whether to preserve the host header
serviceId: String - ID of the service this route forwards to
enabled: Boolean - Whether the route is enabled
metadata: Object - Creation and update timestamps
relatedTools: Array - List of related tools for further analysis
| Name | Required | Description | Default |
|---|---|---|---|
| size | No | Number of routes to return | |
| offset | No | Offset token for pagination (from previous response) | |
| controlPlaneId | Yes | Control Plane ID (obtainable from list-control-planes tool) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It describes the listing operation and pagination behavior, but it does not explicitly state that the tool is read-only, idempotent, or free of side effects. While listing is inherently non-destructive, explicit transparency about behavioral traits like rate limits or authentication is missing.
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?
The description is front-loaded with the purpose, but it is overly verbose with a full Output section listing all fields. Since no output schema exists, the detailed output description may be helpful, but it could be streamlined. The structure is clear but not optimally concise.
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?
For a list tool with 3 parameters and no output schema, the description covers input and output well, including pagination details. However, it lacks information about error conditions, rate limits, or required permissions. Overall, it provides sufficient context for an agent to understand what the tool does and what it returns.
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 coverage is 100%, so the baseline is 3. The description adds negligible value: it repeats schema definitions for 'size' and 'offset' (e.g., 'Number of routes to return (1-1000, default: 100)' matches schema) and provides a less informative description for 'controlPlaneId' than the schema's hint about obtaining it from another tool.
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 description starts with 'List all routes associated with a control plane', which is a specific verb ('List') and resource ('routes') combined with a necessary qualifier ('associated with a control plane'). This clearly identifies the tool's function and distinguishes it from sibling tools like list_services or list_consumers.
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 description implies usage context by mentioning 'controlPlaneId' and the input schema hints to obtain it via 'list-control-planes', but it does not explicitly state when to use this tool versus alternatives (e.g., list_services or get_control_plane). No exclusions or when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all services associated with a control plane.
INPUT:
controlPlaneId: String - ID of the control plane
size: Number - Number of services to return (1-1000, default: 100)
offset: String (optional) - Pagination offset token from previous response
OUTPUT:
metadata: Object - Contains controlPlaneId, size, offset, nextOffset, totalCount
services: Array - List of services with details for each including:
serviceId: String - Unique identifier for the service
name: String - Display name of the service
host: String - Target host for the service
port: Number - Target port for the service
protocol: String - Protocol used (http, https, grpc, etc.)
path: String - Path prefix for the service
retries: Number - Number of retries on failure
connectTimeout: Number - Connection timeout in milliseconds
writeTimeout: Number - Write timeout in milliseconds
readTimeout: Number - Read timeout in milliseconds
tags: Array - Tags associated with the service
enabled: Boolean - Whether the service is enabled
metadata: Object - Creation and update timestamps
relatedTools: Array - List of related tools for further analysis
| Name | Required | Description | Default |
|---|---|---|---|
| size | No | Number of services to return | |
| offset | No | Offset token for pagination (from previous response) | |
| controlPlaneId | Yes | Control Plane ID (obtainable from list-control-planes tool) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions pagination and required fields but does not explicitly state that the tool is read-only or discuss side effects, permissions, or rate limits.
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?
The description is well-structured with INPUT and OUTPUT sections, front-loading the purpose. It is fairly detailed but appropriate for the complexity, though it could be slightly more concise.
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?
Despite lacking an output schema, the description fully documents the output structure. It covers all parameters, pagination, and required fields, making it complete for the tool's complexity.
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 coverage is 100%, but the description adds context such as offset being from a previous response and size having a default and range, going beyond the schema's basic descriptions.
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 description clearly states 'List all services associated with a control plane,' using a specific verb and resource. It distinguishes from sibling tools like list_consumers or list_routes by focusing on services.
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 description implies usage by listing inputs and output but does not explicitly state when to use this tool over alternatives or when not to use it. No exclusions or context for sibling tools are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Query and analyze Kong API Gateway requests with customizable filters. Before calling this it's necessary to have a controlPlaneID and a serviceID or routeID. These can be obtained using the list-control-planes, list-services, and list-routes tools.
INPUT:
timeRange: String - Time range for data retrieval (15M, 1H, 6H, 12H, 24H, 7D)
statusCodes: Number[] (optional) - Filter by specific HTTP status codes
excludeStatusCodes: Number[] (optional) - Exclude specific HTTP status codes
httpMethods: String[] (optional) - Filter by HTTP methods (e.g., GET, POST)
consumerIds: String[] (optional) - Filter by consumer IDs
serviceIds: String[] (optional) - Filter by service IDs. The format of this field must be ":".
routeIds: String[] (optional) - Filter by route IDs. The format of this field must be "controlPlaneID:routeID"
maxResults: Number - Maximum number of results to return (1-1000)
OUTPUT:
metadata: Object - Contains totalRequests, timeRange, and applied filters
requests: Array - List of request objects with details including:
requestId: String - Unique request identifier
timestamp: String - When the request occurred
httpMethod: String - HTTP method used (GET, POST, etc.)
uri: String - Request URI path
statusCode: Number - HTTP status code of the response
consumerId: String - ID of the consumer making the request
serviceId: String - ID of the service handling the request
routeId: String - ID of the matched route
latency: Object - Response time metrics
clientIp: String - IP address of the client
and many more detailed fields...
| Name | Required | Description | Default |
|---|---|---|---|
| routeIds | No | Filter by route IDs (from list-routes tool) | |
| timeRange | No | Time range for data retrieval (15M = 15 minutes, 1H = 1 hour, etc.) | 1H |
| maxResults | No | Number of items to return per page | |
| serviceIds | No | Filter by service IDs | |
| consumerIds | No | Filter by consumer IDs | |
| httpMethods | No | Filter by HTTP methods (e.g. ['GET', 'POST', 'DELETE']) | |
| statusCodes | No | Filter by specific HTTP status codes (e.g. [200, 201, 404]) | |
| excludeStatusCodes | No | Exclude specific HTTP status codes (e.g. [400, 401, 500]) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description notes required format for IDs and default time range, but lacks explicit statements on read-only nature, rate limits, or error handling.
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?
Well-structured with intro, prerequisites, input/output sections. Minor vagueness in 'and many more detailed fields...' but overall efficient.
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?
No output schema, but description provides detailed output structure. Covers all parameters and dependencies. Lacks edge case and error handling details.
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 coverage is 100% (baseline 3). Description adds extra context: explains timeRange enum meanings and details the special format for serviceIds/routeIds beyond schema constraints.
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?
Description clearly states the tool queries and analyzes Kong API Gateway requests with customizable filters, distinct from sibling tools that list entities.
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?
Explicitly states prerequisites (controlPlaneID, serviceID/routeID) and references sibling tools to obtain them, providing clear when-to-use guidance.
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.
v1.0.1check_control_plane_group_membership1 field changedInput schema / properties / controlPlaneId / formatAdded value: +"uuid"get_control_plane1 field changedInput schema / properties / controlPlaneId / formatAdded value: +"uuid"list_consumers1 field changedInput schema / properties / controlPlaneId / formatAdded value: +"uuid"list_control_plane_group_memberships1 field changedInput schema / properties / groupId / formatAdded value: +"uuid"list_plugins2 fields changedInput schema / properties / controlPlaneId / formatAdded value: +"uuid"Input schema / properties / includeRawConfigAdded value: +{
+ "default": false,
+ "description": "Include raw plugin configuration values. Disabled by default because configuration may contain sensitive data.",
+ "type": "boolean"
+}list_routes1 field changedInput schema / properties / controlPlaneId / formatAdded value: +"uuid"list_services1 field changedInput schema / properties / controlPlaneId / formatAdded value: +"uuid"check_control_plane_group_membershipget_consumer_requestsget_control_planelist_consumerslist_control_plane_group_membershipslist_control_planeslist_pluginslist_routeslist_servicesquery_api_requestsScored across 10 tools
Each tool has a clearly distinct purpose targeting a specific resource (e.g., control planes, consumers, plugins) or action (check, get, list, query), with no overlapping functionality.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., list_control_planes, get_control_plane, query_api_requests), with no deviations.
With 10 tools, the set is well-scoped for managing Kong Konnect resources, covering control planes, consumers, plugins, routes, services, and API analytics without being overly large or sparse.
The tool set is read-only (only get, list, check, query operations), lacking any create, update, or delete operations for the managed resources, which is a significant gap for full lifecycle management typically expected in an API management context.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Model Context Protocol server for the Apideck Unified API. Connect any MCP-compatible agent framework to 100+ accounting systems, HRIS platforms, file storage providers, and more through one integration. More information https://www.apideck.com/mcp-server
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.
A Model Context Protocol server for Wix AI tools
