The Kong Konnect MCP Server enables AI assistants to interact with Kong Konnect's API Gateway for analytics, configuration management, and control plane operations.
Capabilities include:
Query and analyze API requests with filters for time range, status codes, HTTP methods, and consumer/service/route IDs
Analyze specific consumer requests with success/failure filters and detailed statistics
Inspect and manage gateway components including services, routes, consumers, and plugins
Control plane management:
List and filter control planes
Retrieve detailed control plane information
Manage control plane group memberships
Check membership status
Integration with AI assistants for natural language interaction
Extensible architecture for adding new tools and operations
Enables interaction with Kong Konnect APIs, allowing users to query API Gateway analytics, inspect configuration details (services, routes, consumers, plugins), and manage control planes through a structured interface.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Kong Konnect MCP Server show me the top 5 services by request volume in the last hour"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
This project is no longer actively maintained and will be archived as read-only.
No further updates, bug fixes, or new features will be made. Issues and pull requests are no longer monitored.
If you're looking for Kong Konnect MCP support, please check the Konnect remote MCP server.
Note: This repository is deprecated and will soon be archived as read-only. See the notice above for details.
A Model Context Protocol (MCP) server for interacting with Kong Konnect APIs, allowing AI assistants to query and analyze Kong Gateway configurations, traffic, and analytics.
Related MCP server: RL-MCP
⚠️ Deprecated: This project is no longer maintained. The information below is preserved for reference only.
This project provides a Model Context Protocol (MCP) server that enables AI assistants like Claude to interact with Kong Konnect's API Gateway. It offers a set of tools to query analytics data, inspect configuration details, and manage control planes through natural language conversation.
Key features:
Query API request analytics with customizable filters
List and inspect gateway services, routes, consumers, and plugins
Manage control planes and control plane groups
Integration with Claude and other MCP-compatible AI assistants
build/ # Committed compiled JavaScript output used by the release/distribution flow
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 definitionsNote: As this project is deprecated, no support is provided for installation issues.
Node.js 20 or higher
A Kong Konnect account with API access
A client with MCP capabilities (e.g. Claude Desktop, Cursor, etc...)
# Clone the repository
git clone https://github.com/Kong/mcp-konnect.git
cd mcp-konnect
# Install dependencies
npm install
# Run the test suite (also rebuilds compiled output)
npm test
# Rebuild the committed build artifacts after changing src/
npm run buildThe repository includes committed files under build/ as part of its distribution model. If you modify files in src/, regenerate build/ before committing or publishing changes.
Set the following environment variables to configure the MCP server:
# 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=usThe server provides tools organized in three categories:
Query and analyze Kong API Gateway requests with customizable filters.
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 returnAnalyze API requests made by a specific consumer.
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 returnList all services associated with a control plane.
Inputs:
- controlPlaneId: Control plane ID
- size: Number of services to return
- offset: Pagination offset tokenList all routes associated with a control plane.
Inputs:
- controlPlaneId: Control plane ID
- size: Number of routes to return
- offset: Pagination offset tokenList all consumers associated with a control plane.
Inputs:
- controlPlaneId: Control plane ID
- size: Number of consumers to return
- offset: Pagination offset tokenList all plugins associated with a control plane.
Inputs:
- controlPlaneId: Control plane ID
- size: Number of plugins to return
- offset: Pagination offset token
- includeRawConfig: Set to true to include raw plugin configuration values (defaults to false)List all control planes in your organization.
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 directionGet detailed information about a specific control plane.
Inputs:
- controlPlaneId: Control plane ID to retrieveList all control planes that are members of a specific group.
Inputs:
- groupId: Control plane group ID
- pageSize: Number of members to return per page
- pageAfter: Cursor for paginationCheck if a control plane is a member of any group.
Inputs:
- controlPlaneId: Control plane ID to checkNote: This configuration is provided for historical reference. No support is available for setup issues.
To use this MCP server with Claude for Desktop:
Install Claude for Desktop
Create or edit the Claude Desktop configuration file:
MacOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
Add the following configuration:
{
"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"
}
}
}
}Restart Claude for Desktop
The Kong Konnect tools will now be available for Claude to use
First, list all control planes:
Please list all control planes in my Kong Konnect organization.Then, list services for a specific control plane:
List all services for control plane [CONTROL_PLANE_ID].Query API requests for a specific service:
Show me all API requests for service [SERVICE_NAME/ID] in the last hour that had 5xx status codes.List consumers for a control plane:
List all consumers for control plane [CONTROL_PLANE_ID].Analyze requests for a specific consumer:
Show me all requests made by consumer [CONSUMER_NAME/ID] in the last 24 hours.Check for common errors or patterns:
What are the most common errors experienced by this consumer?⚠️ This project is no longer accepting contributions. The repository will be archived as read-only. Pull requests and issues will not be reviewed or merged.
Historical development notes:
npm test runs the TypeScript build and the repository test suite.
build/ is a committed generated artifact in this repository and should be regenerated with npm run build after changes to src/.
Note: No support is provided for this deprecated project. The information below is preserved for reference only.
Connection Errors
Verify your API key is valid and has the necessary permissions
Check that the API region is correctly specified
Ensure your network can connect to the Kong Konnect API
Authentication Errors
Regenerate your API key in the Kong Konnect portal
Check that environment variables are correctly set
Data Not Found
Verify the IDs used in requests are correct
Check that the resources exist in the specified control plane
Ensure time ranges are valid for analytics queries
Built by Kong. Originally inspired by Stripe's 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. Dates show when Glama detected each change.
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_requestsEach 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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
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
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Kong/mcp-konnect'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
