Field service dispatch: instant quotes, tracked work orders, public evals. steadywrk.app
Scored across 6 tools
Most tools are clearly distinct: dispatch.index catalogs verticals, dispatch.estimate gives public modeled pricing, dispatch.quote requests an official quote, and dispatch.order creates an order. The only true overlap is estimate vs. quote, but their descriptions explicitly cross-reference each other to disambiguate.
The five dispatch.* tools share a clear namespace, but the tool names are not in a consistent verb_noun pattern and `agentic.readiness_probe` breaks the namespace convention entirely. The naming is readable, but it is a mixed style rather than a predictable action-oriented scheme.
Six tools is a reasonable count for a dispatch-oriented server and the estimate/quote/order flow is well represented. The unrelated storefront readiness probe makes the set feel slightly less cohesive, but the count itself is not excessive or thin.
The core field-service workflow is covered: a user can browse verticals, get a public estimate, request an official quote, and create an order. Missing order-management operations, such as cancel or retrieve, are minor gaps for a dispatch creator server rather than fatal dead ends.
Free multi-surface storefront readiness snapshot (UCP/ACP discovery, product schema, robots, answer-engine maps). Not an attested Store Guard grade. Response includes a Store Guard $149 CTA. No API key required.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Public storefront URL or domain |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds useful behavioral context beyond annotations: free, no API key required, not attested, and a $149 CTA in the response. However, annotations mark readOnlyHint=false and idempotentHint=false, while the description frames the tool as an 'inspect'/'snapshot', so expected side effects are left ambiguous; the description does not clarify whether probing the target has write or non-idempotent consequences.
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, no filler. The core purpose is front-loaded and every sentence earns its place: scope of scan, limitation vs Store Guard, CTA, and authentication requirement.
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 single-parameter tool with an output schema, the description covers cost, auth, non-attestation, and the commercial CTA. It does not address potential rate limits or side effects of probing an external URL, so it is not quite complete, but nothing essential to invoking it 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 description coverage is 100% — the 'url' property already says 'Public storefront URL or domain' and maxLength 255. The description reinforces that the target must be public ('multi-sureface storefront readiness') but does not add format or syntax guidance, so it stays at the baseline for fully documented parameters.
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 action ('readiness snapshot') and concrete outputs ('UCP/ACP discovery, product schema, robots, answer-engine maps'), and explicitly disclaims being an 'attested Store Guard grade'. This is immediately distinguishable from the dispatch.* siblings and from the paid Store Guard product.
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 selection context: free, no API key required, multi-surface storefront readiness check. The exclusion ('Not an attested Store Guard grade') tells the agent this is not the paid/attested alternative, and the CTA is disclosed upfront. It does not explicitly name an alternative tool, but none of the dispatch.* siblings compete for this job.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Public modeled field-service price estimate using cited BLS wage data and disclosed model assumptions. Returns wage_basis and billed_estimate so callers can inspect the calculation and geographic basis. The response identifies estimates based on a national baseline and distinguishes model assumptions from observed prices. Use dispatch.quote with an accepted credential to request a quote. No API key required.
| Name | Required | Description | Default |
|---|---|---|---|
| trade | Yes | Trade code (plumbing, electrical, HVAC, etc.) | |
| urgency | No | routine | |
| location | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnly, idempotent, and non-destructive behavior, so the description adds value by disclosing that this is a modeled estimate using cited BLS wage data, that responses distinguish model assumptions from observed prices, and that a national baseline is used. This goes beyond annotation hints without contradicting them.
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 description is front-loaded with the core purpose and data source, then explains the return fields, then the model vs. observed distinction, and finally the quote alternative. Every sentence carries distinct information with no redundancy.
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 an output schema present and annotations covering safety, the description supplies the missing context: public access, no API key, cited data source, returns for inspection, and the route to get a real quote. It is slightly light on how parameters like urgency affect the estimate, but the schema and output schema cover much of the remaining needed detail.
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 only 33%, so the description should compensate for undocumented parameters, but it does not. It mentions 'geographic basis' and a 'national baseline,' which loosely relates to location, but it provides no meaningful guidance on trade, urgency, or location semantics beyond the schema's terseness.
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 uses a specific verb and resource: 'field-service price estimate' with a clear modeled/observed distinction. It also differentiates from the sibling tool by explicitly saying quote requests belong to dispatch.quote, so an agent can immediately tell this tool apart.
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 description explicitly points to dispatch.quote with an accepted credential for requesting a quote, which clarifies the main alternative. It also states that no API key is required, giving a clear access condition. It does not enumerate all sibling tools, but the key decision boundary is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the public evaluation document for a selected rolling window. Consult its per-field provenance and methodology to distinguish self-reported estimates, measurements, and unavailable fields. It is not an independent audit or a service-level guarantee. No API key required.
| Name | Required | Description | Default |
|---|---|---|---|
| period | No | rolling_30d |
| Name | Required | Description |
|---|---|---|
| period | Yes | |
| estimated | Yes | False only when goal-fulfillment rates are backed by fresh, sufficient production telemetry. |
| provenance | Yes | Per-field record of whether each published figure is measured or estimated. |
| methodology | Yes | Metric definitions, named-period window, source-class vocabulary. Never a sample size. |
| operational | Yes | |
| trust_signals | Yes | |
| schema_version | Yes | |
| goal_fulfillment | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive hints. The description adds valuable context beyond that: the document is public, requires no API key, contains per-field provenance and methodology, and is not an audit or guarantee. This meaningfully shapes an agent's expectations about access and interpretation.
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 description is three sentences with no filler. It front-loads the primary purpose, then adds the key caveats and access requirement. Every sentence earns its place.
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 single-parameter read tool with rich annotations and an output schema, the description covers purpose, caveats, access requirements, and how to interpret the returned data. Nothing necessary for an agent to call this tool 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 schema has one parameter, 'period', with an enum and default, so the allowed values are already explicit. The description adds the semantic framing of 'rolling window' but does not mention the parameter name or default. Given the schema carries most parameter meaning, the description provides partial but not complete compensation.
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 uses a specific verb ('Return') with a specific resource ('public evaluation document') and scoping ('selected rolling window'). It clearly differentiates from sibling tools like dispatch.estimate and dispatch.index by emphasizing that this is an evaluation document with provenance, not an estimate or operational record.
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 description gives clear usage context: consult the evaluation document to distinguish self-reported estimates, measurements, and unavailable fields. It also provides an explicit when-not-to-use signal by stating it is not an independent audit or service-level guarantee. It stops short of naming specific sibling alternatives for other use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the catalog of 8 dispatch trade verticals. Per trade: the BLS OES hourly WAGE (medianRateDollars/p25/p75 — what a technician earns, NOT a price) alongside billedHourlyRateRoutineDollars, what a buyer pays hourly at routine urgency, derived by the same wage→billed transform dispatch.estimate uses. See the wage_vs_billed block. No API key required.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| note | Yes | |
| trades | Yes | |
| updated_at | Yes | |
| source_period | Yes | |
| wage_vs_billed | Yes | |
| model_assumptions | Yes | |
| rate_model_version | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds meaningful context: it clarifies that wages are technician earnings (not prices), explains the billing derivation from the same transform dispatch.estimate uses, and notes that no API key is required. This goes beyond the annotations without contradicting them.
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 description is compact yet dense with information. Every sentence serves a purpose: it states the resource, enumerates the fields, clarifies semantics (wage vs. price), and connects to the sibling tool. It is well front-loaded with the core purpose and then adds the clarifying details.
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 zero-parameter read-only catalog tool with an output schema, the description is nearly complete. It provides the key context an agent needs: what the data represents, how the billed rate is derived, and that no auth is required. The only minor gap is not mentioning pagination or size limits, but for 8 verticals this is likely a non-issue, and the output schema covers return structure.
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 input schema has zero parameters and 100% schema description coverage, so the schema already tells the agent there are no inputs. The description reinforces this by stating the exact fixed content (8 verticals with specific fields) and the wage vs. billed distinction, which is useful for understanding the output without needing parameters.
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 uses a specific verb ('Return') and clearly identifies the resource: the catalog of 8 dispatch trade verticals. It distinguishes itself from siblings by emphasizing the catalog and wage-vs-billed distinction, which is not something dispatch.estimate or dispatch.process would provide.
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 states when to use this tool (to read the catalog) and clarifies that it is not a price lookup, which prevents misuse. It doesn't explicitly name alternatives like dispatch.estimate or dispatch.process, but the context strongly implies the catalog is the reference for estimates, so the usage context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a field-service order and return its status URL. HTTP 201 returns a created order; HTTP 202 returns an order accepted_pending_fulfilment with fulfilled=false. Order creation requires a provisioned integration key through x-api-key. MCP also accepts that key through Authorization: Bearer; direct REST order creation requires x-api-key. A self-serve OAuth token authenticates but is not entitled to create orders: HTTP 402 payment_required (JSON-RPC -32002 over MCP). Anonymous callers receive HTTP 401 with WWW-Authenticate. Provisioning contact: hello@steadywrk.app.
| Name | Required | Description | Default |
|---|---|---|---|
| trade | Yes | ||
| urgency | No | routine | |
| location | Yes | ||
| nte_cents | No | ||
| description | Yes | ||
| callback_url | No | ||
| reference_id | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint=false, destructiveHint=true), the description adds substantial behavioral detail: exact HTTP success codes and their meanings, the accepted_pending_fulfilment state, authentication mechanisms, OAuth entitlement limitations with HTTP 402, and anonymous caller behavior with HTTP 401. This is rich, non-obvious context that helps an agent anticipate side effects and errors.
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 description is dense but well-structured, with the core purpose front-loaded and each subsequent sentence covering a distinct and important aspect: response codes, authentication options, entitlement restrictions, failure modes, and support contact. There is 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?
For a creation tool with complex authentication, entitlement, and response semantics, the description covers all critical aspects an agent needs to invoke it correctly: expected status codes, required auth context, OAuth limitations, failure responses, and a support contact. Since an output schema exists, detailed return-value documentation is not necessary here.
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 0%, so the description must compensate for parameter meaning. It does not explain any of the seven parameters, such as nte_cents, callback_url, reference_id, or the nested location object. While the parameter names are somewhat self-explanatory and the schema provides types/defaults/enums, the description adds no semantic value beyond what the schema already shows.
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 and resource: 'Create a field-service order and return its status URL.' This clearly identifies the tool's action and differentiates it from sibling tools like dispatch.estimate and dispatch.quote, which are concerned with estimation and quoting rather than order creation.
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 description gives clear operational guidance: HTTP 201 vs 202 outcomes, the need for a provisioned integration key via x-api-key, and the alternative Authorization: Bearer mechanism for MCP. It also explains that OAuth tokens are authenticated but not entitled to create orders. It does not explicitly name sibling alternatives for when not to use this tool, but the context of when to use it is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Request a field-service quote by trade, location, and urgency. Returns availability and quote details when available. Accepts a provisioned integration key through x-api-key or, when OAuth is enabled, a scoped self-serve OAuth token through Authorization: Bearer. MCP also accepts the provisioned key through Authorization: Bearer. Request a key at hello@steadywrk.app. Anonymous callers receive HTTP 401 with WWW-Authenticate. Public modeled pricing is available through dispatch.estimate.
| Name | Required | Description | Default |
|---|---|---|---|
| trade | Yes | Trade code (plumbing, electrical, HVAC, etc.) | |
| urgency | No | routine | |
| location | Yes | ||
| nte_cents | No | ||
| description | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds meaningful behavioral context beyond the annotations: authentication requirements, the WWW-Authenticate response for anonymous callers, and the 'when available' caveat on return data. It does not contradict the annotations, and though readOnlyHint is false, the description neither claims nor denies read-only semantics.
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 description is a compact four sentences, front-loaded with purpose, and every sentence contributes either the core operation, return behavior, authentication context, or an alternative routing. No filler or redundant restatement of the title.
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?
Given the tool has a nested location object, an output schema, and several parameters, the description covers the essential invocation context: what it does, how authentication works, what it returns, and when to use the sibling estimate tool. It omits semantics for nte_cents and description, but the presence of an output schema partially compensates for return-value expectations.
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 description explains the roles of trade, location, and urgency, but does not clarify nte_cents or the description parameter. With only 20% schema description coverage, those fields remain semantically undocumented in both the schema and the description, so the compensation is partial.
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 uses a specific verb, 'Request', names the resource 'field-service quote', and qualifies it with trade, location, and urgency. It explicitly states what the tool returns and distinguishes it from dispatch.estimate, its closest sibling.
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 clearly explains the authentication context, including accepted key methods, the anonymous-caller 401 behavior, and how to obtain a key. It also names dispatch.estimate as the alternative for public modeled pricing, giving the agent enough information to choose between siblings.
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.
agentic.readiness_probe1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "description": "Either a successful probe (ok=true, report + demo) or a business error (e.g. missing url) — never a fabricated report.",
+ "oneOf": [
+ {
+ "properties": {
+ "demo": {
+ "properties": {
+ "hashSnippet": {
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "permalink": {
+ "type": "string"
+ },
+ "persisted": {
+ "type": "boolean"
+ },
+ "verifyPath": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "permalink",
+ "verifyPath",
+ "hashSnippet",
+ "persisted"
+ ],
+ "type": "object"
+ },
+ "ok": {
+ "const": true,
+ "type": "boolean"
+ },
+ "report": {
+ "properties": {
+ "checks": {
+ "items": {
+ "properties": {
+ "detail": {
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "label": {
+ "type": "string"
+ },
+ "status": {
+ "enum": [
+ "pass",
+ "warn",
+ "fail",
+ "skip"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "label",
+ "status",
+ "detail"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "grade": {
+ "enum": [
+ "A",
+ "B",
+ "C",
+ "D",
+ "F"
+ ],
+ "type": "string"
+ },
+ "host": {
+ "type": "string"
+ },
+ "next": {
+ "properties": {
+ "flagship": {
+ "type": "string"
+ },
+ "sample": {
+ "type": "string"
+ },
+ "storeGuardBuy": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "origin": {
+ "type": "string"
+ },
+ "probedAt": {
+ "type": "string"
+ },
+ "score": {
+ "type": "number"
+ },
+ "summary": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "host",
+ "origin",
+ "score",
+ "grade",
+ "summary",
+ "checks",
+ "probedAt",
+ "next"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "ok",
+ "report",
+ "demo"
+ ],
+ "type": "object"
+ },
+ {
+ "additionalProperties": true,
+ "description": "Business error — e.g. missing/invalid url argument, rate limit.",
+ "properties": {
+ "error": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "error"
+ ],
+ "type": "object"
+ }
+ ],
+ "type": "object"
+}dispatch.estimate1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "description": "A full wage-to-billed-rate estimate, or an unknown/missing trade error — never a fabricated number.",
+ "oneOf": [
+ {
+ "properties": {
+ "basis": {
+ "const": "wage_to_billed_rate_transform",
+ "type": "string"
+ },
+ "billed_estimate": {
+ "additionalProperties": true,
+ "description": "What a buyer pays — every component of the arithmetic, re-derivable via formula.",
+ "properties": {
+ "billed_hourly_rate_cents": {
+ "type": "integer"
+ },
+ "billed_hourly_rate_routine_cents": {
+ "type": "integer"
+ },
+ "currency": {
+ "const": "USD",
+ "type": "string"
+ },
+ "formula": {
+ "type": "string"
+ },
+ "labor_burden_multiplier": {
+ "type": "number"
+ },
+ "minimum_billable_hours": {
+ "type": "number"
+ },
+ "total_cents": {
+ "type": "integer"
+ },
+ "total_usd": {
+ "type": "number"
+ },
+ "trip_fee_cents": {
+ "type": "integer"
+ },
+ "urgency_multiplier": {
+ "type": "number"
+ }
+ },
+ "type": "object"
+ },
+ "disclosure": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "estimated": {
+ "const": true,
+ "type": "boolean"
+ },
+ "estimated_cost_cents": {
+ "description": "Alias of billed_estimate.total_cents.",
+ "type": "integer"
+ },
+ "location_resolution": {
+ "additionalProperties": true,
+ "properties": {
+ "location_sensitive": {
+ "type": "boolean"
+ },
+ "reason": {
+ "type": "string"
+ },
+ "resolved_metro": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "resolved_metro_label": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "scope": {
+ "enum": [
+ "metro_cited",
+ "national_baseline",
+ "mena_coverage_beta"
+ ],
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "rate_card": {
+ "properties": {
+ "median_dollars": {
+ "type": "number"
+ },
+ "p25_dollars": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "p75_dollars": {
+ "type": [
+ "number",
+ "null"
+ ]
+ }
+ },
+ "type": "object"
+ },
+ "rate_model_version": {
+ "type": "string"
+ },
+ "source": {
+ "const": "public_rate_card",
+ "type": "string"
+ },
+ "trade": {
+ "type": "string"
+ },
+ "urgency": {
+ "enum": [
+ "emergency",
+ "urgent",
+ "routine",
+ "scheduled"
+ ],
+ "type": "string"
+ },
+ "wage_basis": {
+ "additionalProperties": true,
+ "description": "The cited hourly WAGE input — NOT the price.",
+ "properties": {
+ "bls_occ_code": {
+ "type": "string"
+ },
+ "kind": {
+ "const": "hourly_wage",
+ "type": "string"
+ },
+ "median_cents": {
+ "type": "integer"
+ },
+ "note": {
+ "type": "string"
+ },
+ "p25_cents": {
+ "type": [
+ "integer",
+ "null"
+ ]
+ },
+ "p75_cents": {
+ "type": [
+ "integer",
+ "null"
+ ]
+ },
+ "scope_label": {
+ "type": "string"
+ },
+ "source_url": {
+ "type": "string"
+ },
+ "trade_label": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ }
+ },
+ "required": [
+ "estimated",
+ "source",
+ "basis",
+ "rate_model_version",
+ "trade",
+ "urgency",
+ "location_resolution",
+ "wage_basis",
+ "billed_estimate",
+ "estimated_cost_cents",
+ "rate_card",
+ "disclosure"
+ ],
+ "type": "object"
+ },
+ {
+ "description": "Trade was missing or not recognized. No number is fabricated.",
+ "properties": {
+ "error": {
+ "enum": [
+ "unknown_trade",
+ "trade_required"
+ ],
+ "type": "string"
+ },
+ "estimated": {
+ "const": false,
+ "type": "boolean"
+ },
+ "known_trades": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "source": {
+ "const": "public_rate_card",
+ "type": "string"
+ },
+ "trade": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "valid_trades": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "estimated",
+ "source",
+ "error",
+ "trade",
+ "valid_trades",
+ "known_trades"
+ ],
+ "type": "object"
+ }
+ ],
+ "type": "object"
+}dispatch.evals1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "estimated": {
+ "description": "False only when goal-fulfillment rates are backed by fresh, sufficient production telemetry.",
+ "type": "boolean"
+ },
+ "goal_fulfillment": {
+ "additionalProperties": true,
+ "properties": {
+ "completion_rate": {
+ "type": "number"
+ },
+ "human_override_rate": {
+ "type": "number"
+ },
+ "nte_accuracy": {
+ "type": "number"
+ },
+ "redispatch_rate": {
+ "type": "number"
+ },
+ "sampled_at": {
+ "type": "string"
+ },
+ "source": {
+ "enum": [
+ "live_telemetry",
+ "canonical_estimate"
+ ],
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "methodology": {
+ "additionalProperties": true,
+ "description": "Metric definitions, named-period window, source-class vocabulary. Never a sample size.",
+ "type": "object"
+ },
+ "operational": {
+ "additionalProperties": true,
+ "properties": {
+ "active_providers": {
+ "type": "null"
+ },
+ "active_states": {
+ "type": "string"
+ },
+ "avg_dispatch_latency_ms": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "jobs_dispatched_30d": {
+ "type": "null"
+ },
+ "latency_source": {
+ "type": "string"
+ },
+ "p95_dispatch_latency_ms": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "pricing_latency_p50_ms": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "pricing_latency_p95_ms": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "pricing_latency_sampled_at": {
+ "type": "string"
+ },
+ "pricing_latency_source": {
+ "enum": [
+ "live_telemetry",
+ "unavailable"
+ ],
+ "type": "string"
+ },
+ "quote_turnaround_hours": {
+ "type": "number"
+ },
+ "quote_turnaround_is_sla": {
+ "type": "boolean"
+ }
+ },
+ "type": "object"
+ },
+ "period": {
+ "enum": [
+ "rolling_7d",
+ "rolling_30d",
+ "rolling_90d"
+ ],
+ "type": "string"
+ },
+ "provenance": {
+ "additionalProperties": true,
+ "description": "Per-field record of whether each published figure is measured or estimated.",
+ "type": "object"
+ },
+ "schema_version": {
+ "type": "string"
+ },
+ "trust_signals": {
+ "properties": {
+ "build_hash": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ }
+ },
+ "required": [
+ "schema_version",
+ "period",
+ "estimated",
+ "goal_fulfillment",
+ "operational",
+ "trust_signals",
+ "provenance",
+ "methodology"
+ ],
+ "type": "object"
+}dispatch.index1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "model_assumptions": {
+ "type": "string"
+ },
+ "note": {
+ "type": "string"
+ },
+ "rate_model_version": {
+ "type": "string"
+ },
+ "source_period": {
+ "type": "string"
+ },
+ "trades": {
+ "items": {
+ "additionalProperties": true,
+ "description": "kind is always \"hourly_wage\" — medianRateDollars/p25/p75 (and their *Wage* aliases) are what a technician earns, NOT a price. billedHourlyRateRoutine* is what a buyer pays.",
+ "properties": {
+ "billedHourlyRateRoutineCents": {
+ "type": "integer"
+ },
+ "billedHourlyRateRoutineDollars": {
+ "type": "number"
+ },
+ "kind": {
+ "const": "hourly_wage",
+ "type": "string"
+ },
+ "medianWageDollars": {
+ "type": "number"
+ },
+ "p25WageDollars": {
+ "type": "number"
+ },
+ "p75WageDollars": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "kind",
+ "medianWageDollars",
+ "p25WageDollars",
+ "p75WageDollars",
+ "billedHourlyRateRoutineCents",
+ "billedHourlyRateRoutineDollars"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "updated_at": {
+ "type": "string"
+ },
+ "wage_vs_billed": {
+ "additionalProperties": true,
+ "properties": {
+ "billed_fields": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "formula": {
+ "type": "string"
+ },
+ "full_estimate_tool": {
+ "type": "string"
+ },
+ "labor_burden_multiplier": {
+ "type": "number"
+ },
+ "overhead_margin_markup": {
+ "type": "number"
+ },
+ "wage_fields": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "warning": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ }
+ },
+ "required": [
+ "trades",
+ "wage_vs_billed",
+ "note",
+ "model_assumptions",
+ "updated_at",
+ "source_period",
+ "rate_model_version"
+ ],
+ "type": "object"
+}dispatch.order1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "description": "A recorded work order — fulfilled (contractor matched, HTTP 201) or accepted_pending_fulfilment (no contractor yet, HTTP 202) — or a business/entitlement error passthrough.",
+ "oneOf": [
+ {
+ "properties": {
+ "accepted": {
+ "const": true,
+ "type": "boolean"
+ },
+ "created": {
+ "const": true,
+ "type": "boolean"
+ },
+ "fulfilled": {
+ "type": "boolean"
+ },
+ "fulfilment": {
+ "description": "Present only when fulfilled=false.",
+ "properties": {
+ "assigned": {
+ "const": false,
+ "type": "boolean"
+ },
+ "detail": {
+ "type": "string"
+ },
+ "escalation_contact": {
+ "type": "string"
+ },
+ "reason": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "order": {
+ "additionalProperties": true,
+ "properties": {
+ "assigned_contractor_ref": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "created_at": {
+ "type": "string"
+ },
+ "estimated_response_minutes": {
+ "type": [
+ "number",
+ "null"
+ ]
+ },
+ "id": {
+ "type": "string"
+ },
+ "location": {
+ "type": "object"
+ },
+ "quoted_cost_cents": {
+ "type": [
+ "integer",
+ "null"
+ ]
+ },
+ "quoted_cost_usd": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "status": {
+ "enum": [
+ "pending_dispatch",
+ "accepted_pending_fulfilment"
+ ],
+ "type": "string"
+ },
+ "trade": {
+ "type": "string"
+ },
+ "urgency": {
+ "enum": [
+ "emergency",
+ "urgent",
+ "routine",
+ "scheduled"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "status",
+ "trade",
+ "location",
+ "urgency",
+ "created_at"
+ ],
+ "type": "object"
+ },
+ "tracking": {
+ "properties": {
+ "auth": {
+ "type": "string"
+ },
+ "status_url": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ }
+ },
+ "required": [
+ "created",
+ "accepted",
+ "fulfilled",
+ "order",
+ "tracking"
+ ],
+ "type": "object"
+ },
+ {
+ "additionalProperties": true,
+ "description": "Business/rate-limit/entitlement error passthrough.",
+ "properties": {
+ "error": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "error"
+ ],
+ "type": "object"
+ }
+ ],
+ "type": "object"
+}dispatch.quote1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "description": "A matched-contractor quote, a no-availability response, or a business/auth error passthrough from the downstream dispatch API.",
+ "oneOf": [
+ {
+ "description": "A contractor was matched.",
+ "properties": {
+ "available": {
+ "const": true,
+ "type": "boolean"
+ },
+ "next_steps": {
+ "properties": {
+ "contact": {
+ "type": "string"
+ },
+ "dispatch": {
+ "type": "string"
+ },
+ "docs": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "quote": {
+ "properties": {
+ "alternates_count": {
+ "type": "integer"
+ },
+ "best_match": {
+ "properties": {
+ "estimated_cost_cents": {
+ "type": "integer"
+ },
+ "estimated_cost_usd": {
+ "type": "string"
+ },
+ "estimated_response_minutes": {
+ "type": "number"
+ },
+ "match_score": {
+ "type": "number"
+ }
+ },
+ "type": "object"
+ },
+ "estimated_eta": {
+ "type": "string"
+ },
+ "generated_at": {
+ "type": "string"
+ },
+ "location": {
+ "type": "object"
+ },
+ "trade": {
+ "type": "string"
+ },
+ "urgency": {
+ "enum": [
+ "emergency",
+ "urgent",
+ "routine",
+ "scheduled"
+ ],
+ "type": "string"
+ },
+ "valid_for_minutes": {
+ "type": "integer"
+ }
+ },
+ "required": [
+ "trade",
+ "location",
+ "urgency",
+ "estimated_eta",
+ "best_match",
+ "alternates_count",
+ "generated_at",
+ "valid_for_minutes"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "available",
+ "quote",
+ "next_steps"
+ ],
+ "type": "object"
+ },
+ {
+ "description": "No contractor is currently available for this trade/location.",
+ "properties": {
+ "available": {
+ "const": false,
+ "type": "boolean"
+ },
+ "location": {
+ "type": "object"
+ },
+ "message": {
+ "type": "string"
+ },
+ "trade": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "available",
+ "message",
+ "trade",
+ "location"
+ ],
+ "type": "object"
+ },
+ {
+ "additionalProperties": true,
+ "description": "Business/rate-limit/auth error passthrough.",
+ "properties": {
+ "error": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "error"
+ ],
+ "type": "object"
+ }
+ ],
+ "type": "object"
+}dispatch.estimateagentic.readiness_probedispatch.evalsdispatch.indexdispatch.orderdispatch.quoteManage jobs, customers, scheduling, estimates and invoices for a field service business.
Search customers, manage quotes, work orders, action items, and calendar events for your business
Field workforce scheduling for AI agents. GPS punches, forms, timesheets. No dashboard.
Job orders for trades and field work: parts, labour, status, completion report, invoice payload.
Add one secure layer between your agents and this server.
