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 job by job_id to retrieve status, diagnostics, output paths, and a redacted engine log tail.

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–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

TableJSON Schema

Name	Required	Description	Default
`view`	No	summary returns the typed envelope (data.payload.job_status, .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 run.

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 already cover the read-only/idempotent/non-destructive profile, and the description adds substantial lifecycle detail beyond that: the first terminal poll captures the exit code and frees the container, later polls stay readable, the compiled library is never removed, and behavior degrades to unit counts + log tail on an older engine image. This is exactly the extra context annotations cannot express.

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: the polling action and job_id keying come first, then the returned fields, then the degradation caveat. Every sentence carries substance, though the diagnostics/return-value enumeration is heavier than strictly needed given an output schema exists.

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 an async status poller with an output schema, full schema coverage, and rich annotations, the description fills the remaining gaps (lifecycle, degradation, diagnostics promotion) so an agent can call and interpret it correctly.

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 coverage is 100% and the schema already documents job_id, view, and log_lines (including the 'raise it when diagnosing a failed run' hint). The description restates the job_id origin but adds no syntax or format detail beyond the schema, 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?

States a specific verb (poll), resource (asynchronous compile), and names the two siblings that produce the job (log10x_compile and log10x_compile_link). An agent can distinguish this status poller from the retriever_query_status sibling and from the compile launchers 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 Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Clearly establishes the usage context: call it to poll a job started by log10x_compile or log10x_compile_link, keyed by job_id. It does not explicitly name a competing status tool or say when-not to use it, but the precondition 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