Kong Konnect API와 상호 작용하기 위한 MCP(Model Context Protocol) 서버로, AI 어시스턴트가 Kong Gateway 구성, 트래픽 및 분석을 쿼리하고 분석할 수 있습니다.
https://github.com/user-attachments/assets/19c2f716-49b5-46c3-9457-65b3784e2111
Related MCP server: RL-MCP
이 프로젝트는 Claude와 같은 AI 비서가 Kong Konnect의 API 게이트웨이와 상호 작용할 수 있도록 하는 모델 컨텍스트 프로토콜(MCP) 서버를 제공합니다. 분석 데이터를 쿼리하고, 구성 세부 정보를 검사하고, 자연어 대화를 통해 제어 영역을 관리할 수 있는 도구 세트를 제공합니다.
주요 특징:
사용자 정의 가능한 필터를 사용한 쿼리 API 요청 분석
게이트웨이 서비스, 경로, 소비자 및 플러그인을 나열하고 검사합니다.
제어 평면 및 제어 평면 그룹 관리
Claude 및 기타 MCP 호환 AI 어시스턴트와의 통합
Konnect MCP는 현재 진행 중인 작업 이며, 각 릴리스마다 새로운 기능과 개선 사항을 추가할 예정입니다.
지엑스피1
Node.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 buildMCP 서버를 구성하려면 다음 환경 변수를 설정하세요.
# 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 Gateway 요청을 쿼리하고 분석합니다.
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 checkClaude for Desktop과 함께 이 MCP 서버를 사용하려면:
데스크톱용 Claude 설치
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를 다시 시작하세요
이제 Claude가 Kong Konnect 도구를 사용할 수 있습니다.
먼저 모든 제어 평면을 나열하세요.
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
