Skip to main content
Glama
Iqram09

kong-ai-gateway-mcp

by Iqram09
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Get a consumer with credential and group state

get_consumer
Read-onlyIdempotent

Retrieve a Kong consumer's credential counts and ACL groups to separate 401 authentication failures from 403 authorization failures when one client fails.

Instructions

Retrieves one Kong consumer together with what it can actually authenticate and authorize with: how many credentials of each type it holds, and which ACL groups it belongs to.

USE WHEN: a specific client is failing while others succeed, or you need to distinguish a 401 from a 403. The two have different causes and this tool separates them:

  • no credential of the type the route requires -> 401, authentication fails

  • credential present but wrong ACL group -> 403, authorization fails

RETURNS: consumer (ref, username, customId), credentialCounts per credential type, and aclGroups.

SECURITY: credential COUNTS only. Key values, passwords and secrets are never returned by this tool and are not available through any tool in this server.

LIMITATIONS: does not say which routes the consumer may reach -- that depends on the plugins on each route. Pair with list_plugins_for_route, or use diagnose_route with a consumer name to have both sides checked together.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
consumerYesConsumer username, id, or `consumer:<username>` reference. Example: "partner-integration" or "consumer:partner-integration".

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description adds substantive context beyond them: the SECURITY note that only counts are returned and secrets are unavailable anywhere in the server, plus a LIMITATIONS note that route reachability depends on per-route plugins. That is exactly the kind of constraint annotations cannot express.

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?

Labeled sections (USE WHEN, RETURNS, SECURITY, LIMITATIONS) front-load purpose and decision logic. Despite the length, each section carries distinct information — return shape, a security guarantee, and a scoping caveat — so no sentence is 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?

No output schema exists, so the description compensates by enumerating the returned fields (`consumer`, `credentialCounts`, `aclGroups`). Combined with the auth-failure framing and the pointer to diagnose_route, an agent has everything needed to call and interpret this tool.

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% and the single parameter already documents the accepted forms with an example. The description adds nothing about the `consumer` argument, so the baseline 3 for schema-driven params is correct.

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?

Specific verb+resource ('Retrieves one Kong consumer') with a scope qualifier that separates it from the sibling list_consumers: it returns credential-type counts and ACL group membership, not just identity. An agent can distinguish it from list_consumers, get_route, and get_service without opening schemas.

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?

An explicit USE WHEN section names the concrete trigger (one client failing while others succeed) and frames the 401-vs-403 decision this tool resolves. It also names alternatives (list_plugins_for_route, diagnose_route) and the condition under which to prefer them.

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