# Tools your assistant can call
> Every tool the 00 Simulator connector gives Claude, ChatGPT and other assistants, grouped by job, with what each one can change.
Source: https://simulator.00aud.io/docs/ai/tools
Connect 00 Simulator to your assistant and it gets these 39 tools. It works on your own workspaces, and each description below is the text it reads to choose a tool. The list is built from the connector's own, so it matches what your assistant sees.
- **Tools:** 39
- **Change a workspace:** 11
- **Server URL:** `https://simulator.00aud.io/mcp`
## How to read this list
Your assistant picks which tool to call, and when, from what you ask: you never call one yourself. The tools are grouped by the job they do, and the tags say what a tool can change.
- _Changes a workspace_: 11 tools add, edit or remove something in a workspace you own. Edits to a design are saved as new versions you can go back to, and a deleted workspace can be restored: see [Changes you can undo](https://simulator.00aud.io/docs/ai/what-it-sees#changes-you-can-undo).
- _In your open tab_: `show_graphs`, `annotate_graphs` and `end_workspace_session` work on what you see in the workspace you have open in 00 Simulator, not on the design. See [Watch it work live](https://simulator.00aud.io/docs/ai/live).
- _Changes your theme_: `save_theme`, `activate_theme` and `delete_theme` change how 00 Simulator looks for you, never a workspace.
- Untagged tools leave your designs as they are. `simulate_workspace` is still marked as writing, because it keeps the run it makes, privately, so graphs can be drawn from it.
Your assistant app is also told which tools only read (23 of them) and which can overwrite or remove something (8), so it can ask you before one runs. Nine tools need nothing beyond signing in: `search_drivers`, `get_driver`, `validate_driver`, `suggest_enclosure`, `get_enclosure_schema`, `get_theme_schema`, `search_docs`, `read_doc` and `list_workspace_capabilities`. The rest need the permissions you approve when you connect, listed in [What your assistant sees](https://simulator.00aud.io/docs/ai/what-it-sees#permissions).
> **Narration, and taking control** 23 tools that work on a workspace also take a narration: one or two plain sentences your assistant writes about what it is doing and why, shown in 00 Simulator if you have that workspace open. Their descriptions end by asking for it, and most of those that change something add that once you take control, your assistant must stop and ask you before editing again. That closing sentence is left out below; the rest is word for word.
## A design job, step by step
Six steps, in the order someone would do them, from choosing a driver to keeping or undoing the work.
### 1. Pick a driver
Search simulation-ready drivers by name or Thiele/Small filters, read one in full, and check a set of parameters for missing fields and contradictions.
**search_drivers**: Search simulator-ready drivers by text and optional T/S filters. Returns compact driver summaries and driver refs.
**get_driver**: Fetch a full driver by driver ref. Supports local, Bits, and raw driver refs through the internal API.
**validate_driver**: Validate a raw driver payload and report missing fields, simulation readiness, and consistency warnings.
### 2. Design
Suggest a starting alignment, read the fields each enclosure type takes, then build and edit candidates in a workspace of your own.
**suggest_enclosure**: Suggest one or two starting enclosure alignments using the simulator suggestion logic.
**get_enclosure_schema**: Describe Workspace enclosure editing, SI units, horn types/profiles, Paraflex and MEH configuration. This schema is enforced by `update_enclosure` and temporary `simulate_workspace` overrides.
**create_workspace**: Create a cloud workspace for a new project or design question. Call `list_workspaces` first and prefer `add_enclosure` on an existing Workspace: alternatives for one question belong together, where they can be compared on one graph. Name it after the project, not the candidate, and keep the name under 40 characters. A Workspace created here starts as a draft: it stays out of the account's Workspace count and recents, and is archived automatically after a week unless the account edits, renames, pins or keeps it. _Changes a workspace._
**list_workspaces**: List cloud workspaces for the authenticated account. Read this before creating anything: when the account already has a Workspace for the design question at hand, add to it with `add_enclosure` instead of creating another. Each entry reports `isDraft` and `createdByClientId`, so a Workspace you created earlier in this conversation is easy to find and continue.
**get_workspace**: Fetch a cloud workspace document owned by the authenticated account.
**add_enclosure**: Add one enclosure to an owned Workspace, with its driver values embedded in the same call. Prefer this over creating another Workspace: candidates that belong to the same design question belong in one Workspace, where they can be compared on one graph. Requires the current `expectedRevision`. Uses the same SI-unit fields as `update_enclosure`; read `get_enclosure_schema` for horn fields and examples. _Changes a workspace._
**update_enclosure**: Update one enclosure in an owned Workspace with required revision control. Uses the same SI-unit fields as the app. Arrays replace; configuration and `hornParaflex` merge one level; null clears optional fields. Read `get_enclosure_schema` for horn fields and examples. _Changes a workspace._
**update_workspace**: Update workspace metadata or replace the portable workspace document using optimistic revision control. A document without a notes field keeps the graph notes the person wrote; pass notes: \[\] only when they asked for their notes to be removed. _Changes a workspace._
### 3. Simulate
Run the solver on a saved version, including horns, EQ and multiple-entry drivers, and read the numbers back.
**simulate_workspace**: Run selected enclosures from an exact owned Workspace revision on the server, including all horn topologies, EQ and MEH sources. Uses saved power, embedded drivers and `environment.simulation` settings (`maximumFrequency`: auto or 20–20000 Hz; `upperResponseMode`: estimated or physical; `maxSpl`: the Max SPL thermal rule, real input power by default, or constant voltage or estimated coil heat, with an optional voice coil temperature). Auto uses 2 kHz if the Workspace contains horns, otherwise 400 Hz. `frequencyRange` overrides sampling for this run. Temporary overrides do not edit the Workspace. Returns a private run ID; results expire after 24 hours and only the newest 20 runs per Workspace are retained.
**get_simulation_results**: Read a private Workspace simulation run by `runId` and `workspaceId`. Summary includes each enclosure, MEH source names, horn locations and radiating outlets. Full includes exact resolved configuration and `frequencyResponse` curves, including each MEH source’s SPL, impedance, excursion, voltage and current, and `hornDiagnostics` with complex RMS pressure/flow, peak particle velocity, local acoustic impedance and separate output pressures. Non-finite values are encoded as null.
### 4. Show you
Draw graphs in the conversation, arrange the dashboard in your open tab around what is being explained, and mark the frequencies worth looking at.
**render_simulation_graphs**: Render interactive graph tiles for a private simulation run. Call `simulate_workspace` first, then pass its `workspaceId` and `runId`. Choose up to 6 graphs per call, in display order (spl: SPL at the saved listening distance; `maxSpl`: highest SPL before the driver reaches Xmax or its thermal limit; impedance: impedance magnitude seen by the amplifier; phase: acoustic phase including EQ and filters; `groupDelay`: group delay; excursion: peak cone excursion per diaphragm with Xmax limits; `prExcursion`: peak passive radiator excursion with its Xmax limit; `portVelocity`: port air velocity with the 17 m/s warning level; `rearPortVelocity`: rear chamber port air velocity of a 6th-order bandpass; `apparentPower`: apparent amplifier load including reactive current; `currentDraw`: amplifier RMS current). Defaults to spl and excursion. Every selected enclosure is overlaid on each tile, and so are the Workspace's measured traces for that kind (drawn thin, marked source: measured, with any display offset applied); kinds an enclosure does not produce (for example port velocity for a sealed box) are left out, and the result lists the kinds available for the run. Add controls (power, eq) when the user wants to explore drive level or EQ interactively: the widget then shows a panel where they can change one enclosure's power and EQ filters and see its curves re-solved locally; those previews stay unsaved until the user applies them, which writes through `update_enclosure`. Leave controls out for a plain comparison. Reads stored results without editing or re-running the Workspace. Results expire after 24 hours; re-simulate if expired.
**show_graphs**: Arrange the dashboard of the person's open 00 Simulator tab around what you are explaining, without changing the design. List the tiles in reading order and mark one primary: on a desktop it takes the most room and the rest fill the first screen; on a phone the graphs page in that order. Show the graphs your numbers come from (for example horn-pressure when you quote throat pressure). The person keeps the arrangement or restores their own layout when you finish. Tile ids and what each shows are listed by `list_workspace_capabilities` under `liveActivity.graphs`. _In your open tab._
**annotate_graphs**: Mark what to look at on the graphs in the person's open 00 Simulator tab, without changing the design: a band over a frequency range, a vertical line at a frequency, a horizontal level, or a point on an enclosure's curve. Each call replaces your previous marks; an empty list clears them, and they hide by themselves once the design changes. Keep labels to a few words with units ("+2 dB", "71.7 Pa") and explain in narration. Put the graph on screen with `show_graphs` first. Tile ids and what each shows are listed by `list_workspace_capabilities` under `liveActivity.graphs`. _In your open tab._
### 5. Check the build
Bring in a real measurement, such as a REW export, link it to the design it measures, and compare the two: the level difference and the shape difference are reported separately.
**import_trace**: Import a measured trace (REW text export, .frd, .zma, CSV, or a table of numbers) into an owned Workspace, where it overlays the matching graph: SPL, impedance, phase or Max SPL. Pass the file contents as text (up to 512 KB) or rows as points. The same rules as dropping the file in the app apply: lines that start with a number are data, frequency ascending, at least 5 rows, decimated to 48 points per octave, phase kept when present. Link it to the enclosure it is a measurement of with `enclosureId`; omit or pass null for reference data that belongs to no design here. Stored values are never shifted: use offset or `compare_trace` to align levels. At most 24 traces per Workspace. Requires `expectedRevision`. _Changes a workspace._
**compare_trace**: Compare a measured trace with an enclosure simulated from the current Workspace revision. Reports the mean level offset over the band (simulated minus measured: a distance or drive difference, not a shape disagreement), the RMS residual once that offset is removed, the largest remaining deviation and its frequency, and the residual at 1/6-octave points. The simulated run is saved like `simulate_workspace`, so `render_simulation_graphs` can draw it with the trace overlaid; lower `pointsPerDecade` when a large horn's run would pass the 4 MB limit. Pass apply: true with `expectedRevision` to store the offset on the trace. _Changes a workspace._
**list_traces**: List the measured traces in an owned Workspace: kind, unit, linked enclosure, display offset, frequency range, point count and measurement conditions. No curve values; use `get_trace` for those.
**get_trace**: Read one measured trace's values. Values are the stored measurement unless `applyDisplay` is true, in which case the display offset and smoothing are applied as drawn. Long traces are resampled on a log grid to at most `maxPoints` (default 96, up to 1000).
**update_trace**: Edit a measured trace: name, kind, link to an enclosure (null unlinks), display offset, smoothing, line style, point marker, visibility, colour (null goes back to the automatic colour: a shade of the linked enclosure's, or the trace's own) or measurement conditions (merged; null clears a field). Stored values never change. Requires `expectedRevision`. _Changes a workspace._
**delete_trace**: Remove a measured trace from an owned Workspace. It stays in revision history. Requires `expectedRevision`. _Changes a workspace._
### 6. Keep or undo
Finish with a summary you can undo in one go, restore any saved version, and clear away the candidates and workspaces that did not work out.
**end_workspace_session**: Finish your work on a Workspace. The person watching it in 00 Simulator sees your summary with the steps you took, and can keep or revert your changes. Call it once when you are done, with a two or three sentence summary of what changed and what to try next. _In your open tab._
**list_workspace_revisions**: List immutable revision metadata for an owned cloud Workspace without returning revision documents.
**get_workspace_revision**: Fetch one exact immutable revision document for an owned cloud Workspace.
**restore_workspace_revision**: Restore one older immutable revision into an owned cloud Workspace as a new MCP-attributed revision. _Changes a workspace._
**remove_enclosure**: Remove one enclosure from an owned Workspace with required revision control. Use it to drop a candidate you added and ruled out, instead of leaving it behind. _Changes a workspace._
**delete_workspace**: Move an owned Workspace to Deleted workspaces, where the account can restore it for 30 days. Use it to clean up a Workspace you created and no longer need, so unwanted designs do not pile up. Ask the person before deleting a Workspace you did not create in this conversation. _Changes a workspace._
## Outside the design job
Tools that belong to no single step of a design.
### Look it up
Search the 00 Simulator docs and read a page or one section of it, so answers about the app and what a result means quote the docs and link to them.
**search_docs**: Search the 00 Simulator docs: how to do something in the app, and what a tile, result, setting or term means. Returns the best matching pages, sections, tiles and glossary terms, each with a url and a one-line summary. Then read the best match with `read_doc` and quote it with its url, rather than answering from memory.
**read_doc**: Read a 00 Simulator docs page as Markdown. Pass a url from `search_docs` or a docs path such as /docs/reference/tiles/port-velocity (/docs is an overview of every page). Pass section, a heading on the page, to read only that part; a url ending in #section reads just that section. Quote what you use and link its url.
### Appearance
Build an app theme for you, for instance more contrast between the side-panel sections, check it against the contrast floors, and switch to it when you ask.
**get_theme_schema**: Describe a 00 Simulator theme: every scalar with its range and what it changes, the per-mode settings, the contrast floors a theme must clear, and the built-in themes as examples. Read this before `save_theme`.
**list_themes**: List the themes this person can use in 00 Simulator, built in and saved, and which one is active.
**get_theme**: Read one theme in full, with its contrast report for dark and light mode. Use an id from `list_themes`; "default" and "grosso" are built in.
**save_theme**: Check and save a custom theme for this person. Pass `dryRun` true to get the normalised theme and its contrast report without saving. A theme under a contrast floor in either mode is refused, with the failing checks and what to change. Leave `themeId` out to add a new theme, and give it a name. Pass `themeId` to change one of their saved themes: only the scalars and mode settings you send move, and a colour sent as null goes back to the app's own. Pass activate true only when they asked to switch. The person sees a theme change in 00 Simulator when they next look at that tab; they never need to refresh. _Changes your theme._
**activate_theme**: Switch this person to a built-in or saved theme. Only when they asked for it. The person sees a theme change in 00 Simulator when they next look at that tab; they never need to refresh. _Changes your theme._
**delete_theme**: Delete one of this person's saved themes, for example one you made and they did not keep. Built-in themes cannot be deleted. If it was active, they go back to the built-in theme it came from. _Changes your theme._
### Fold a horn
Fold a horn into a cabinet the way the Fold tile does, with other layouts, fixes and the folded horn to simulate beside the target, then export the saved fold as a Boundary Lab project to solve in 3-D.
**fold_horn**: Fold a horn enclosure into a cabinet the way the 00 Simulator Fold tile solves it, on an exact Workspace revision, without saving anything. Uses the saved cabinet (`hornFoldLayout`) or, when none is saved, sizes and compacts one; a layout in Auto takes the ranking's best fold. Pass changes (the `update_enclosure` fields) to try horn edits or another cabinet first. A `hornFoldLayout` change replaces the whole saved layout, driver mock included (the result's `driver.mock` is the one in use): give outside dimensions and `wallThicknessMm` without a topology to let the ranking choose the fold for them. Returns whether it fits, every issue, path length, areas, volume, the driver's taps and chambers, alternative folds, grow/trim fixes, optionally the smallest cabinet, cut list, Hornresp readout and area profile, and `folded.changes`: the passage as built, to pass as a `simulate_workspace` override so you can simulate the folded horn next to the target. To keep a fold, save the returned layout with `update_enclosure` (`changes.hornFoldLayout`), pinned with `topologyMode` "pinned" once you have chosen it. A saved layout may also carry the Fold tile's editor, pattern, locks and pins (held passage faces); keep them when you echo a layout back, or leave pins out to let the fold follow the horn.
**export_boundary_lab**: Export a horn's saved fold as a Boundary Lab project (coupled FEM-BEM: the folded passage as tetrahedra, the cabinet as a boundary-element shell, the driver on its board for tapped horns) and return a download link that works without signing in for 24 hours. Save the fold with `update_enclosure` first; pass the revision that holds it. resolution "draft" meshes by wavelength alone and solves in seconds, close enough to iterate on; "final" meshes the passage to 20 mm for sign-off. The zip includes the project, both meshes, a README and `to_traces.py`, which turns a solved run into .frd and .zma files for `import_trace`. Solving needs Boundary Lab installed where you run it: download with curl, unzip, blab project validate, blab project solve, then run the script and import the files linked to this enclosure to compare them with `compare_trace`.
### Its own limits
List the workspace operations this connection allows and the permission each one needs.
**list_workspace_capabilities**: List authenticated workspace operations, required scopes, availability, and document mutation semantics.
## Ask your AI
**Ask your AI**
Your assistant answers from the connector itself, so it reflects the permissions you approved.
> Using 00 Simulator, tell me which workspace operations this connection allows, which permission each one needs, and which of them can change my designs.