Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@SEToolBox MCP Server run a link budget for my Ku-band downlink and save the result"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP server for SEToolBox, the systems engineering calculator for macOS and iPadOS. It lets an AI agent run the app's Link Budget, Radar Range, and EO/IR calculators and read the user's projects, through the folder the app watches. The app does every calculation; this server only writes request files and returns the app's result files unchanged.
SEToolBox running, with an agent runs folder chosen in Settings and "Allow agent runs" on. On iPad the app must be in the foreground.
Node 20 or newer.
The folder must be on local disk, not iCloud Drive or another sync folder. The exchange relies on an atomic rename.
Related MCP server: DJAI Tools MCP
No clone, no build: npx fetches and builds the server on first use. Pin a release tag so every machine gets the same code; the default branch is not pinned and npx caches what it fetched.
Warm the cache first, and confirm the version it prints:
npx -y github:slaughters85j/setoolbox-mcp-server#v0.2.0 --versionClaude Code:
claude mcp add --scope user setoolbox -e "SETOOLBOX_AGENT_FOLDER=/path/to/your/agent/folder" -- npx -y github:slaughters85j/setoolbox-mcp-server#v0.2.0Codex CLI:
codex mcp add setoolbox --env SETOOLBOX_AGENT_FOLDER=/path/to/your/agent/folder -- npx -y github:slaughters85j/setoolbox-mcp-server#v0.2.0Claude desktop app, in ~/Library/Application Support/Claude/claude_desktop_config.json. Use the absolute path of npx (which npx); the desktop app does not load your shell PATH. Quit the app before editing when you can, since it rewrites the file on quit; if the agent doing this is running inside the desktop app, write the entry anyway and check it after the restart:
"setoolbox": {
"command": "/opt/homebrew/bin/npx",
"args": ["-y", "github:slaughters85j/setoolbox-mcp-server#v0.2.0"],
"env": { "SETOOLBOX_AGENT_FOLDER": "/path/to/your/agent/folder" }
}Then quit and relaunch the tool. To confirm which build is live, call setoolbox_status and read serverVersion; tool descriptions can be stale in a client's cache, the status payload cannot.
Setting | Source | Default |
Folder |
| required |
Result timeout |
| 60 |
Poll interval |
| 1000 |
Tool | Does |
| The three calculation tools and their schema versions |
|
|
| Write a request, wait for the result, return it verbatim |
| Fetch a result by runId, after a timeout or from another session |
| Recent results, newest first |
| Folder present, schema versions, queue depth, last result age |
| Every project with per-family record counts (read only) |
| One project: summary rows, or the full export JSON (read only) |
<folder>/
in/ requests, written as <runId>.json.tmp then renamed to <runId>.json
out/ results, <runId>.json; or <request file name>.error.json when the runId could not be trusted
done/ archived requests
schema/ link_budget.json, radar_range.json, eoir.jsonrunId: 1 to 64 characters of [A-Za-z0-9._-], no leading dot, equal to the file name without .json, never reused. The app never overwrites a result.
A calculation request carries tool, inputSchemaVersion (1), inputs (every physical quantity as {"value": n, "unit": "..."}), optional save (projectName, analysisName), and optional displayUnits.
A read request carries operation (project.list or project.read) instead of tool and inputs.
Results carry, in order: status (ok, undetermined, error), answer, assurance, result, warnings, run, then data for reads, agentInstruction for undetermined answers, or the error fields. run holds runId, toolVersion, inputSchemaVersion, timestamp, analysisId, persisted, sessionId, and on calculation results tool.
undetermined is a normal outcome. Report the quantity as not determined and ask for answer.missingInputs.
The server writes only in/<runId>.json.tmp and the rename. It never touches out/, done/, or schema/, never deletes, and never resends under a used runId.
skill/setoolbox-agent-runs/SKILL.md teaches an agent when and how to use these tools, including a project review procedure. Copy or link it into your agent's skills folder.
npm install
npm testSeventeen tests run against a temporary folder with a fake responder standing in for the app. Two live tests run only when SETOOLBOX_AGENT_FOLDER is set and the app is running.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| runId | Yes | The request's runId. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world). The description adds valuable non-annotation behavior: the not-found return shape { found: false, queued: boolean } and the semantic distinction that queued=true means the request is still in in/. This discloses queued-state semantics the agent cannot infer from annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each earning its place: purpose, when-to-use, and the not-found return shape. Front-loaded with the verb and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complete for a single-param read tool with no output schema: the description supplies the missing return contract (found/queued) and clearly explains when to call it. Nothing an agent needs is absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the runId pattern and description are already documented in the schema. The description adds no format or syntax detail beyond the schema; baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Return) and resource (result file for a runId) with precise scope ('verbatim, if one exists in out/'). Distinguishable from sibling setoolbox_status, which reports state rather than returning file content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit when-to-use: 'after a setoolbox_run timeout, or for a run submitted by another session.' This routes the agent correctly relative to setoolbox_run and cross-session scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| tool | Yes | One of link_budget, radar_range, eoir. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, non-destructive safety, but the description adds important behavioral details: the returned JSON structure, that notes are app rules to follow, and that the file must not be cached because the app rewrites it when its schema version changes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The purpose is front-loaded and the remaining details are structured around return fields, echo/notes semantics, and caching. It is somewhat detailed for a one-parameter tool, but most sentences carry useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description adequately explains the returned schema object, including fields, echo, notes, and the no-caching rule. It gives an agent enough context to call this read-only tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single tool parameter is fully documented in the schema with enum values. The description adds only general context that it selects one tool, so it does not extend parameter meaning beyond the schema baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: return the schema file for one tool, described as the blank input form. It also differentiates from sibling setoolbox_run by instructing the agent to read it before every run.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to read it before every setoolbox_run and to use only the field names and units it lists. It also gives a caching constraint across app launches, though it does not name when-not-to-use alternatives beyond the run dependency.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| timeoutSeconds | No | Seconds to wait for the result. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly/idempotent/non-destructive, but the description adds real context beyond them: the folder-exchange mechanism, the runtime precondition that the app must be running, and the verbatim file return with payload under 'data.projects'. 'Nothing in the app changes' usefully reinforces the read-only annotation; only limits like rate/timeouts are unaddressed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads the purpose, then follows with behavioral and output details in a logical order. The long enumeration of tool families is informative but slightly verbose; otherwise no wasted sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list tool with no output schema, the description supplies the field list, the payload location ('data.projects'), the return mechanism, and the runtime precondition. An agent has everything needed to call and interpret it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With a single parameter and 100% schema description coverage, the schema fully documents timeoutSeconds, so the baseline of 3 applies. The description adds no additional parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('List every project in the user's SEToolBox store') and enumerates the exact fields returned, so an agent knows precisely what this yields. It does not explicitly differentiate itself from siblings like setoolbox_list_runs or setoolbox_read_project, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the resource name, and it discloses a precondition ('the app must be running with agent runs allowed'), but it never states when to prefer this over alternatives such as list_runs or read_project, nor any exclusion conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum rows. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description goes further by disclosing ordering (newest first), the default and maximum limit, and the shape of returned rows, which is genuinely useful context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core action and scope, then the parameter bounds and safety tag. No filler; every clause adds information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description usefully enumerates returned fields and ordering, and covers limit bounds. It stops short of mentioning pagination or how to fetch a single run's details, but for a simple list tool it is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and there is only one parameter; the description's 'Default limit 20, maximum 200' essentially restates schema constraints. Baseline 3 applies since the schema already carries the semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (List) and resource (recent runs/results in out/), plus ordering (newest first) and the returned fields. An agent can distinguish this from siblings like get_result or list_tools from the description alone.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The tagline 'Read-only audit view' implies a browsing/inspection use case, but no explicit when-to-use vs alternatives is given (e.g., when to prefer get_result for a specific run, or list_tools for schemas). Usage is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description still adds real behavioral context: the null inputSchemaVersion case and its cause (schema file not yet written, app must be running with agent runs allowed). That failure-mode disclosure is genuinely beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short paragraphs, front-loaded with the purpose and followed by the exact return shape. Every sentence carries information; no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description compensates by spelling out the return object and the meaning of a null version. With annotations covering safety and zero parameters, nothing an agent needs to invoke this correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so the baseline is 4. There is nothing for the description to clarify about arguments, and it correctly spends no space on them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource — 'List the three SEToolBox calculation tools an agent can run through the folder exchange' — and scopes what each entry contains. An agent can distinguish this from siblings like setoolbox_list_projects or setoolbox_list_runs without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied rather than stated. The description notes the precondition that the app must be running with agent runs allowed, which hints at when entries will be populated, but there is no explicit 'call this before setoolbox_get_schema/setoolbox_run' routing or any when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| detail | No | summary | |
| projectId | No | Project id from setoolbox_list_projects. | |
| projectName | No | Exact project name. | |
| timeoutSeconds | No | Seconds to wait for the result. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, yet the description still adds value: the two error statuses and their causes, the size warning for full reads, that the payload sits under "data", and that family names in the summary are keys in the full form. That is behavioral context well beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core action and selector rule; each subsequent sentence carries distinct information (detail modes, size, error handling). The middle paragraph is dense, but nothing is padding or restatement of the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description carries the return-shape burden and does so: it enumerates the summary fields, characterizes the full export, and specifies where the payload lives. Combined with the error cases, an agent has everything needed to call and interpret this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 75% and the schema documents projectId, projectName, and timeoutSeconds individually. The description adds the mutual-exclusion constraint ("never both") that the schema does not express, and defines what each detail enum value actually returns.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ("Read one project") plus the two admissible selectors, and names the sibling it depends on (setoolbox_list_projects). It is immediately distinguishable from setoolbox_list_projects and setoolbox_get_result.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives concrete use cases (review a study, cross-check values, find an analysis id), an explicit rule for choosing detail ("ask for it when you need values"), and routing under failure (select by projectId from setoolbox_list_projects on ambiguous_project).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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:
tool: link_budget | radar_range | eoir
inputs: object keyed by schema field name. Every physical quantity is { "value": number, "unit": "<one of the field's allowed units>" }. Enum, option, and text fields are strings; integer and boolean fields are plain. Bare numbers for quantities are rejected by the app. Unknown field names are rejected. Omit what the user did not give you; the app never fills a required field from a default.
save (optional): { "projectName", "analysisName" }. Present means the app creates one new marked analysis in that project (created if absent). Absent means compute only.
displayUnits (optional): { "": "" } to choose the unit used for "value" in the result; "siValue" is always SI.
runId (optional): supplied by you, or generated as -<4 hex>. Must be new; the app never overwrites a result.
timeoutSeconds (optional): how long to wait for the result. Default from SETOOLBOX_AGENT_TIMEOUT_S (60).
Returns the result file as JSON, unchanged. Top-level keys in order: status, answer, assurance, result, warnings, run, then agentInstruction or the error fields.
status "ok": answer.value/unit in display units, answer.siValue/siUnit in SI; result[] echoes every derived quantity and every supplied input (state entered or pinned). Compare runs on siValue.
status "undetermined": answer.value is null, answer.missingInputs names what to supply, and agentInstruction says to report the quantity as not determined. This is a normal outcome, not an error.
status "error": error code plus field, received, allowed (when a finite set exists), and nextAction. Fix the request and resubmit with a new runId.
assurance is never empty. link_budget and radar_range: level "computed", citations false. eoir: level "traced", with citation and determinacy on each quantity.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| save | No | Create one saved analysis. | |
| tool | Yes | One of link_budget, radar_range, eoir. | |
| runId | No | The request's runId. | |
| inputs | Yes | Field name to value, per schema/<tool>.json. | |
| displayUnits | No | Field name to display unit. | |
| timeoutSeconds | No | Seconds to wait for the result. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover only safety flags; the description adds substantive behavior: it writes and reads files, runIds are never overwritten, timeouts leave the request queued, and error semantics map to nextAction. This is far beyond what the structured fields disclose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Long but well-structured with Args and Returns sections, front-loaded with the core action. Given six parameters and a complex result contract, every sentence carries usable information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description carries the return-value burden and does so thoroughly: top-level key order, status ok/undetermined/error semantics, assurance levels per tool, and tool-error conditions. Nothing material for correct invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% but the schema descriptions are terse; the description adds the quantity format ({value, unit}), rejection of bare numbers and unknown fields, no default-filling, save-vs-compute semantics, displayUnits vs siValue, and runId/timeout behavior. This meaningfully exceeds the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Submit one calculation request to SEToolBox and wait for its result') and clarifies the tool's actual role ('only writes the request file and reads the result file back verbatim'). An agent can distinguish it from siblings like setoolbox_get_result directly from the text.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear operational guidance: omit inputs the user did not supply, never resubmit under the same runId, and use setoolbox_get_result to retrieve a result after a timeout. It does not explicitly state when to prefer this over every alternative sibling, but the retrieval-path routing is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false), but the description adds genuine behavior: it never throws on a missing folder and directs the caller to read folderPresent instead. It does not discuss latency or cost, but for a local read-only status probe that omission is minor.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with what is returned, then the diagnostic guidance, then the error-behavior caveat. The middle sentence is long but every clause (threshold, causes) earns its place. No filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description carries the return-value burden and does so by naming folderPresent, queueDepth, schema version, and result age. Combined with the error-handling note, an agent has everything needed to call and interpret this zero-argument probe.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so the baseline is 4. The description's mentions of queueDepth and folderPresent refer to output fields rather than inputs, so there is no parameter semantics to add.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb ('Report') and enumerates exactly what is reported: folder existence/preparedness, per-tool schema version, in/ queueDepth, and age of the newest result. This clearly separates it from siblings like setoolbox_list_tools or setoolbox_get_schema, which return different content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives an explicit trigger ('Use it to tell the user "SEToolBox is not running" when runs time out') and even interprets the output threshold ('queueDepth above zero for longer than a few seconds') with the likely causes (app closed, runs off, iPad not foreground). The when-to-use condition is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.2.0setoolbox_get_resultsetoolbox_get_schemasetoolbox_list_projectssetoolbox_list_runssetoolbox_list_toolssetoolbox_read_projectsetoolbox_runsetoolbox_statusScored 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.
AI-callable calculators and engineering models with real formulas. No hallucinated math.
Create RF signal projects from prompts, inspect graphs, and export IQ data.
Precision math engine for AI agents. 203 exact methods. Zero hallucination.
# TrueCalci Precision Compute Engine Deterministic statutory, financial, and engineering computational tools for AI agents, developers, and autonomous workflows over the Model Context Protocol (MCP). ### Capabilities (25 Verified Engines): - **Specialist FinOps:** Remote Contractor vs. W-2 Parity, S-Corp Reasonable Compensation (IRS Rev. Rul. 74-44), Solo 401(k) Shelter, Cross-Border FX Drag, Billable Capacity Floor. - **Global & Cross-Border Tax:** US Form 2555 FEIE Nomad Stacking, B2B Foreign
