Log10x MCP Server

Official

by log-10x

Overview Schema Source Related Servers Discussions Admin

TypeScript

Local

Link symbol units

log10x_compile_link

Idempotent

Link a folder of .10x.json symbol units into a single .10x.tar library without scanning source, used to re-link edited units or rebuild from prior compile output.

Instructions

Link an existing folder of .10x.json symbol units (from a prior compile) into a single .10x.tar library, with NO source scan. This is the same compiler-flavor Compiler app invoked with link-only arguments: the units folder is the outputSymbolFolder and no source is mounted, so the engine reuses the units already on disk (scans 0 new files) and merges them into the library, which is written into that same folder. Like log10x_compile it waits inline up to max_wait_ms (default 45s; linking is usually fast, so it normally returns the linked library in ONE call) and otherwise hands back a job_id to poll with log10x_compile_status. Use it to re-link after editing or pruning units, to assemble a library from a units tree built piecemeal, or to rebuild a library from the output folder of a prior log10x_compile. REQUIRES the COMPILER flavor (runs log10x/compiler-10x @apps/compiler by default, or a local compiler-flavor tenx with mode="local"; an engine reporting the flavor as cloud is accepted, the native runtime build is refused). No Kubernetes or Log10x account needed.

Input Schema

Name	Required	Description	Default
`mode`	No	Execution backend, same contract as log10x_compile's `mode`: `auto` prefers the compiler image, `docker` forces it, `local` uses a compiler-flavor tenx. Only the compiler flavor can link; see log10x_compile `mode` for the three flavors and which are refused.	auto
`timeout_ms`	No	Hard cap on link wall time in ms. Default 600,000 (10 min). Linking is much faster than scanning, but a very large units tree can still take minutes.
`units_path`	Yes	Absolute path to a folder of .10x.json symbol units (produced by a prior compile) to link into a single .10x.tar library. Traversed recursively; the existing units are merged with NO source re-scan, and the .10x.tar is written into this same folder.
`max_wait_ms`	No	How long to wait inline (ms) for the link to finish before handing back a job_id to poll. Default 45,000 (45s). Linking usually finishes inside this and returns the library in ONE call. A very large units tree returns a running job_id you poll with log10x_compile_status. 0 = fire-and-forget.
`library_name`	No	Base name for the linked .10x.tar and the runtimeName. Sanitized to [A-Za-z0-9_.-].	symbols

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.

Changed1 schema field changedv1.30.8Oct 15, 2026

changedInput schema / properties / mode / description

Previous value: -"Execution backend, same contract as log10x_compile: `auto` prefers the compiler image, `docker` forces it, `local` uses a compiler-flavor tenx (an engine built before the flavor rename reports that flavor as `cloud`; both are accepted). Both runtime flavors are refused, `runtime` (native binary) and `runtime-jvm` (JVM-packaged, the only runtime on Windows), neither carries the `generate` pipeline unit."New value: +"Execution backend, same contract as log10x_compile's `mode`: `auto` prefers the compiler image, `docker` forces it, `local` uses a compiler-flavor tenx. Only the compiler flavor can link; see log10x_compile `mode` for the three flavors and which are refused."

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 mark it as a non-read-only, idempotent, non-destructive write; the description adds substantial context beyond that: it scans 0 new files, merges on-disk units into the library written to the same folder, waits inline up to max_wait_ms (typically returning in one call) and otherwise hands back a job_id, and requires the compiler flavor while refusing the native build. No contradiction with the write/idempotent annotations.

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, scope, and key constraint are front-loaded in the first sentence, and each subsequent sentence carries real information. It is dense and long for a single paragraph, but there is little filler to cut.

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 mutation tool with an output schema present, the description covers purpose, prerequisites, execution semantics, timing, and fallback behavior. Nothing an agent needs in order to invoke it correctly 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 schema already documents all five parameters (baseline 3). The description goes further by tying units_path to the compiler's outputSymbolFolder and explaining max_wait_ms's inline-vs-job_id behavior, adding cross-parameter context on top of the schema.

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 opening sentence states a specific verb (Link), resource (existing folder of .10x.json symbol units), and output (.10x.tar library), plus a distinguishing constraint (NO source scan). It explicitly contrasts with log10x_compile, so an agent can tell them apart without opening either 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 three concrete when-to-use scenarios (re-link after editing/pruning units, assemble from a piecemeal units tree, rebuild from a prior compile's output folder) and names log10x_compile_status as the polling alternative. Restrictions (compiler flavor required, native runtime refused) are stated up front.

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

Deploy Server