Skip to main content
Glama
log-10x

Log10x MCP Server

Official
by log-10x

Set up recurring cost-reduction

log10x_setup_recurring
Read-onlyIdempotent

Configure a recurring autonomous log cost-reduction agent by answering seven setup questions. Generates policy.yaml and a scheduler manifest for Kubernetes, GitHub Actions, or crontab.

Instructions

Conversational wizard that configures a recurring autonomous cost-reduction agent. Walks the user through seven decisions — target services, savings target (%), tick schedule, scheduler runtime, gitops config repo, exception services, and final confirm — then emits two ready-to-commit artifacts: policy.yaml (the declarative policy the tick CLI consumes) and a scheduler manifest (Kubernetes CronJob YAML, GitHub Actions workflow, or crontab entry + wrapper script depending on the chosen scheduler). Each call merges the latest answer into the wizard session and either asks the next missing question or emits the artifacts once all answers are present. Re-invoke with the same session_id on every subsequent turn; sessions live 30 minutes. To skip interactive Q&A, supply all fields (target_services, target_percent, schedule, scheduler, config_plane, confirm: true) in a single call. Optional overrides: exceptions (services never touched), min_delta_pp (minimum savings delta before committing a new CSV, default 2pp), env_id, namespace, secret_name. Apply instructions for the chosen scheduler are in data.apply_instructions. After the first tick runs, call log10x_commitment_report to verify realized savings. REQUIRES nothing deployed to ASK: it renders manifests from your answers and writes to no account. The emitted tick needs a scheduler runtime (k8s CronJob, GitHub Actions, crontab, EventBridge, Container Apps job) and a policy repo or S3 prefix you control before it runs.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
env_idNoLog10x environment ID. Auto-detected from LOG10X_ENV_ID when absent.
confirmNoSet to true to confirm the configuration and emit the artifacts. The wizard asks for confirmation interactively when omitted.
scheduleNoTick schedule. Presets: daily-03utc (default), every-6h, every-12h, every-24h-localtz. Or pass a raw 5-field cron expression (e.g. "0 5 * * 1").
namespaceNoKubernetes namespace for the CronJob. Default: log10x. Only used when scheduler=k8s_cron.
schedulerNoWhere the recurring tick runs. k8s_cron = Kubernetes CronJob (default when kubectl reachable), github_actions = GHA workflow, crontab = crontab + wrapper script, eventbridge = AWS-native (EventBridge Scheduler + CodeBuild, S3 config plane — no cluster, no GitHub; the fit for AWS serverless estates), container_apps_job = Azure-native (Container Apps scheduled Job, git config plane; the fit for Azure serverless estates).
exceptionsNoService names the policy must never touch (audit / regulatory / executive). Optional — defaults to empty. Pass [] to explicitly clear all exceptions.
session_idNoWizard session handle. Omit on the first call — a new session is minted and returned. Pass it back unchanged on every subsequent call.
secret_nameNoName of the Kubernetes Secret holding LOG10X_API_KEY. Default: log10x-secret. Only used when scheduler=k8s_cron.
config_planeNoWhere the recurring CLI reads policy.yaml and writes updated cap CSVs: a gitops repo URL (e.g. https://github.com/acme/log10x-config), a local path, or — required when scheduler=eventbridge — an S3 prefix (e.g. s3://acme-logs/log10x-config).
min_delta_ppNoMinimum change in savings percentage points required before the tick commits a new CSV. Default: 2. Set to 0 to commit on every tick.
target_percentNoDesired savings target, as a percentage of current log volume (1-95). Default: 30. The CLI's per-pattern planner works backward from this target.
target_servicesNoServices the policy targets. Empty array = all services. Use service names from `log10x_services`. The wizard asks if omitted.
budget_gb_monthlyNoVOLUME BUDGET: keep monthly ingest for the targeted services at or under this many GB/mo. A standing line, not a one-shot cut: each tick scales the budget to its lookback window and cuts only the overage — already under budget means every pattern passes. Replaces target_percent in policy.yaml (mutually exclusive). Dollar budgets are a one-shot answer via log10x_estimate_savings (budget_usd_monthly); the recurring tick is byte-denominated.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
dataNo
toolYes
viewNosummary
imagesNo
actionsNo
summaryYes
warningsNo
truncatedNo
next_cursorNo
render_hintNo
generated_atYes
schema_epochYes
schema_versionYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.30.7

TDQS

A4.8/5.0
Behavior5/5

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

Annotations cover the safety profile (readOnlyHint, idempotentHint, openWorldHint), and the description adds genuinely new behavior: session lifetime of 30 minutes, the merge-and-ask-next-question loop, artifact emission on completion, and the explicit 'writes to no account' guarantee. These are traits no structured field conveys.

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?

Purpose and artifact output are front-loaded, and the length is justified for a 13-parameter stateful wizard. There is mild redundancy between the 'REQUIRES nothing deployed' sentence and the closing prerequisite sentence, which keeps it from a 5.

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?

Given an output schema exists, the description needn't explain return values, and it still points to data.apply_instructions. For a complex, multi-turn setup tool it covers invocation, state, prerequisites, and the next step, leaving no critical gap.

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 parameters are already documented; the description adds value by framing them as an ordered set of seven decisions and clarifying that supplying all of them bypasses interactive Q&A. It largely restates defaults (min_delta_pp 2pp) already in the schema, so it stops short of a 5.

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 — configures a recurring autonomous cost-reduction agent — and enumerates the exact artifacts it emits (policy.yaml, scheduler manifest). It also names the sibling follow-up tool (log10x_commitment_report), so an agent can distinguish it from the surrounding cost/savings tools.

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 describes the invocation protocol (re-invoke with the same session_id each turn, or supply all fields in one call to skip Q&A), names the alternative path, and states prerequisites (a scheduler runtime and a config repo/S3 prefix) plus the follow-up verification call. Nothing about when to use it is left to inference.

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