Skip to main content
Glama
log-10x

Log10x MCP Server

Official
by log-10x

Compile symbol library

log10x_compile
Idempotent

Compile a symbol library from local, GitHub, Docker, Helm, or Artifactory sources to generate runtime event-attribution artifacts, returning a pollable job ID for long builds.

Instructions

Compile a symbol library from any mix of sources, waiting inline for the result when it is quick and handing back a pollable job_id when it is not. It waits up to max_wait_ms (default 45s): a small compile, and EVERY re-run (which reuses prior units via the pinned output folder), finishes inside that window and returns the finished library plus the full scan/link diagnostics in ONE call; a long first compile of a large tree overruns the wait and returns a running job_id to poll with log10x_compile_status, or just call this tool again later, since the output is pinned and a finished run is collected near-instantly. max_wait_ms: 0 returns the job_id immediately (fire-and-forget). Sources combine freely: a local folder of source code / binaries (source_path), GitHub repositories via the GitHub REST API (github_repos, with optional github_branch / github_folders), docker/OCI images (docker_images), Helm charts (helm_charts), and Artifactory artifacts (artifactory_instance + artifactory_repo, with artifactory_files / artifactory_folders). The run scans the sources (Java, Go, Python, JS/TS, Scala, C/C++, C#, plus binaries) and writes per-file .10x.json symbol units plus a single linked .10x.tar library, the AOT artifact the 10x runtime later uses to assign hidden classes (TenXTemplates) to events. GitHub pull REQUIRES a token even for public repos: pass github_token or set GH_TOKEN; without one the tool returns not_configured. Docker-image pull is daemonless (podman bundled in compiler-10x, --cap-add SYS_ADMIN granted automatically) and public images need no credentials. Helm pull is a meta-source (renders the chart, by default also pulls the images it references); OCI/URL chart refs resolve standalone while a bare repo/chart needs a matching helm_repos entry. Artifactory pull needs a token (artifactory_token or ARTIFACTORY_TOKEN). REQUIRES the COMPILER flavor: runs log10x/compiler-10x @apps/compiler by default, or a local compiler-flavor tenx with mode="local". An engine built before the flavor rename reports that flavor as cloud, and both spellings are accepted; the native runtime build has no generate pipeline unit and is refused. No Kubernetes or Log10x account needed. .jar files are not scanned directly; provide extracted .class.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
modeNoExecution backend. `auto` (default) prefers Docker (the compiler image, guaranteed compiler flavor) and falls back to a local compiler-flavor tenx. `docker` forces the image (LOG10X_COMPILER_IMAGE or LOG10X_TENX_IMAGE, default log10x/compiler-10x:1.1.39, a pinned tag rather than :latest so the same sources compile through the same engine every time). `local` forces the binary (LOG10X_TENX_PATH or `tenx` on PATH) and refuses it unless its version banner reports the compiler flavor (`compiler`, or `cloud` on an engine built before the flavor rename). Of the three shipped flavors only `compiler` can compile: `runtime` (native binary) and `runtime-jvm` (JVM-packaged runtime, the only runtime available on Windows) are both refused, since neither carries the `generate` pipeline unit. With a local install, local-folder compilation and GitHub pull (REST API + token) work out of the box; docker_images pull additionally needs a container engine (podman or docker) on the host. The docker `compiler-10x` image bundles all of those (podman included, daemonless), which is why Docker is the default.auto
helm_reposNoHelm chart repositories to register before resolving helm_charts, each as "name=url" (e.g. ["ingress-nginx=https://kubernetes.github.io/ingress-nginx"]). Required for bare "repo/chart" names; unnecessary for OCI/URL refs. Added via `helm repo add` in pre-step containers (docker mode only; in mode=local the host helm config is used as-is). url must be an http(s):// chart-repo index URL; for an OCI registry, put the oci://… ref directly in helm_charts (`helm repo add` does not support oci://).
timeout_msNoHard cap on compile wall time in milliseconds. Default 1,800,000 (30 min). The first compile of a large codebase typically runs 10–30 min; subsequent runs are near-instant via checksum reuse.
helm_chartsNoHelm charts to render and scan, as chart refs. A meta-source: the compiler runs `helm template` / `helm show chart` to extract the docker images and GitHub source repos the chart references, then (by default) pulls those too. OCI refs (e.g. "oci://ghcr.io/nginxinc/charts/nginx-ingress") and full URLs resolve standalone; a bare "repo/chart" (e.g. "ingress-nginx/ingress-nginx") needs a matching helm_repos entry. Combines freely with the other sources. In mode=local the host needs the helm CLI and must have the repos already `helm repo add`-ed.
max_wait_msNoHow long to wait inline (ms) for the compile to finish before handing back a job_id to poll. Default 45,000 (45s): small compiles and re-runs (which reuse prior units) finish inside this and return the library + diagnostics in ONE call. A long first compile of a large tree returns a running job_id you poll with log10x_compile_status, or just call this tool again later, since the output is pinned and a finished run is collected near-instantly. 0 = fire-and-forget (return the job_id immediately).
output_pathNoAbsolute path where the symbol library is written (the .10x.json units and the linked .10x.tar). Defaults to a fresh temp directory, returned in the result as data.payload.output.folder.
source_pathNoAbsolute path to a local folder of source code / binaries to scan. The compiler recursively traverses it for supported languages (Java, Go, Python, JS/TS, Scala, C/C++, C#) and binaries. Note: .jar files are not scanned directly; provide extracted .class files. Optional when github_repos is given; at least one source (source_path and/or github_repos) is required.
docker_tokenNoRegistry token/password for docker_images (fed to `docker login --password-stdin` against the default registry, Docker Hub). Falls back to DOCKER_TOKEN from the MCP server environment. Omit for public images; pair with docker_username. Reaches the compiler as process environment only.
github_reposNoGitHub repositories to pull (via the GitHub REST API) and scan, each as owner/repo (e.g. ["apache/commons-cli"]). REQUIRES a GitHub token, even for public repos: pass github_token, or have GH_TOKEN / GITHUB_TOKEN set in the MCP server environment. Combines freely with source_path.
github_tokenNoGitHub access token for github_repos (a fine-grained token with read-only Contents access to the target repos suffices). Falls back to GH_TOKEN / GITHUB_TOKEN from the MCP server environment. Reaches the compiler as process environment only; never written to disk or argv. When docker_images are given too, this same token additionally lets the compiler pull + scan each image's source repo (the org.opencontainers.image.source annotation); without it that extra scan is skipped silently.
library_nameNoBase name for the linked .10x.tar library file and the compile runtimeName. Sanitized to [A-Za-z0-9_.-].symbols
docker_imagesNoDocker/OCI images to pull and scan for symbols, as image refs, fully-qualified recommended (e.g. ["docker.io/grafana/grafana:11.1.0"]; a port-bearing host like "harbor.corp:8443/team/app:2.1" is fine, and a bare "alpine" resolves against the engine default registry). The pull is daemonless (podman inside the compiler-10x image, no host docker socket), and the tool automatically grants the compile container `--cap-add SYS_ADMIN` (needed by podman; only when this arg is used). Public images need no credentials. docker_username + docker_token `docker login` to the DEFAULT registry (Docker Hub), so they cover private Docker Hub repos; images on a different private registry must be pre-authenticated on the host/engine. In mode=local the host needs a docker/podman CLI with a working engine, and pulled images are left in its store (remove:false). Combines freely with source_path and github_repos.
github_branchNoBranch to pull for ALL github_repos. Omit to pull each repo’s default branch.
github_foldersNoFolders within each GitHub repo to pull (e.g. ["src/main/java"]). Omit to pull entire repos. Narrowing this speeds up both the pull and the scan.
docker_usernameNoRegistry username for docker_images login, also used for private images a Helm chart references (helm_pull_images). Authenticates the default registry (Docker Hub). Falls back to DOCKER_USERNAME from the MCP server environment. Omit for public images. The engine logs in only when BOTH username and token are non-blank. Reaches the compiler as process environment only.
helm_pull_reposNoWhether to pull + scan the GitHub source repos a chart references (via org.opencontainers.image.source annotations). Default false because it REQUIRES a GitHub token (engine refuses an empty token); enabling it without github_token / GH_TOKEN returns not_configured.
artifactory_repoNoArtifactory repository key to pull from, e.g. "libs-release-local". Required when artifactory_instance is given. Scope the pull with artifactory_files and/or artifactory_folders.
helm_pull_imagesNoWhether to pull + scan the docker images a chart references (the richest symbol source for a chart). Default true. When true the tool grants the compile container `--cap-add SYS_ADMIN` (daemonless podman), same as docker_images. Set false to scan only the chart template/values text.
artifactory_filesNoSpecific files within artifactory_repo to pull, each a repo-relative path (e.g. ["dist/app-1.0.0.tar.gz"]). Combine with artifactory_folders; at least one of the two is required when pulling from Artifactory.
artifactory_tokenNoArtifactory API access token for artifactory_instance. Falls back to ARTIFACTORY_TOKEN from the MCP server environment. Required when pulling from Artifactory. Reaches the compiler as process environment only; never written to disk or argv.
artifactory_foldersNoFolder paths within artifactory_repo to pull (e.g. ["com/acme/app"]). Traversed recursively unless artifactory_recursive is false. At least one of artifactory_files / artifactory_folders is required when pulling from Artifactory.
artifactory_instanceNoBase URL of an Artifactory instance to pull artifacts (Java archives, .NET assemblies, etc.) from and scan, e.g. "https://demo.jfrog.io/artifactory". Requires artifactory_repo and a token (artifactory_token or ARTIFACTORY_TOKEN). Pull is via the Artifactory REST API, no extra host privilege. Combines freely with the other sources.
artifactory_recursiveNoWhether artifactory_folders are pulled recursively (sub-folders too). Default true. Ignored when only artifactory_files are given.

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 establish the mutation/idempotency profile, and the description adds substantial context beyond them: the pinned output folder enabling cheap re-runs, the daemonless podman pull with automatic --cap-add SYS_ADMIN, the mandatory GitHub token even for public repos, the not_configured failure mode, and the flavor gating that refuses runtime builds. This is rich behavioral 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?

The text is long but dense and front-loaded with the inline-wait behavior before drilling into sources and prerequisites; almost every clause carries distinct information. It is slightly repetitive in restating the re-run/pinned-output behavior across the description and the max_wait_ms schema entry, 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?

For a 23-parameter tool with an output schema, the description covers the operation model, source combinations, credential requirements, execution backends, flavor constraints, and failure modes (not_configured, refused runtime). Nothing an agent needs to invoke it correctly is missing, and return values are appropriately left to the output schema.

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 description coverage is 100%, so the baseline is 3, and every parameter is already well documented in the schema. The description still adds cross-parameter semantics the schema does not: how sources combine freely, that github_token doubles as the source-repo credential for docker_images, and that max_wait_ms:0 means fire-and-forget.

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 ('Compile a symbol library from any mix of sources') and enumerates the source types it accepts. It is clearly distinguishable from siblings log10x_compile_status (polling) and log10x_compile_link (linking), and the output artifacts are named.

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 inline-vs-async decision: small compiles and every re-run finish within max_wait_ms and return in one call, while a long first compile returns a job_id to poll with log10x_compile_status or by re-calling this tool. It also states prerequisites and exclusions (GitHub token required, runtime flavors refused, .jar not scanned directly).

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