Loading ToolBench
MagicTeX — a LaTeX editor for AI agents (Claude Code), via an MCP server: live PDF preview, an editable source panel with a Visual (WYSIWYG) mode, anchored PDF comments that drive edits, and git-backed history. Compiles your .tex with a WASM TeX Live engine in a headless browser — no local TeX install, no Overleaf account.
MagicTeX demonstrates solid tool design with clear, action-oriented naming (render_preview, check_comments, list_checkpoints) and comprehensive descriptions (avg 180 chars, well above 10-char minimum). All 7 tools have input schemas with Zod validation and typed parameters. Descriptions explain WHAT, WHEN, and WHY for most tools. However, output schemas are not documented in the visible code, responses are inferred from implementation rather than explicitly declared. Error handling is present but minimal; no recovery guidance or actionable error messages visible. Tool composition is strong (each tool has one responsibility; IDs chain properly). Security is reasonable (no secrets in params; WRITE operations gated). Missing: per-tool output schema documentation, error classification guidance, and confirmation patterns for destructive ops.
Post a review comment anchored to a passage of the paper — for a reviewer agent marking up the document. Give the exact quoted text from the compiled paper (or the source prose) it refers to, and your comment/instruction. By default it is created as a *suggestion* the human accepts in the workspace before the author loop acts on it; pass accepted:true only in fully-autonomous ("copilot") mode to make it immediately actionable. Use this to leave many targeted comments rather than one long critique.
List the comments the user has accepted on the rendered PDF, as located work items. Each has an id, page, the quoted passage, the source file:line it anchors to (best-effort), and the user's instruction. Call this when the user asks to "address/check my comments" (or after they mention leaving comments) — or on each pass of an agent loop watching for new comments. For each item: open the source at the given location, make the requested edit (saving triggers a recompile + a checkpoint automatically), then call resolve_comment with its id and a one-line note. If it returns none, there is nothing accepted yet — reviewer suggestions awaiting the human's accept don't count.
List recent checkpoints (auto-saved on each successful compile) — sha, timestamp, and file/line-change stat, newest first. Use this to find a sha to pass into show_diff, or to cite specific saved versions when summarizing a multi-step editing session.
Compile the current project's LaTeX to a PDF locally and update the live preview. Uses the machine's TeX install when it has one, otherwise a bundled WASM TeX Live in a headless browser — so no local TeX is required. Returns compile success/errors, which engine and backend ran, the file count, and the local preview URL — open it to see the rendered pages. Call this after editing .tex files to see and verify the rendered result.
Output schemas not documented. Tool descriptions explain what is returned (e.g., 'Returns compile success/errors, which engine and backend ran, the file count, and the local preview URL') but no formal schema is visible in code. LLMs cannot plan downstream operations without knowing response structure.
No error recovery guidance. Error responses are not shown in source; no indication of retryable vs. fatal errors, or what the LLM should do next (e.g., 'Try search_users() first'). Agents will stall on failures.
Destructive operations (add_comment with accepted:true, resolve_comment) lack confirmation or dry-run patterns. An agent could autonomously mark comments resolved or post suggestions without user review.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 67 | 2026-07-28+ | v2 |
Add a reply to a comment's thread — to ask the human a clarifying question, explain your reasoning, or (as a defender) push back on another agent's suggestion before it is resolved. Use the comment id from check_comments. This does not resolve the comment; use resolve_comment for that.
Mark a workspace comment as resolved after you have made the edit it asked for. Pass the comment id (from check_comments) and a one-line note describing what you changed — the note is shown to the user on the comment card.
Render a side-by-side git diff as an image, shown inline in the conversation. Use this when the user asks to SEE a diff visually — it returns a picture, not a text summary. Defaults to current uncommitted changes; pass a checkpoint sha for a specific saved version.
Parameter 'accepted' in add_comment defaults to false but description warns it enables 'fully-autonomous' mode. No explicit guidance on when this is safe or what permissions gate it.
list_checkpoints limit parameter capped at 50 but no explanation of why or what happens if omitted. Default is 10 (reasonable) but constraint rationale is missing.