Skip to main content
Glama
Sign In

Ankra

by ai.ankra
OverviewDiscussionsAdmin

Get cluster gateway API

get_cluster_gateway_api
Read-only

Where the Kubernetes Gateway API stands on a cluster Ankra built (the twin of ankra cluster gateway-api and the portal's networking card - the one preview the portal, the CLI and this tool share): available says the cluster has Ankra-managed networking to serve it (false carries unavailable_reason); enabled is the recorded option; phase is one of off, no_platform_networking, conflict, crds_failed, crds_pending, values_pending, apply_failed, applying, enabled, and enabled is the cluster's own answer: the platform reads the GatewayClass traefik Accepted and the Gateway traefik-gateway in namespace traefik Programmed from watches it can vouch for (synced, fresh, not parked as unlistable); with the values written and no failed apply, everything short of that stays applying, whether Traefik or cert-manager has not applied yet, the Gateway has not reported Programmed (the note quotes its reason and message), or the platform cannot read the Gateway's status on the cluster yet (the note says why, such as the cluster not syncing gateways), so applying can last until the cluster reports the Gateway served; crds is the platform's own reading of the Gateway API CRDs (source addon or preinstalled, what the CRD watch sees, the gateway-api-crds addon's state and applied state, established); traefik and cert_manager say what each member's stored values would gain (add), already carry (already_on) or contradict (conflict, naming the keys), and their applied state; values_hold names why the values write is held back (an offline cluster, a paused GitOps sync); note says what the phase means and who moves it on. Use it before enable_cluster_gateway_api and after it to follow the phase; a phase other than enabled is not a broken cluster. Read-only.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "get_cluster_gateway_api"
  }
}

Input Schema

NameRequiredDescriptionDefault
cluster_idNoUUID of the target cluster. Optional when a cluster is selected.
cluster_nameNoExact name of the target cluster. Optional when a cluster is selected.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4/5.0
Behavior4/5

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

Goes well beyond readOnlyHint by explaining phase values, why 'applying' can persist, which watches must be synced/fresh/unlistable, and why values writes are held back. The only repetition is the trailing 'Read-only,' which merely restates the annotation.

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

Conciseness3/5

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

The purpose is front-loaded, but the body is a dense, semicolon-chained paragraph with nested parentheticals that is hard to parse. Much of the return-field detail earns its place because no output schema exists, but the lack of structure costs readability.

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

Completeness4/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 carries the return-value burden and does so thoroughly, covering available, enabled, phase, crds, traefik, cert_manager, values_hold, and note. It is complete enough to call and interpret the tool, with only minor gaps around error cases or cluster-not-found behavior.

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 coverage is 100% with two optional cluster-identification parameters, so the schema already documents them fully. The description adds no meaning about cluster_id versus cluster_name or selection behavior, making the baseline 3 appropriate.

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 and resource: reports where the Kubernetes Gateway API stands on an Ankra-built cluster. It explicitly distinguishes itself from the sibling enable_cluster_gateway_api and frames itself as the shared preview used by portal, CLI, and this tool.

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?

Gives clear temporal guidance: use it before enable_cluster_gateway_api and after it to follow the phase, and warns that a phase other than enabled is not a broken cluster. It names the relevant alternative, though it does not distinguish itself from broader cluster-status tools an agent might otherwise reach for.

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

All Ankra toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources