SMI Aware Assistant

Submit Exports

smi_submit_exports

Submits previously created SMI export drafts (Draft status only) for processing. A batch of up to 25 ids is processed immediately and the result lists accepted and rejected ids. A larger batch runs as a background job that the server waits on for a few seconds, then returns the same accepted and rejected ids plus the jobId. If the result has status queued, the job is still running or could not be read: call smi_get_job with its jobId and do not resubmit the ids. If the job failed, SMI does not say whether any id was submitted: check each id with smi_check_order_complete before resubmitting. SMI notifies the user when each export is released; smi_check_order_complete reads the status of a single record.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "ids": "<ids>"
    },
    "name": "smi_submit_exports"
  }
}

Input Schema

Name	Required	Description	Default
`ids`	Yes

Output Schema

Name	Required	Description	Default
`mode`	Yes
`jobId`	No
`status`	Yes
`accepted`	Yes
`rejected`	Yes
`releaseJobs`	No
`outcomesEnumerated`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedNov 9, 2026

addedOutput schema / properties / jobId
```
Added value: +{
+  "type": "number"
+}
```

addedOutput schema / properties / mode

Added value: +{
+  "enum": [
+    "sync",
+    "async"
+  ],
+  "type": "string"
+}

addedOutput schema / properties / releaseJobs

Added value: +{
+  "items": {
+    "additionalProperties": false,
+    "properties": {
+      "id": {
+        "type": "number"
+      },
+      "jobId": {
+        "type": "number"
+      }
+    },
+    "required": [
+      "id",
+      "jobId"
+    ],
+    "type": "object"
+  },
+  "type": "array"
+}

changedOutput schema / required

Previous value: -[
-  "status",
-  "accepted",
-  "rejected",
-  "outcomesEnumerated"
-]New value: +[
+  "mode",
+  "status",
+  "accepted",
+  "rejected",
+  "outcomesEnumerated"
+]

First observedSep 23, 2026

TDQS

A4.6/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations declare a mutating, non-idempotent, non-destructive, open-world call, and the description corroborates and enriches this with the batch-size threshold, the asynchronous job behavior, the jobId returned, and the explicit warning not to resubmit. What it does not cover is the notification mechanism's timing or the fate of ids that were accepted but later fail processing, which would round out the mutation semantics.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Content is front-loaded and operational: the core operation, then batch thresholds, then the two remediation paths. The final sentence is somewhat dense and the clause restating that smi_check_order_complete reads a single record's status is near-redundant, but no sentence is pure padding.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given an existing output schema, the description still usefully previews the shape of the result (accepted/rejected ids, jobId, queued status) and covers the full decision tree an agent faces after the call. Nothing needed to invoke it correctly or react to its outcomes is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 0% description coverage on a single `ids` array, so the description must carry the meaning, and it does partially: it defines ids as export draft ids in Draft status and explains the 25-id behavioral split. It stops short of clarifying whether an id is the string external id or the integer internal id, which is exactly the ambiguity the anyOf schema leaves open.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource ("Submits ... SMI export drafts") plus a hard precondition ("Draft status only") that separates it from smi_create_export and smi_submit_deep_reports. An agent knows exactly what operation this performs and on what input state.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives explicit branching guidance: batches up to 25 process immediately, larger batches become background jobs, a queued result means call smi_get_job and never resubmit, and a failed job means verify each id with smi_check_order_complete before retrying. Alternatives are named with the exact condition that selects them, leaving nothing to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All SMI Aware Assistant tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?