Ankra

trace_request_path

Read-only

Trace a URL end to end and name the FIRST broken hop with evidence. Call this FIRST for any 'URL / preview / demo / ingress / hostname does not work', 502/503/504, timeout, 404 from the ingress controller, or certificate error symptom: it walks DNS (resolved addresses or NXDOMAIN, and for a hostname under an Ankra-managed zone which cluster owns it, whether an external-dns publisher is installed, whether it is running and whether its webhook provider has endpoints), TCP connect, the TLS handshake and certificate (issuer, SANs, expiry, verification error), the HTTP answer (status, server, redirect, body snippet), then inside the cluster the Ingress or IngressRoute whose host rule matches (namespace, backend Service and port, TLS secret, load balancer address versus DNS), the cert-manager Certificate and its ACME challenge, the backend Service (type, selector, ports), its ready and not-ready endpoints, and the Pods behind it (phase, ready, restarts, waiting or terminated reason, the last log lines of the first not-ready pod). Every hop records status ok/failed/unknown/skipped, its source (live, or the resource index with its staleness) and elapsed_ms. The verdict names the first failed hop, its cause in one sentence, and the later hop that explains it when there is one - so answer from the verdict without further reads; add at most one or two reads only when a hop is unknown. An unknown hop is a read that did not happen, never a finding. The cluster is derived from the hostname's managed zone, else from an Ingress host match across your readable clusters, else the session's cluster; pass cluster_name or cluster_id to pin it and namespace to narrow the Ingress search. Read-only; the probe dials from the Ankra platform, so private addresses are refused. Whole trace under 15 seconds.

Input Schema

Name	Required	Description
`url`	Yes	The URL the user reports as not working: https://host/path, http://host:port/, or a bare hostname (https is assumed).
`namespace`	No	Namespace to search for the Ingress rule in. Optional; narrows a large cluster.
`cluster_id`	No	UUID of the cluster to read from; an alternative to cluster_name.
`cluster_name`	No	Exact name of the cluster to read the Ingress, Service, endpoints and Pods from. Optional: derived from the hostname's managed zone or an Ingress host match when omitted.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 10, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Adds substantial behavior beyond the readOnlyHint annotation: the exact hop sequence (DNS, TCP, TLS, HTTP, Ingress/IngressRoute, Certificate/ACME, Service, endpoints, Pods/logs), hop status model (ok/failed/unknown/skipped), source and staleness, elapsed_ms, verdict semantics, cluster derivation, probe origin from the Ankra platform with private addresses refused, and a 15s bound.

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-loads the purpose and the symptom triggers, then packs operational detail with little filler. It is a dense, run-on paragraph rather than bulleted structure, so readability suffers slightly, but for a complex diagnostic tool the length is largely justified.

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?

For a complex read-only diagnostic with no output schema and only a single annotation, the description covers what is inspected, how the target cluster is chosen, how to interpret the verdict, and platform limitations (private addresses, 15s). Nothing significant an agent needs to call it correctly is missing.

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 description coverage is 100%, so the baseline is 3; the description still adds meaning by spelling out the cluster-derivation logic (managed zone, then Ingress host match, then session cluster) and the pinning role of cluster_name/cluster_id plus namespace narrowing the Ingress search.

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?

Names a specific verb (trace) and resource (a URL end to end) and states the concrete output (the FIRST broken hop with evidence). This clearly separates it from siblings such as probe_endpoint and get_ingresses, so an agent can select it 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?

Explicitly says to call this FIRST for a concrete symptom set (URL/preview/demo/ingress/hostname does not work, 502/503/504, timeout, ingress-controller 404, certificate error). It also constrains follow-up behavior ('answer from the verdict without further reads; add at most one or two reads only when a hop is unknown'), giving clear routing and usage guidance.

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

All Ankra tools Inspect

Try in Browser

Context Every Agent Can ShareAgents share what they learn, hand off work, and keep it when you switch models. Start with 5 GB free.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?