physverify
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
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 | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| run_checksA | Run physverify verification checks (manufactured solutions, order of convergence, invariants, limits, exactness) on physics simulation code. Takes spec files that define checks(); with no specs given, finds verify_*.py files under |
| confirm_claimA | Judge one suspected defect with physverify confirm. Takes a claim file that defines CLAIM, control() and checks() with a reference written from the physics (docs/confirm.md), runs it in a fresh process and returns the verdict: confirmed, rejected or not decidable, with the reason and each check's status and message. Appends the result to a ledger file. Runs the code, so it needs trusted=true or the sandbox (PHYSVERIFY_REPO set). |
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 2 tools
run_checks is a broad verification sweep over discovered verify_*.py specs, while confirm_claim adjudicates a single suspected defect from a CLAIM file and writes to a ledger, so purposes are mostly separable. They share the underlying checks() machinery and both report check statuses, which could cause some hesitation about which to call for a one-off verification.
Both tools follow the same verb_noun snake_case pattern (run_checks, confirm_claim) and the verbs accurately reflect their actions. No mixing of conventions.
Only two tools for what is a fairly rich verification domain, which feels thin even for a focused CLI wrapper. The pair covers the batch and single-claim workflows but leaves little room for auxiliary operations.
Core lifecycle of run-specs-then-confirm-defect is present, but the surface is missing useful operations such as listing/discovering available spec or claim files, reading the accumulated ledger, or validating spec syntax before execution. The write-only ledger is a dead end for an agent.