Skip to main content
Glama

Compiler Explorer

by io.github.compiler-explorer

compile

Read-only

Compile source code and return assembly output, stdout, and stderr

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
stdinNoStandard input for execution (requires execute=true)
sourceYesSource code to compile
executeNoRun the program instead of returning assembly. `asm` becomes empty; runtime output goes to top-level `stdout`/`stderr`; compile diagnostics move to `buildResult.stdout`/`stderr`.
filtersNoOutput filters
optionsNoCompiler flags (e.g. "-O2 -std=c++20 -Wall")
compilerNoCompiler ID from list_compilers (e.g. "g161"). If omitted, uses the language's `defaultCompiler` from list_languages.
languageYesLanguage ID (e.g. "c++", "c", "rust", "python")
librariesNoLibraries to link.
maxAsmLinesNoCap asm output (default 500 lines).
maxStderrLinesNoCap each stderr stream — compile and execute separately (default 100).
maxStdoutLinesNoCap each stdout stream — compile and execute separately (default 100).

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observed

TDQS

A4/5.0
Behavior4/5

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

The readOnlyHint: true annotation is contradicted by the description and schema since executing code is clearly a write/mutate operation. However, the description itself is transparent about what the tool does. The annotation contradiction is flagged separately, but the description accurately says 'compile and return assembly output, stdout, and stderr', and the schema details execution behavior. The annotation issue is a failing of the annotation, not the description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that precisely captures the core function. Every word is necessary, there is no fluff or repetition. It is front-loaded and to the point.

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 the comprehensive input schema (100% coverage, nested objects well documented) and the lack of an output schema, the description adequately states what is returned (assembly output, stdout, stderr). No additional detail is needed—the schema covers parameter behavior extensively.

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 baseline is 3. The description adds no parameter details itself, but the schema descriptions are thorough, covering all 11 parameters including complex nested objects like filters and libraries. The short description does not need to repeat schema content.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool compiles source code and returns assembly output, stdout, and stderr. This is a specific verb-resource combination that distinguishes it from siblings like list_compilers or lookup_asm_instruction. However, the description omits mention of the execution mode documented in the schema, which is a significant secondary capability.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

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

The description does not explicitly state when to use this tool versus alternatives. However, given sibling tools like list_compilers, list_languages, and list_libraries, it is implied this tool is for actual compilation after selecting a compiler. There is no guidance on prerequisites (e.g., need to list compilers first) or when to use execution mode.

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

All Compiler Explorer toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.1/5.0
Disambiguation5/5

Each tool has a clear, distinct purpose: compiling code, sharing via short URLs, retrieving sharing info, listing compilers, languages, libraries, and looking up assembly instructions. No two tools overlap in functionality.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern with snake_case (e.g., list_compilers, generate_short_url, lookup_asm_instruction). The naming is uniform and predictable.

Tool Count5/5

With 7 tools, the server is well-scoped for its purpose. It covers core compilation, sharing, metadata exploration, and instruction documentation without being too sparse or bloated.

Completeness4/5

The tool set covers the primary workflow (compile, share, browse metadata) and includes a unique instruction lookup. A minor gap is the lack of detailed compiler information beyond listing, but this does not significantly hinder the agent's ability to use the server effectively.

Resources