Skip to main content
Glama

Compile Tcc

compile_tcc

Compiles academic projects into PDF using LaTeX, Typst, or Pandoc with citation processing, syntax pre-checks, and actionable diagnostics for build errors.

Instructions

Compila o projeto acadêmico para PDF utilizando LaTeX (abnTeX2 com ciclo multi-pass para evitar [?]), Typst ou Pandoc com --citeproc. Inclui pré-checagem de erros de sintaxe e diagnóstico amigável.

Input Schema

NameRequiredDescriptionDefault
engineNoauto
project_pathYes

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3/5.0
Behavior3/5

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

With no annotations, the description does useful work: it discloses the multi-pass LaTeX cycle to avoid unresolved '[?]' references, a syntax pre-check stage, and friendly diagnostics — real behavioral traits beyond the schema. However, it omits that this is a write-side operation producing a PDF on disk, where the artifact lands, and whether a syntax failure aborts compilation or returns partial diagnostics.

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?

Two dense sentences with the resource and engine list front-loaded, and no filler phrasing. Slightly overloaded with parenthetical detail, but every clause carries information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The output schema covers return values, so that need not be described. Still, for a build tool with zero annotations and 0% parameter coverage, the definition should state output artifact location and the semantics of 'auto' and project_path to be complete enough for confident invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description carries the full burden. It does map Pandoc to markdown and confirm the LaTeX/Typst engine choices, but never explains what 'auto' does or what project_path should point at (project directory vs. main .tex file), which is the required parameter.

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?

States a specific verb and resource (compile the academic project to PDF) and enumerates the concrete toolchain options: LaTeX/abnTeX2, Typst, and Pandoc --citeproc. It is distinguishable from validation siblings like check_structure, though the 'pre-check of syntax errors' clause blurs that line slightly and no sibling is named explicitly.

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

Usage Guidelines2/5

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

There is no guidance on when to invoke this versus check_structure, validate_citations, or audit_illustrations_and_tables, and no prerequisite conditions are stated. It also does not say when to leave engine at 'auto' versus forcing latex/typst/markdown, leaving the caller to infer the workflow.

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