SEToolBox MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| SETOOLBOX_AGENT_FOLDER | Yes | Path to the folder SEToolBox watches for agent runs (the folder chosen in Settings, which must be on local disk, not iCloud Drive or another sync folder). Required; can alternatively be supplied as the CLI option --folder <path>. | |
| SETOOLBOX_AGENT_POLL_MS | No | Poll interval in milliseconds for checking the out/ folder for results. | 1000 |
| SETOOLBOX_AGENT_TIMEOUT_S | No | Result timeout in seconds, i.e. how long the server waits for a result file before giving up. | 60 |
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": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| setoolbox_list_toolsA | List the three SEToolBox calculation tools an agent can run through the folder exchange, with one-line descriptions and the input schema version each one currently publishes. Returns: { "tools": [{ "name", "description", "inputSchemaVersion" | null }] }. A null version means the app has not written that schema file yet (the app must be running with agent runs allowed). |
| setoolbox_get_schemaA | Return schema/.json verbatim: the blank input form for one tool. Read it before every setoolbox_run and use only the field names and units it lists. Each entry in "fields" has name, label, symbol, kind (quantity | enum | integer | boolean | text | option), allowed (units for a quantity, values for an enum or option), required, requiredWhen, and when sourced min, max, exclusiveMin, exclusiveMax, rangeSource. "echo" lists the derived symbols every result reports. "notes" are the app's own rules for that tool; follow them. Never cache this across app launches; the app rewrites the file when its schema version changes. |
| setoolbox_runA | Submit one calculation request to SEToolBox and wait for its result. The app does the math; this tool only writes the request file and reads the result file back verbatim. Args:
Returns the result file as JSON, unchanged. Top-level keys in order: status, answer, assurance, result, warnings, run, then agentInstruction or the error fields.
A tool error (isError) means the exchange itself failed: folder missing, bad or duplicate runId, or timeout. On timeout the request stays queued; the app processes it when it is running and in front, and setoolbox_get_result returns it later. Never resubmit under the same runId. |
| setoolbox_list_projectsA | List every project in the user's SEToolBox store: id, name, dateCreated, lastModified, and counts of records per tool family (tpmDataList, statisticalTools, massBudgetProjects, budgetTools, spacePowerBudgetProjects, nonSpacePowerBudgetProjects, linkBudgetAnalyses, radarRangeAnalyses, eoirAnalyses). Goes through the same folder exchange as a run, so the app must be running with agent runs allowed. Returns the result file verbatim; the payload is under "data.projects". Nothing in the app changes. |
| setoolbox_read_projectA | Read one project from the user's SEToolBox store, by projectId or by exact projectName (never both). Use it to review a study, cross-check values between tools, or find an analysis id. detail "summary" (default): the project header plus "records", one row per record with family, id, name, and for Link Budget, Radar Range, and EO/IR analyses also lastModified and isAgentRun. detail "full": the project's complete export JSON, the same bytes the app's Export command writes, with every stored input and result of every record. Large; ask for it when you need values. Family names in the summary are the keys of the full form, so a summary row can be found again in the full read. Returns the result file verbatim; the payload is under "data". Nothing in the app changes. A wrong name yields status "error" with project_not_found; a name shared by two projects yields ambiguous_project, so select by projectId from setoolbox_list_projects. |
| setoolbox_get_resultA | Return the result file for a runId, verbatim, if one exists in out/. Use it after a setoolbox_run timeout, or for a run submitted by another session. Returns { "found": false, "queued": boolean } when no result has appeared; queued true means the request is still waiting in in/ for the app. |
| setoolbox_list_runsA | List recent results in out/, newest first: runId, file name, tool, status, timestamp, analysisId (when the app saved an analysis), and the error code for error results. Default limit 20, maximum 200. Read-only audit view. |
| setoolbox_statusA | Report whether the agent folder exists and is prepared, the schema version of each tool, how many requests wait in in/ (queueDepth), and the age in seconds of the newest result. Use it to tell the user "SEToolBox is not running" when runs time out: a queueDepth above zero for longer than a few seconds means the app is closed, agent runs are off, or the iPad app is not in the foreground. Never throws for a missing folder; read folderPresent. |
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 8 tools
Each tool has a clearly distinct purpose: listing calculation tools, fetching a schema, running a calculation, listing/reading projects, retrieving one result, auditing recent runs, and checking exchange status. Overlaps such as get_result vs. list_runs are separated by runId-specific vs. audit/list semantics. No two tools appear to do the same thing.
All names use the setoolbox_ prefix and snake_case, which is consistent and predictable. The set is mostly verb_noun (list_tools, get_schema, list_projects, read_project, get_result, list_runs), with minor deviations in run and status.
Eight tools is well-scoped for a folder-exchange agent interface covering discovery, execution, retrieval, audit, project browsing, and health. Each tool earns its place, and there is no evident bloat or severe under-provisioning.
The surface covers the core agent workflow: discover tools, read schemas, run calculations, retrieve results, audit runs, browse projects, and check status. Minor gaps exist, such as no explicit project/analysis write, delete, or queued-run cancellation operations, but these are not dead ends for normal agent use.