palace-tools
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| PALACE_TOOLS_CMD | No | Tells the runner how to call Palace (native command). Optional; `palace-tools doctor` shows what it found. | |
| PALACE_TOOLS_IMAGE | No | Tells the runner how to call Palace (container image). Optional; `palace-tools doctor` shows what it found. | |
| PALACE_TOOLS_DISTRO | No | Tells the runner how to call Palace (WSL distro). Optional; `palace-tools doctor` shows what it found. | |
| PALACE_TOOLS_BACKEND | No | Tells the runner how to call Palace (backend selection). Optional; `palace-tools doctor` shows what it found. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| palace_specA | Describe the compact config spec accepted by palace_build_config, with an example. |
| palace_build_configA | Build a Palace JSON config from a compact spec (physical-group names, units, ports, sweep) with safe defaults (MUMPS, direct solve for eigen/small driven, cheap estimator, Excitation = Index). Writes it if 'out' is given, and returns lint + schema results. |
| palace_lint_configB | Validate a Palace config against the 0.16 schema and run the lint rules (solver choice, ports, boundaries, units, AMR, sweeps). Pass geometry (the *.tags.json) for distance/patch checks. |
| palace_lint_rulesB | List every lint rule with its lesson and source. |
| palace_gotchasC | The gotchas list (lint rules plus workflow lessons). |
| palace_mesh_templateA | Build and mesh a template model with Gmsh: rectangular_cavity(a,b,d,h), parallel_plate_line(w,h,length,eps_r,h_mesh), microstrip_line(w,h,length,eps_r,side,top,h_mesh,h_edge,ports='lumped'|'wave',f_ghz). Writes .msh + .tags.json, returns groups and a mesh report with exact unknowns per order. |
| palace_mesh_reportB | Quality (minSICN, gamma), tets and exact Nedelec unknowns of a .msh file. |
| palace_estimate_costC | Estimate peak RAM and wall time (quiet/typical/busy) from unknowns or a config + tags file, calibrated on ~200 recorded Palace 0.16 runs. |
| palace_statusB | Running Palace jobs, CPUs and free RAM on the Palace host; progress of a case folder; whether a run with 'ranks' may start now. |
| palace_runA | Run Palace on case_dir/config (blocks until done). Refuses if another Palace job would be oversubscribed or RAM is short, unless force. Logs palace.log, time.log, run_record.json. |
| palace_resultsA | Summarise a Palace output folder (S-parameters, eigenmodes, EPR/Q tables, AMR, fields, log) and optionally write Touchstone with the right per-port reference impedances. |
| palace_checkC | Sanity checks: passivity, reciprocity, energy balance (fake wall loss), port symmetry, eigenmode at the expected frequency, log errors, wave-port spurious modes, convergence. |
| palace_doctorC | Which optional modules and Palace backends are available. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 13 tools
Tools mostly target distinct actions (build, lint, mesh, run, results), so selection is usually clear. However, palace_lint_rules and palace_gotchas overlap in content because gotchas includes lint rules plus workflow lessons, which could cause confusion about which to call.
All tools use consistent snake_case with a palace_ prefix and a predictable verb_noun pattern (e.g., palace_build_config, palace_lint_config, palace_mesh_report). Naming is highly coherent and easy to infer.
The 13 tools map cleanly onto the multi-step Palace workflow—config creation, linting, meshing, running, result summary, cost estimation, status, and sanity checks. Each tool appears to earn its place without obvious redundancy.
Core lifecycle coverage from config building through meshing, running, and result summarization is strong, with diagnostic and check tools rounding out the set. Minor gaps exist in case/folder management (e.g., listing, deleting, or comparing runs), but these are workaround-able.