squire
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| SQUIRE_TOKEN | No | Optional Squire session or headless token. The public service also supports anonymous access when no token is provided. | |
| SQUIRE_API_BASE_URL | No | Optional API base URL override. Defaults to https://api.squire.run. | https://api.squire.run |
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 |
|---|---|
| helpA | Show the top-level Squire command catalog or help for a specific command. This is the canonical discovery surface for humans and agents before choosing a command. |
| whoamiA | Return the current public or authenticated identity, trust tier, feature flags, token metadata, and server-side quotas. |
| verifyA | Run small inline snippets or staged scripts in fresh Linux containers across the supported target images. |
| depsA | Validate whether dependency manifests install in a clean environment. The CLI surface exists, but the public zero-egress service currently rejects deps jobs. |
| sqlA | Run SQLite or Postgres schema, query, and migration validation in a fresh disposable database sandbox. |
| testA | Run small or medium test jobs in clean runtimes with a target matrix for Python, Node, or Bash. |
| lintA | Run fixed lint and static-analysis tools in a fresh toolchain so local environment drift does not affect the result. |
| auditA | Run the supported security-focused audit surfaces against staged local files. On the public service this currently means secret scanning and local-config static analysis. |
| buildA | Run offline packaging and build sanity checks in clean environments and optionally pull the resulting artifacts back locally. |
| benchB | Run small, short-lived benchmark jobs in clean runtimes to compare simple timing behavior without turning Squire into a full performance platform. |
| browserA | Run headless Chromium in a constrained offline sandbox and optionally download screenshots or other generated browser artifacts locally. |
| compileA | Run target-specific Go or Rust compilation checks in clean toolchains without turning Squire into a full CI or release system. |
| solveA | Run bounded solver jobs for Z3 or MiniZinc in a fresh disposable sandbox. |
| quantum_simulateB | Stage a small Python/Qiskit file set, run the entry file inside an offline Qiskit Aer image, and optionally download generated artifacts locally. |
| dataA | Run Python data-processing jobs in a disposable remote runtime with pandas, polars, and pyarrow available. |
| mediaA | Run Python media jobs in a disposable remote runtime with ffmpeg installed and optionally download the generated files locally. |
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 16 tools
Most tools are clearly separated by domain (sql, lint, build, browser, quantum, data), but 'verify' and 'test' both run code in clean sandboxes and could cause misselection. 'build' vs 'compile' and 'data' vs 'media' also share enough conceptual overlap that an agent might need to rely on descriptions.
Tool names mostly follow a consistent, simple lowercase command style with clear domain nouns. The only real inconsistency is 'quantum_simulate' using an underscore-and-verb structure while nearly every other tool is a single word, but the overall pattern remains predictable.
At 16 tools, the server sits just above the ideal 3-15 range, but each tool addresses a distinct sandboxed domain. The count is slightly heavy rather than bloated, and the individual tools each appear to earn their place.
The tool surface comprehensively covers execution, validation, build, compile, lint, test, browser, and specialized sandbox domains. Minor gaps exist: 'deps' is explicitly non-functional on the public service, and there is no generic job-status or artifact-cleanup tool, but agents can still complete most intended workflows.