Log10x MCP Server

Official

by log-10x

Overview Schema Source Related Servers Discussions Admin

TypeScript

Local

Advise: Retriever install

log10x_advise_retriever

Read-onlyIdempotent

Generates an install, verify, or teardown plan for Log10x Retriever from a discovery snapshot, validating required AWS SQS, S3, and IRSA resources.

Instructions

Given a DiscoverySnapshot (from log10x_discover_env), produce an install/verify/teardown plan for the Log10x Retriever. Unlike Reporter + Receiver, the Retriever has no forwarder choice — it is a standalone set of workloads (indexer + query-handler + stream-worker + filter CronJobs) that read from S3 via SQS and serve an HTTP query endpoint. The advisor detects existing AWS infra (input bucket with indexing-results/ prefix, four SQS queues — index/query/subquery/stream — and an IRSA-annotated ServiceAccount) from the discovery snapshot, or accepts explicit overrides. Preflight fails closed when any required resource is missing — the Retriever depends on Terraform-provisioned infra that this advisor does NOT create. Verify probes: pods Ready, indexer processing messages, query endpoint responding, S3 indexing-results/ getting writes, SQS queue drainage. Teardown uninstalls the Helm release but leaves AWS infra alone (Terraform's concern).

Input Schema

TableJSON Schema

Name	Required	Description	Default
`action`	No	Plan scope. Default: `all`.
`namespace`	No	Target namespace. Default: snapshot.recommendations.suggestedNamespace.
`infra_mode`	No	How the customer provisions AWS infra. terraform = emit .tf module block. cli = emit aws-cli commands. existing = infra already provisioned, wizard skips infra steps and jumps to helm values. Auto-detected as "existing" when the snapshot already has all four SQS URLs + IRSA.
`destination`	No	Destination SIEM for the kept slice (e.g. `datadog`, `cloudwatch`, `splunk`). Gates SIEM down-tier sub-sections in the offload markdown.
`snapshot_id`	Yes	ID returned by `log10x_discover_env`. The snapshot is cached for 30 min.
`iam_role_arn`	No	IAM role ARN for the Retriever ServiceAccount (IRSA) (module output: iam_role_arn). Auto-detected from snapshot.
`index_bucket`	No	S3 path for indexed results (include prefix). Default: `<index_source_bucket>/indexing-results/`.
`release_name`	No	Helm release name. Default: `my-retriever`.
`license_source`	No	How the wizard acquires the engine license JWT. Defaults to `"signin"` — emits `signin_required` mode when no Auth0 session exists. Pass `"demo"` for a 14-day anonymous JWT. Pass `"paste"` with `license_jwt_paste` to supply an existing JWT.	signin
`index_queue_url`	No	SQS URL for index operations (module output: index_queue_url). Auto-detected from snapshot.
`query_queue_url`	No	SQS URL for query operations (module output: query_queue_url). Auto-detected from snapshot.
`stream_queue_url`	No	SQS URL for stream operations (module output: stream_queue_url). Auto-detected from snapshot.
`license_jwt_paste`	No	License JWT supplied by the user when `license_source: "paste"`.
`subquery_queue_url`	No	SQS URL for sub-query operations (module output: subquery_queue_url). Auto-detected from snapshot.
`index_source_bucket`	No	S3 bucket for source logs (module output: index_source_bucket_name). Auto-filled from snapshot.recommendations.retrieverS3Bucket when present.

Output Schema

TableJSON Schema

Name	Required	Default
`data`	No
`tool`	Yes
`view`	No	summary
`images`	No
`actions`	No
`summary`	Yes
`warnings`	No
`truncated`	No
`next_cursor`	No
`render_hint`	No
`generated_at`	Yes
`schema_epoch`	Yes
`schema_version`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.30.7Sep 11, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Annotations cover the safety profile (readOnly, idempotent, closed-world), yet the description adds substantial behavioral disclosure: the standalone workload set, S3/SQS dependency, fail-closed preflight when AWS infra is absent, the specific verify probes, and the fact that teardown leaves Terraform-managed infra untouched.

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?

Dense but front-loaded, leading with the action and contrast to siblings before detailing behavior. The single-paragraph block is long, though nearly every sentence carries distinct information (preflight, verify, teardown semantics).

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 15-parameter tool with an output schema, the description supplies the behavioral context an agent needs — preflight conditions, verify probes, and teardown scope — without redundantly explaining return values. Nothing critical is missing.

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%, so parameters are already richly documented in the schema (infra_mode auto-detection, license_source modes, SQS queue outputs). The description adds only the general 'accepts explicit overrides' notion, so the baseline of 3 is 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 ('produce an install/verify/teardown plan') and resource ('Log10x Retriever'), and explicitly contrasts itself with the Reporter + Receiver topological option. An agent can distinguish this from log10x_advise_install and the retriever query/probe siblings without opening the schema.

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?

Clearly establishes the input context ('Given a DiscoverySnapshot from log10x_discover_env') and the override path, and notes preflight fails closed. However, it does not explicitly route between this tool and the sibling log10x_advise_install, leaving that alternative to inference.

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

Deploy Server