Skip to main content
Glama
Iqram09

kong-ai-gateway-mcp

by Iqram09
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

List plugins affecting a route

list_plugins_for_route
Read-onlyIdempotent

Identify which plugins actually run on a route by resolving Kong scope precedence, filtering disabled instances, and summarizing authentication status.

Instructions

Lists every plugin that affects a route, resolved across all three Kong scopes.

USE WHEN: investigating authentication, rate limiting, CORS, ACL or any other plugin-driven behaviour. This is the tool that answers "is this route protected, and by what".

IMPORTANT -- three things this resolves that a raw plugin list does not:

  1. Scope precedence. Kong applies the most specific instance of a plugin: route beats service beats global. effectivePlugins reflects that; shadowed lists instances that exist but never run.

  2. Disabled plugins. A plugin with enabled=false is still returned by Kong and still shows in Kong Manager, but does nothing. Check the enabled field, not mere presence.

  3. Authentication summary. authentication states plainly whether any ENABLED auth plugin applies, which is usually the actual question.

RETURNS: effectivePlugins (what actually runs, each with ref, name, enabled, scope and relevant config), shadowed, and an authentication summary object.

LIMITATIONS: plugin config is filtered to diagnostically relevant keys; secret-bearing fields are never returned. Consumer-scoped plugin instances are listed but their effect depends on which consumer is calling.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
routeYesRoute name, id, or `route:<name>` reference, e.g. "route:payments-prod".
includeInheritedNoAlso return plugins the route inherits from its service and from global scope (default true). Leave this true when asking "is this route protected" -- a route with no plugins of its own can still be covered by a service-level or global plugin.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly/idempotent/non-destructive, and the description adds substantial context beyond them: shadowed vs effective instances, the enabled=false trap, and the fact that secret-bearing config keys are stripped. It does not disclose pagination or performance characteristics, so it falls just short of the top.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with a one-line purpose, then clearly labelled USE WHEN / IMPORTANT / RETURNS / LIMITATIONS sections. Slightly long overall, but each block is scannable and none is pure padding.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description takes on the return-value burden and does so: it names effectivePlugins, shadowed, and the authentication summary, and warns that config is filtered and consumer-scoped instances depend on the caller. The one limitation that matters for interpretation is stated explicitly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, including a detailed note on includeInherited's default and why to keep it true, so the schema does the heavy lifting. The description never refers to the `route` parameter's accepted formats or the includeInherited flag directly, so it adds no parameter meaning beyond the schema baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with a specific verb+resource ('Lists every plugin that affects a route') plus a scope qualifier ('resolved across all three Kong scopes') that distinguishes it from list_global_plugins and list_routes_for_service. An agent can tell immediately this is the route-scoped, precedence-resolving plugin view.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit 'USE WHEN' clause enumerates concrete triggers (authentication, rate limiting, CORS, ACL, plugin-driven behaviour) and states the question it answers ('is this route protected, and by what'). It also contrasts itself against 'a raw plugin list', effectively routing the agent away from shallower sibling tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools