Skip to main content
Glama
Sign In
@mgcrea/mcp-keycloak

@mgcrea/mcp-keycloak

by mgcrea
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

keycloak_get_authentication_flow_executions

Read-only

Retrieve authentication flow execution steps and their requirement statuses to determine which login steps are required, alternative, conditional, or disabled.

Instructions

Get the ordered steps inside a flow and whether each is REQUIRED, ALTERNATIVE, CONDITIONAL or DISABLED. This is what determines what a user is actually asked for when logging in (password, OTP, ...).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "flowAlias": "<flowAlias>"
    },
    "name": "keycloak_get_authentication_flow_executions"
  }
}

Input Schema

NameRequiredDescriptionDefault
realmNoRealm to operate on. Defaults to the server's configured realm (KEYCLOAK_REALM).
flowAliasYesFlow alias (its name), e.g. `browser` or `direct grant`.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.3/5.0
Behavior4/5

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

The readOnlyHint annotation already signals this is a safe read operation. The description adds useful behavioral context beyond that by explaining the returned steps are ordered and encoding execution requirements, plus interpreting their meaning in login flows. No contradiction with the annotation exists.

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?

The description is two tight sentences: the first states the operation and output, the second gives the practical significance. There is no redundant filler or repetition of schema details.

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 present, the description adequately conveys what the tool returns: ordered steps with their requirement types. The parameter schema covers the inputs, annotations cover safety, and the description covers the result semantics and real-world relevance, making the definition complete for an agent.

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?

The input schema already documents both parameters, including the realm default and flowAlias examples. The description adds little parameter-level detail beyond framing flowAlias as selecting a flow, so it meets the baseline for full schema coverage but does not elevate it.

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?

The description uses a specific verb ('Get') and resource ('ordered steps inside a flow') and specifies the key output property: whether each step is REQUIRED, ALTERNATIVE, CONDITIONAL or DISABLED. This clearly separates it from sibling tools like keycloak_list_authentication_flows, which operate on the flows themselves rather than their internal steps.

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

Usage Guidelines4/5

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 this tool: to understand what a user is actually asked for during login (password, OTP, etc.). It does not explicitly name sibling alternatives or state when not to use them, so it falls just short of full use/alternative 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