Field Service Business Platform by Doing Work

imports_historyRun

Owner only: write a history import the owner confirmed in imports.historyPreview (send its preview_hash, plus the same csv, kind, source, on_match and mapping). Records already imported are matched by old id and skipped or updated, never duplicated. Imported quotes and invoices are drafts and are not sent. Maintenance plans become service-due reminders (no invoice, no charge), or with plans_as billed, maintenance plans at the confirmed price with auto_send off and no invoice until the next due date; payments become read-only history records (no charge, no fee, no invoice change). flat_rate rows become price book tasks, matched by old id, then task code, then name. mode all_or_nothing (default) or per_row.

Input Schema

Name	Required	Description
`csv`	Yes
`kind`	Yes
`mode`	No
`source`	No	Where the file came from, like jobber or housecall_pro. Old ids are remembered per source. Defaults to the preset, or csv.
`mapping`	Yes
`shop_id`	Yes
`on_match`	No	What to do with a record already imported (same old id) or already in Doing Work. skip (default) leaves it as it is; update refreshes jobs (summary, status, new visits) and price book items. Quotes and invoices are never changed after import.
`plans_as`	No	maintenance_plans only. reminders (default): service due reminders, no money. billed: real maintenance plans at the price per term in the file, which the owner confirms in the preview. Each plan's next invoice is made on its next due date and is not sent on its own (auto_send off).
`preview_hash`	Yes
`equipment_kind`	No	equipment kind only: the type for every row when the file has no type column, like Furnace for a Jobber custom field "Furnace Model". Guessed from the column names when left out; the preview returns it.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedNov 2, 2026

addedInput schema / properties / equipment_kind

Added value: +{
+  "description": "equipment kind only: the type for every row when the file has no type column, like Furnace for a Jobber custom field \"Furnace Model\". Guessed from the column names when left out; the preview returns it.",
+  "maxLength": 100,
+  "minLength": 1,
+  "type": "string"
+}

addedInput schema / properties / plans_as

Added value: +{
+  "description": "maintenance_plans only. reminders (default): service due reminders, no money. billed: real maintenance plans at the price per term in the file, which the owner confirms in the preview. Each plan's next invoice is made on its next due date and is not sent on its own (auto_send off).",
+  "enum": [
+    "reminders",
+    "billed"
+  ],
+  "type": "string"
+}

First observedNov 1, 2026

TDQS

A4.3/5.0

Behavior4/5

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

With no annotations, the description carries the full burden and delivers: dedup by old id (skip/update, never duplicated), quotes and invoices land as drafts and are never sent, plans become reminders or priced plans with auto_send off, payments become read-only records, flat_rate matches on old id then task code then name. Gaps: it names mode 'all_or_nothing (default) or per_row' without explaining what happens on a partial failure, and says nothing about reversibility or error reporting.

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?

Front-loaded with the access constraint and the prerequisite, then dense per-kind effects with no filler. The sentence about maintenance plans is long and clause-heavy, but every clause carries behavioral information an agent needs.

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

Completeness4/5

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

For a 10-parameter mutation tool with no annotations, the description covers the risky parts well and the output schema handles return values. What keeps it from full marks is the unexplained mode semantics and the unmentioned equipment_kind, which matters for equipment imports.

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?

Schema coverage is only 40%, but the prose compensates by tying preview_hash to the preview step and grouping csv/kind/source/on_match/mapping as the payload that must match the confirmation. It also explains the per-kind effect of `kind` and of plans_as beyond the schema text. equipment_kind and shop_id are never mentioned, leaving a real coverage gap.

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?

States a specific verb and resource ('write a history import') plus the mandatory prerequisite ('the owner confirmed in imports.historyPreview'), which cleanly separates it from imports_historyPreview, imports_preview and imports_run. The 'Owner only' prefix establishes the actor scope up front.

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

Usage Guidelines4/5

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

Gives a clear precondition and call recipe: only after confirming in imports.historyPreview, and resend the same csv, kind, source, on_match and mapping plus the preview_hash. It does not explicitly contrast itself with imports_run or imports_preview, so an agent must infer that distinction from the names.

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

All Field Service Business Platform by Doing Work 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?