Ankra

connect_log_source

Propose connecting the log source Ankra derived from this cluster's installed addons (the one a query_logs refusal named). Pass EXACTLY the provider and endpoint from that refusal - both are re-derived server-side at execution and the call is refused on any mismatch, so never invent or edit them. The action requires an organisation admin's confirmation; on confirm the endpoint is first verified with the existing read-only probe (a failed probe writes nothing), then the source is registered in the resource graph as the cluster's log_source, inheriting GitOps, audit, drift detection and IaC export. An in-cluster Service endpoint needs no credential - the agent relay dials it from inside the cluster - so never ask the user for one. Do not use this to repair a misconfigured existing source. If the store runs OUTSIDE the cluster, or the derived endpoint does not match what the release actually renders, re-propose the correct endpoint with endpoint_is_operator_supplied=true: derivation only sees installed addons, so neither case can be derived and neither is a reason to refuse the connection. Admin confirmation and the read-only probe apply either way. If the external store requires authentication (the probe answers 401/403), pass credential_from_cluster_id naming a cluster in this organisation whose log source already queries the same store: the server copies that cluster's saved credential by reference and probes with it. NEVER ask the user to paste a password or token into chat - secret material must not transit this tool.

Input Schema

Name	Required	Description
`endpoint`	Yes	The endpoint URL. Copy verbatim from the refusal's derived-candidate sentence, or supply the correct one with endpoint_is_operator_supplied=true when the store is external or the derived endpoint is wrong. Must be an http:// or https:// URL. Private and in-cluster addresses are fine; loopback, link-local (including the cloud metadata address) and multicast are refused.
`provider`	Yes	The provider. Copy verbatim from the refusal's derived-candidate sentence, or supply it with endpoint_is_operator_supplied=true.
`cluster_id`	Yes	Ankra cluster id (UUID) the call targets. Discover ids with list_clusters.
`credential_from_cluster_id`	No	UUID of another cluster in the SAME organisation whose saved log credential should authenticate this source. Valid ONLY together with endpoint_is_operator_supplied=true. The server verifies that cluster belongs to this organisation, loads its stored log_credential (name, username, auth scheme, and the secret material from the secret store), runs the read-only probe WITH it, and only on success copies the credential onto this cluster and registers the source naming it - no password or token ever passes through the chat or this tool call. Use it when the external store refuses the unauthenticated probe (401/403) and a sibling cluster already queries the same store; never ask the user to paste the secret instead.
`endpoint_is_operator_supplied`	No	Set true ONLY when a person supplied this endpoint rather than copying Ankra's derived candidate. Derivation reads INSTALLED ADDONS, so it cannot name a store running outside the cluster (a managed OpenSearch, a hosted Prometheus) - that is the case this exists for. It skips the derived-candidate equality check ONLY: organisation-admin confirmation and the read-only probe still run, and the confirmation shows the endpoint as supplied rather than derived. Never set it to pass off an endpoint you inferred yourself.

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?

Annotations only declare write/non-idempotent/non-destructive; the description goes far beyond, disclosing that server-side re-derivation refuses on any mismatch, that an organisation admin must confirm, that a read-only probe runs first and writes nothing on failure, that the source is then registered in the resource graph with GitOps/audit/drift/IaC inheritance, and that no secret material may transit the tool.

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?

The purpose and the exact-copy requirement are front-loaded, and nearly every sentence carries a distinct constraint (mismatch refusal, probe, credential path, secret handling). It is nonetheless a dense, uninterrupted block that could be structured into clearer segments; length is justified by the operational complexity but the density is high.

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, and the description compensates fully: it covers precondition (a prior refusal), confirmation flow, probe behavior, credential sourcing including the 401/403 case, failure modes, and the off-cluster/derived-mismatch path. Nothing material for correct invocation appears 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 coverage is 100%, so the baseline is 3, and the schema descriptions already document most param constraints. The description still adds workflow meaning beyond the schema: how provider/endpoint must be sourced (verbatim from the refusal, re-derived server-side), and the conditional linkage between endpoint_is_operator_supplied and credential_from_cluster_id.

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 states a specific verb and resource ('Propose connecting the log source Ankra derived from this cluster's installed addons'), and it is readily distinguishable from siblings like query_logs, connect_metrics_source, and set_cluster_hosted_log_shipping. It also names the originating trigger (a query_logs refusal), anchoring the action to a concrete workflow.

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 when-to-use (a query_logs refusal named a derived candidate), explicit when-not-to-use ('Do not use this to repair a misconfigured existing source'), and named alternatives for the external-store and mismatch cases via endpoint_is_operator_supplied=true. It also routes the credential path to credential_from_cluster_id rather than user input.

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?