Log10x MCP Server

Official

by log-10x

Overview Schema Source Related Servers Discussions Admin

TypeScript

Local

Emit SIEM connector for an offload bucket

log10x_siem_connector

Read-onlyIdempotent

Generate the pull-side connector config that lets Datadog or Splunk ingest log10x offload NDJSON from your S3 bucket.

Instructions

Generate the customer-applied SIEM-side connector config (Datadog Forwarder Lambda, or the Splunk Add-on for AWS SQS-based S3 input) that makes a SIEM pull log10x's offload output from the customer's own S3 bucket. Call this when the user has offloaded a pattern's data to S3 (the offload action / a log10x_offload_add destination) and asks how to get Datadog or Splunk to ingest it, e.g. 'ship my offload bucket to Splunk' or 'wire Datadog to read these logs'. log10x deliberately never pushes to a SIEM (vendor-driven re-ingest collides with Datadog Rehydration billing, Splunk HEC permissions, and Elastic _bulk limits); it lands NDJSON in the customer bucket and the SIEM pulls, and this tool emits exactly that pull-side connector. Args: siem (required: datadog / splunk / both), bucket (required: the offload bucket), account_id (required), region (default us-east-1), prefix (optional, default app/), plus per-SIEM options (datadog_forwarder_arn, sqs_queue_name, sourcetype, index). Returns, per target: the discovery model, ordered setup steps, paste-ready terraform (an SNS fan-out plus IAM, and for Splunk the SQS queue and the S3-to-SNS-to-SQS notification), the SIEM-native config (the Splunk inputs.conf aws_sqs_based_s3 stanza), and verified caveats. Recipes are matched to log10x's actual offload output (uncompressed NDJSON, one event per line, Hive-partitioned keys) and encode the key gotcha: the offload bucket usually already notifies the 10x indexer's SQS, and S3 allows only one notification config per overlapping prefix, so both recipes fan out via SNS rather than a second raw bucket notification. Honest caveats are surfaced: Datadog is logs-only (use log10x_backfill_metric for per-pattern metrics), and the Splunk SQS-based input collects only objects created after setup (backfill older data with a Generic S3 input). Read-only: it generates config and does not create AWS resources or mutate any env document.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`siem`	Yes	Which SIEM should pull the offload: datadog (Forwarder Lambda), splunk (Add-on SQS-based S3 input), or both.
`index`	No	Splunk index for the input. Default "main".
`bucket`	Yes	The offload bucket the SIEM should read (where 10x writes the NDJSON).
`prefix`	No	Offload key prefix the SIEM should watch. Default "app/".
`region`	No	AWS region of the bucket.	us-east-1
`account_id`	Yes	AWS account ID that owns the bucket (same account the SIEM connector runs in).
`sourcetype`	No	Splunk sourcetype for the input. Default "log10x:offload".
`sqs_queue_name`	No	Name for the SQS queue the Splunk input drains (splunk only).
`datadog_forwarder_arn`	No	ARN of an already-deployed Datadog Forwarder Lambda (datadog only). Omit to leave a placeholder.

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.6/5.0

Behavior5/5

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

Goes well beyond the readOnly/idempotent annotations: it explains the deliberate architectural stance (no vendor push due to Datadog Rehydration billing, Splunk HEC permissions, Elastic _bulk limits), the S3 single-notification-per-prefix gotcha and SNS fan-out workaround, and honest caveats (Datadog logs-only, Splunk SQS only picks up post-setup objects). It also confirms no AWS resources are created.

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-loaded with purpose and usage, then args, then return shape, then caveats — a logical order. However it is delivered as a single dense paragraph and repeats some parameter info already in the schema, so it is slightly heavier than needed.

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 9-parameter config-generation tool with an output schema, the description still supplies the decision context (when to use), the behavioral rationale, the return contents (discovery model, steps, terraform, native config, caveats), and the key gotchas — nothing material 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 the schema already documents all 9 parameters including defaults and the siem enum. The description largely restates required args (siem, bucket, account_id, region, prefix) and groups the per-SIEM options, adding only modest value over the structured fields.

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 ('Generate the customer-applied SIEM-side connector config ... Datadog Forwarder Lambda, or Splunk Add-on SQS-based S3 input') and defines the exact artifact produced. An agent can distinguish this from sibling tools like log10x_offload_add or log10x_backfill_metric 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 states when to call it ('when the user has offloaded a pattern's data to S3 ... and asks how to get Datadog or Splunk to ingest it') with concrete utterances ('ship my offload bucket to Splunk'). It also names the escape hatches for adjacent needs (log10x_backfill_metric for metrics, Generic S3 input for backfill).

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

Deploy Server