Log10x MCP Server

Official

by log-10x

Overview Schema Source Related Servers Discussions Admin

TypeScript

Local

Compile status

log10x_compile_status

Read-onlyIdempotent

Poll an asynchronous compile by job_id to track status, view engine diagnostics, and retrieve produced units and the linked .10x.tar artifact.

Instructions

Poll an asynchronous compile started by log10x_compile (or a link started by log10x_compile_link), by its job_id. Returns job_status (running / completed / failed / timed_out), the units produced so far + the linked .10x.tar (path + size), elapsed time, the engine exit code, and a credential-redacted tail of the engine log. Crucially, it promotes the engine's scan/link DIAGNOSTICS into the envelope so the compiler is not a black box at 100k to 500k file scale: per-language scan-failure counts with capped failure samples (which files failed to parse and why), and the link report (units merged / skipped, files excluded by folder/name filter, and the symbol-type histogram: class / enum / log / exec). Those appear once the compiler-10x image carries the engine diagnostics change; on an older image the tool degrades to unit counts + the log tail. The first terminal poll captures the exit code into the job record and frees the container; later polls stay readable and the compiled library is never removed.

Input Schema

Name	Required	Description	Default
`view`	No	summary returns the typed envelope (data.payload.job_status, .loss_markers, .diagnostics, .output, .log_tail).	summary
`job_id`	Yes	The job id returned by log10x_compile (data.payload.job_id).
`log_lines`	No	How many trailing engine-log lines to include in data.payload.log_tail (credential-redacted). 0 to omit. Raise it when diagnosing a failed or incomplete run.

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.

Changed2 schema fields changedv1.30.8Oct 15, 2026

changedInput schema / properties / log_lines / description

Previous value: -"How many trailing engine-log lines to include in data.payload.log_tail (credential-redacted). 0 to omit. Raise it when diagnosing a failed run."New value: +"How many trailing engine-log lines to include in data.payload.log_tail (credential-redacted). 0 to omit. Raise it when diagnosing a failed or incomplete run."

changedInput schema / properties / view / description

Previous value: -"summary returns the typed envelope (data.payload.job_status, .diagnostics, .output, .log_tail)."New value: +"summary returns the typed envelope (data.payload.job_status, .loss_markers, .diagnostics, .output, .log_tail)."

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?

Beyond the readOnly/idempotent annotations, the description discloses substantial behavior: the four job_status states, that the first terminal poll captures the exit code and frees the container while the library is never removed, and that diagnostics degrade on an older engine image. This is exactly the lifecycle context an agent needs and cannot get from structured fields.

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 is front-loaded in the first clause and each sentence carries real content (states, diagnostics, degradation, lifecycle). It is dense and longer than necessary — the diagnostics sentence is heavy — but almost nothing is padding.

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 job-polling tool with an output schema present, the description covers the full lifecycle: what is returned, terminal-state side effects, degraded behavior on old images, and post-completion readability. Nothing needed to poll correctly 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% and the schema already documents view, job_id, and log_lines (including raising log_lines for diagnosis). The description restates that job_id originates from compile and that the log tail is credential-redacted, but adds little parameter-level meaning beyond what the schema provides, so the baseline 3 applies.

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 opens with a specific verb+resource (poll an async compile) and immediately scopes it to jobs produced by log10x_compile / log10x_compile_link, distinguishing it from those producer siblings. An agent can tell exactly what this tool returns (job_status, units, diagnostics) 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?

It clearly states the usage context: poll a job started by log10x_compile or log10x_compile_link, keyed by job_id, and it explains that later polls stay readable after the container is freed. It stops short of an explicit when-not condition, but the polling lifecycle is unambiguous.

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

Deploy Server