Loading ToolBench
Quantum Physics Simulation and Animation Server using MCP, QuTip, and Manim
PsiAnimator-MCP provides 5 quantum physics tools with solid parameter schemas and reasonable descriptions. However, descriptions lack optimization for LLM reasoning, output schemas are undocumented, and error handling guidance is absent. Tool naming is domain-appropriate but generic (verb_noun pattern is present). Parameter types are declared but many lack detailed format/constraint documentation. No tool annotations present. The server addresses a specialized scientific domain with reasonable API design but falls short of production-grade agent tooling standards.
Generate Manim animation of quantum processes including Bloch sphere evolution, Wigner functions, state tomography, circuit execution, energy levels, and photon statistics
Calculate various entanglement measures for quantum states including von Neumann entropy, linear entropy, concurrence, negativity, and mutual information
Evolve a quantum system in time using various methods including unitary evolution, master equation, Monte Carlo, and stochastic approaches
Perform quantum measurement of an observable on a quantum state, calculating expectation values, variances, probability distributions, and correlations
Apply a sequence of quantum gates to a quantum state with visualization support and intermediate state tracking
Output schemas not documented. Tool descriptions state what each tool generates (animations, measurements, evolving systems) but the actual response structure, fields, data types, and optional fields are not visible in the source. LLMs cannot plan downstream tool calls or extract specific values without knowing the response schema.
Tool descriptions lack LLM-optimization detail. Descriptions are 50-150 chars and state WHAT tools do but not WHEN to use them, prerequisites, or dependencies. Example: 'generate Manim animation of quantum processes...' does not explain when to choose animate_quantum_process vs evolve_quantum_system, what data_source must contain, or format.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | B | 70 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 40 | - | v1 |
Parameter constraints under-documented. Many parameters (data_source, hamiltonian, observable, gates) accept complex string formats (LaTeX, system names, matrices, circuit notation) but lack format specifications, examples of valid input, or parsing rules in descriptions. LLMs will hallucinate syntax. E.g., 'hamiltonian: string' does not clarify if it expects 'H = 0.5*X + 0.3*Z' or JSON or Python syntax.
No error handling or recovery guidance. Tool descriptions do not document failure modes, timeouts, validation errors, or how LLMs should respond. E.g., if animate_quantum_process fails due to invalid animation_type, no guidance is provided. Per pattern, error responses should tell the LLM what to do next.
No tool annotations present. Tools are missing readOnlyHint, destructiveHint, and idempotentHint annotations. Per 2026-07-28 MCP spec, these are standard metadata. classify_entanglement and measure_observable are read-only; animate_quantum_process and evolve_quantum_system are write operations that modify state. annotations enable agents to reason about idempotency and side effects.
Parameter dependencies undocumented. collapse_operators in evolve_quantum_system only applies to 'master' or 'monte_carlo' evolution; measurement_at_end in quantum_gate_sequence has nested structure that is not explained. solver_options varies by evolution_type. These dependencies should be stated explicitly so LLMs know which combinations are valid.
state_id and data_source parameters poorly documented. These are critical for tool chaining (output of one tool becomes input of another) but their format, lifecycle, and validity are not explained. E.g., is state_id opaque or human-readable? Do state_ids persist across tool calls? Must state_ids be created by a tool or provided externally?