Skip to main content
Glama
Iqram09

kong-ai-gateway-mcp

by Iqram09
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Diff live Kong against the declared baseline

diff_config
Read-onlyIdempotent

Compares the live Kong configuration against the declared baseline to find drift. Use it to spot routes, services, or upstreams that differ from what was intended.

Instructions

Compares what Kong is actually running against the declared configuration baseline in kong/seed/baseline.json, and reports every difference.

USE WHEN: something is configured but behaving unexpectedly, and you need to know whether the live configuration matches what was intended. Especially effective for problems with no local symptom -- a route attached to the wrong service, a dropped HTTP method, a changed upstream address -- where the entity looks perfectly valid in isolation.

Pass entity to scope the comparison to one route or service. A whole-gateway diff is much larger and usually buries the relevant line.

RETURNS: drift[], each entry naming the entity, the attribute, the baseline value, the Kong value and the operational impact; plus inSync and driftCount.

IMPORTANT: a difference does NOT establish which side is wrong. The baseline may be out of date just as easily as the gateway may have drifted. Report the difference and what it causes; do not assert that Kong is misconfigured on the strength of this tool alone.

LIMITATIONS: the baseline covers services (host/port/protocol), routes (service, paths, methods, required plugins) and upstreams (targets). Plugin configuration VALUES are not compared -- only whether a required plugin is present and enabled.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
scopeNoWhich entity class to compare (default "all"). Narrow this when a full diff would be larger than you need.
entityNoRestrict the comparison to one named entity, e.g. "search-prod" or "payments-api". Strongly preferred when investigating a specific problem -- a gateway-wide diff is much larger and mostly irrelevant.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already declare readOnly/idempotent/openWorld/non-destructive, so safety is covered — yet the description adds real behavioral context beyond them: a difference does not establish which side is wrong, and the LIMITATIONS block states exactly which fields are (services/routes/upstreams) and are not (plugin config values) compared. This is materially useful for interpreting results.

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

Conciseness5/5

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

Front-loaded one-line purpose, then labeled blocks (USE WHEN / RETURNS / IMPORTANT / LIMITATIONS). Length is justified by the number of distinct concerns (routing, interpretation caveat, coverage limits) and no sentence is filler.

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?

No output schema exists, so the description carries the return contract itself (drift[] with entity, attribute, baseline value, Kong value, impact; plus inSync and driftCount). Combined with the interpretation caveat and coverage limitations, an agent has everything needed to call and reason about the result.

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

Parameters4/5

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

Schema coverage is 100% and both params are documented in-schema, so the baseline is 3. The description adds genuine decision semantics beyond that: it explains why to pass `entity` (whole-gateway diff buries the relevant line) and recommends scoping as the preferred mode, which the schema description only hints at.

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?

States a specific verb (compares/diffs) and resource (live Kong running config vs. declared baseline in kong/seed/baseline.json), and the sibling set is all read-only inspection tools — none of which diff against a baseline. An agent can distinguish this from get_route/diagnose_route without opening a schema.

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 ('configured but behaving unexpectedly'), plus the diagnostic pattern it excels at (no local symptom, entity valid in isolation). It also names the preferred scoping strategy versus the whole-gateway alternative, giving both when-to-use and how-to-narrow guidance.

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