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 Datadog or Splunk connector configs that pull log10x offload NDJSON from your S3 bucket, so the SIEM ingests offloaded logs.

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'. The MCP does not push offloaded events into a SIEM: the offload lands NDJSON in the customer's bucket, and this tool emits the pull-side connector the SIEM reads it with. 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 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. Caveats: 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

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

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

Behavior5/5

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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint=false, yet the description adds substantial context beyond them: it does not create AWS resources or mutate any env document, per-SIEM output contents, the SNS fan-out workaround for S3's single-notification-per-prefix limit, and caveats (Datadog logs-only, Splunk input only collecting newly created objects). This is rich, decision-relevant disclosure.

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?

One dense block, but the information is front-loaded (purpose, then when-to-use, then args, returns, caveats) and every sentence is substantive for a tool this complex. It would be easier to scan with light formatting or line breaks between args/returns/caveats, and the arg restatement partly duplicates the schema.

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?

With an output schema and full annotations available, the description need only add context, and it does: it explains what gets generated per target, the discovery model and ordered steps, and the operational caveats an agent needs to set expectations. Nothing a caller needs 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 coverage is 100%, so the baseline is 3; the description still adds value by explaining per-SIEM option pairing (datadog_forwarder_arn for datadog, sqs_queue_name/sourcetype/index for splunk), the placeholder behavior when the forwarder ARN is omitted, and the meaning of bucket/prefix as the offload destination. It mostly restates documented params, so it lands just above baseline.

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: generates the customer-applied SIEM-side connector config (Datadog Forwarder Lambda / Splunk Add-on SQS-based S3 input) for pulling log10x offload output from S3. It explicitly contrasts itself with siblings, including log10x_backfill_metric and the offload action, so an agent can distinguish it without opening any 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?

Gives explicit trigger conditions ('when the user has offloaded a pattern's data to S3 and asks how to get Datadog or Splunk to ingest it') plus concrete example utterances. It also states the negative boundary clearly ('The MCP does not push offloaded events into a SIEM') and routes metrics needs elsewhere (log10x_backfill_metric, Generic S3 input for older Splunk data).

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

Deploy Server