STEADYWRK Field Service Dispatch

Server Details

Field service dispatch: instant quotes, tracked work orders, public evals. steadywrk.app

If you are the author of this connector, you can claim ownership with GitHub, an HTTP challenge, or a DNS record. Claimed connector authors can inspect health checks, view analytics, and manage their listing.

Status: Healthy
Last Tested: 2026-09-05 21:36
Transport: Streamable HTTP
URL

Available Tools

6 tools

agentic.readiness_probeInspect storefront readinessAInspect

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.

ParametersJSON Schema

Name	Required	Description	Default
`url`	Yes	Public storefront URL or domain

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4/5.0

Behavior3/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

dispatch.estimateEstimate dispatch costA

Read-onlyIdempotent

Inspect

Keyless billed-cost estimate for a field-service job. Transforms a cited BLS OES hourly WAGE into a billed customer price: wage x labor burden x overhead/margin markup x urgency multiplier, plus a trip fee and a minimum-billable-hours floor. Returns wage_basis (the cited wage input) alongside billed_estimate (every component of the arithmetic, re-derivable by the caller). Location is used where a cited BLS OEWS metro median exists (Dallas-Fort Worth, Houston, Phoenix, Atlanta); a set of MENA metros (Amman, Dubai, Abu Dhabi, Riyadh, Jeddah, Doha, Kuwait City, Manama, Cairo) are recognized as coverage-only (beta) — named, not fabricated, still priced off the US national baseline; everywhere else the payload states plainly that the figure is national-median and location-insensitive. Model assumptions are labelled as such — not observed STEADYWRK prices. Not a contractor-matched quote: use dispatch.quote with an API key for that. No API key required.

ParametersJSON Schema

Name	Required	Description	Default
`trade`	Yes	Trade code (plumbing, electrical, HVAC, etc.)
`urgency`	No		routine
`location`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already establish readOnly, idempotent, and non-destructive behavior. The description adds substantial behavioral context beyond those hints: it reveals the pricing model, which locations affect the estimate, that MENA metros are coverage-only and priced off the US baseline, that model assumptions are labeled and not observed prices, and that the output is re-derivable by the caller. There is no contradiction with annotations.

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?

The description is dense and information-rich, front-loaded with the core purpose and formula. Every sentence conveys useful detail, but the length is substantial and the prose is somewhat run-on with nested clauses. It could benefit from structured breaks, but it is not padded with fluff.

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 the output schema exists to document return values, the description effectively covers all selection and invocation context: input semantics, geographical behavior, data-source limitations, keyless access, and the alternative tool. Nothing critical is missing for an agent to decide whether and how to call this tool.

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 description coverage is only 33%, so the description must compensate. It does so meaningfully for location by detailing metro coverage and fallback behavior, and for urgency by describing its role as an 'urgency multiplier' in the formula. Trade receives less direct elaboration, though the BLS OES wage reference implies its role in wage lookup. Overall, the description adds substantial meaning beyond the minimal schema descriptions.

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: 'Keyless billed-cost estimate for a field-service job.' It then states exactly what the tool computes and returns, including the arithmetic formula and the wage_basis plus billed_estimate outputs. It also explicitly distinguishes itself from dispatch.quote, making sibling differentiation clear.

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?

The description gives explicit guidance on when to use this tool versus dispatch.quote: 'Not a contractor-matched quote: use dispatch.quote with an API key for that.' It also explains 'No API key required,' coverage conditions for US and MENA metros, and the national-median fallback, so an agent knows exactly the contexts where the estimate applies.

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

dispatch.evalsRead dispatch evaluationsA

Read-onlyIdempotent

Inspect

Return the public evals dashboard for a rolling window. Figures are estimated unless provenance.measured lists them. jobs_dispatched_30d and active_providers are null until a measured integer exists — not posture copy. No API key required.

ParametersJSON Schema

Name	Required	Description	Default
`period`	No		rolling_30d

Output Schema

ParametersJSON Schema

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

TDQS

A4.3/5.0

Behavior5/5

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

Beyond the readOnly/idempotent annotations, the description discloses meaningful behavior: figures are estimates unless provenance.measured lists them, specific fields remain null until a measured integer exists, and no API key is required. This is highly informative and adds real value 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.

Conciseness5/5

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

Three tight sentences, front-loaded with the core purpose and followed by high-value caveats. There is no filler or repetition of schema-visible facts.

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?

For a simple read-only tool with one optional parameter and an output schema, the description covers purpose, authentication, estimation behavior, and null-value semantics. Nothing essential is missing for an agent to select and invoke it correctly.

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

Parameters3/5

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

The only parameter, period, is fully constrained by an enum with a default in the schema, so the agent already knows the allowed values. The description adds the 'rolling window' framing but does not add direct parameter-level detail, which is acceptable given the schema's self-explanatory enum.

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: 'Return the public evals dashboard for a rolling window.' This clearly distinguishes it from sibling tools like dispatch.estimate or dispatch.order and states exactly what the tool provides.

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

Usage Guidelines3/5

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

The description makes it clear this is a public, no-auth evals dashboard lookup, but it does not explicitly contrast this tool with siblings or state when not to use it. The usage context is implied rather than directly guided.

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

dispatch.indexRead the dispatch trade catalogA

Read-onlyIdempotent

Inspect

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.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`note`	Yes
`trades`	Yes
`updated_at`	Yes
`source_period`	Yes
`wage_vs_billed`	Yes
`model_assumptions`	Yes
`rate_model_version`	Yes

TDQS

A4.4/5.0

Behavior4/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

dispatch.orderCreate a dispatch work orderA

Destructive

Inspect

Create a dispatch work order. Attempts to auto-match a contractor from the active pool. Returns HTTP 201 with a masked contractor reference when a contractor is matched, or HTTP 202 with status accepted_pending_fulfilment and fulfilment.assigned=false when none is available yet — in both cases the order is recorded and readable at the returned tracking.status_url. BILLABLE: this is the paid tool. It requires a provisioned STEADYWRK integration key presented as x-api-key (or Authorization: Bearer). A self-serve OAuth client_credentials token from /api/mcp/oauth/register authenticates and is accepted by dispatch.quote, but it is NOT entitled to create orders: it receives HTTP 402 payment_required (JSON-RPC -32002). Anonymous callers receive HTTP 401 with WWW-Authenticate. Email hello@steadywrk.app to be provisioned for ordering; price jobs meanwhile with dispatch.estimate (keyless) or dispatch.quote (self-serve credential).

ParametersJSON Schema

Name	Required	Default
`trade`	Yes
`urgency`	No	routine
`location`	Yes
`nte_cents`	No
`description`	Yes
`callback_url`	No
`reference_id`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.4/5.0

Behavior5/5

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

The description richly discloses behavior beyond the annotations: auto-match attempts, HTTP 201 vs 202 semantics, masked contractor references, readable tracking.status_url, billing implications, required x-api-key/Authorization, HTTP 402 and 401 failure modes, and the distinction between billable order creation and non-entitled self-serve credentials. This is far more than the sparse annotations provide.

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?

The description is dense but every sentence carries operational value: outcome statuses, billing, authentication, and routing to alternatives. It is longer than ideal, but not padded; the critical information is front-loaded.

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 complex, paid, side-effecting order-creation tool, the description covers authentication, billing, status codes, response location, and alternatives. The main gap is parameter semantics, but an output schema exists and the invocation and error pathways are clearly described.

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

Parameters2/5

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

Schema description coverage is 0%, so the description should compensate for parameter meaning, but it does not. It never explains trade values, location structure, urgency semantics, nte_cents, callback_url, or reference_id. An agent must rely on names alone, which is insufficient for this 7-parameter nested schema.

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: 'Create a dispatch work order.' It also distinguishes itself from siblings by naming dispatch.estimate and dispatch.quote as alternatives for pricing, making the tool's role unmistakable.

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?

Usage guidance is explicit: self-serve OAuth tokens are accepted by dispatch.quote but NOT entitled to create orders, provisioning requires email, and pricing should use dispatch.estimate or dispatch.quote. This clearly tells an agent when it may and may not call dispatch.order.

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

dispatch.quoteGet a dispatch quoteAInspect

Return an instant dispatch quote for a field-service job. Accepts trade + location + urgency and returns matched contractor, estimated cost in cents, ETA tier, and valid_for_minutes. Requires a client integration key (x-api-key or Authorization: Bearer). Self-serve machine credential: POST /api/mcp/oauth/register (RFC 7591), then POST /api/mcp/oauth/token with grant_type=client_credentials. Anonymous callers receive HTTP 401 with WWW-Authenticate. Self-serve machine credential, no human in the loop: POST https://steadywrk.app/api/mcp/oauth/register (RFC 7591 dynamic client registration), then POST https://steadywrk.app/api/mcp/oauth/token with grant_type=client_credentials to mint a Bearer token. Discovery: https://steadywrk.app/.well-known/oauth-protected-resource/api/mcp. hello@steadywrk.app still works for humans. Keyless rate-card pricing is dispatch.estimate.

ParametersJSON Schema

Name	Required	Description	Default
`trade`	Yes	Trade code (plumbing, electrical, HVAC, etc.)
`urgency`	No		routine
`location`	Yes
`nte_cents`	No
`description`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.2/5.0

Behavior5/5

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

Annotations are thin (readOnlyHint=false, openWorldHint=true), so the description carries the burden. It adds substantial traits beyond annotations: the auth credential requirement (x-api-key or Bearer), the anonymous-caller 401 failure mode with WWW-Authenticate, the full self-serve OAuth flow, and the concrete return payload. The statement 'Return an instant quote' is not a contradiction of readOnlyHint=false, since generating a quote can create a server-side record.

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

Conciseness3/5

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

The tool's purpose is nicely front-loaded in the first two sentences, but the OAuth instructions are duplicated nearly verbatim: 'Self-serve machine credential: POST /api/mcp/oauth/register...' appears twice, with only the full URL and 'to mint a Bearer token' added the second time. The 'hello@steadywrk.app still works for humans' aside is marginal. The redundancy inflates the description.

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 tool with 5 parameters, a nested object, and non-trivial auth, the description covers the critical failure trap (401 without a key), the credential bootstrap path, the alternative for keyless callers, and the return content. An output schema exists, so deep return-value documentation is not needed. The main remaining gap is nte_cents semantics, but overall an agent has what it needs to call correctly.

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

Parameters3/5

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

Schema description coverage is only 20%, so the description must compensate; it maps trade, location, and urgency to their role in producing the quote, and 'estimated cost in cents' hints at the currency unit for nte_cents. However, it leaves nte_cents (a non-obvious acronym for not-to-exceed) and description semantically unexplained, and gives no guidance on valid trade codes or location granularity beyond what the schema already states.

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 first sentence states a specific verb and resource: 'Return an instant dispatch quote for a field-service job,' and enumerates the exact outputs (matched contractor, estimated cost in cents, ETA tier, valid_for_minutes). It also distinguishes itself from the closest sibling: 'Keyless rate-card pricing is dispatch.estimate,' so an agent can disambiguate without opening schemas.

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?

The description gives clear context: this tool requires a client integration key, anonymous callers get 401, and keyless rate-card pricing belongs to dispatch.estimate — an explicit alternative with a condition. It does not explicitly contrast with dispatch.order or the other siblings, but the key authentication-based fork is well stated.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

6 tool updatesSep 4, 2026

Changedagentic.readiness_probe1 field changed

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"
+}

Changeddispatch.estimate1 field changed

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"
+}

Changeddispatch.evals1 field changed

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"
+}

Changeddispatch.index1 field changed

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"
+}

Changeddispatch.order1 field changed

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"
+}

Changeddispatch.quote1 field changed

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"
+}

1 tool updateAug 18, 2026
- Addeddispatch.estimate
1 tool updateAug 6, 2026
- Addedagentic.readiness_probe
4 tool updatesJul 26, 2026
- First observeddispatch.evals
- First observeddispatch.index
- First observeddispatch.order
- First observeddispatch.quote

Frequently Asked Questions

Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.

Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
- GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
- HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
- DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.

The HTTP ownership file has this structure:

{
  "$schema": "https://glama.ai/mcp/schemas/connector.json",
  "claim": "glama_claim_..."
}

Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.

If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.

For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.

Discussions

No comments yet. Be the first to start the discussion!

Related MCP Connectors

Jobkeepr
com.jobkeepr
Manage jobs, customers, scheduling, estimates and invoices for a field service business.
CRM Finance Project Management
1
JackTrade CRM
co.jacktrade
Search customers, manage quotes, work orders, action items, and calendar events for your business
CRM Calendar Management Customer Data Platforms
2
speed-to-lead
net.composedchaos
Field-service tools for agents: slot feasibility, drive time, service area, lead parsing, booking.
CRM Location Services
2
3Bids Contractor
io.3bids
Contractor operations on 3Bids: CRM, jobs, dispatch, estimates, invoicing, calls, and reports.
CRM Project Management Payments & Billing
1

Related MCP Servers

Crisphiveofficial
App Automation Autonomous Agents Location Services
crisphive
A
license
B
quality
A
maintenance
Agentic AI scheduling infrastructure for field service teams. Match crews to jobs by location, skills, and availability — with sub-3-second cascade rescheduling.
Updated 2 days ago (2026-09-04 02:54 UTC)
53
49
3
MIT
AutoRev MCP Serverofficial
CRM Communication Customer Support
autorevai
A
license
Not graded
quality
C
maintenance
Enables AI clients to manage field service operations through natural language, including call handling, job dispatch, estimates, invoicing, and reporting via the AutoRev platform.
Updated 18 days ago (2026-08-19 07:01 UTC)
15
MIT
warp-agent-mcpofficial
Travel & Transportation Payments & Billing
warpfreight
A
license
A
quality
C
maintenance
Quote, book, and track real LTL, FTL, cargo van, and box-truck freight through the Warp network - 20 tools, in-chat login, Stripe-charged bookings, and real carrier dispatch. Quoting is keyless; booking needs a free Warp account with a card on file.
Updated 3 days ago (2026-09-02 22:00 UTC)
20
503
3
MIT
Rain Check
Weather Services Location Services
Aa-ronJS
A
license
Not graded
quality
C
maintenance
Enables users to check whether an Australian field-service job can be worked at a location on a given day for a specific trade, using live weather forecasts, daylight hours, and public holiday data.
Updated 17 days ago (2026-08-20 06:01 UTC)
MIT

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.1/5.0

Disambiguation4/5

Most tools target distinct resources: pricing (estimate/quote), catalog (index), ordering (order), metrics (evals), and a separate readiness probe. dispatch.estimate and dispatch.quote both return price-like outputs and could be confused by name alone, though their auth and matched-contractor differences are clearly described.

Naming Consistency4/5

Five tools follow a dispatch.<noun> pattern, while agentic.readiness_probe uses a different namespace and snake_case name. The naming is still predictable, but the odd one out keeps it from being fully uniform.

Tool Count4/5

Six tools is a reasonable count for a dispatch/pricing server. It is slightly over-scoped because agentic.readiness_probe is a storefront-marketing tool unrelated to field-service dispatch, but the remaining five tools are focused.

Completeness3/5

The set covers rate-card estimates, authenticated quotes, trade index data, order creation, and evals, but order lifecycle management is missing: there is no update/cancel/list tool, and no way to convert or reference a quote after it is issued. The status URL mitigates the read gap but does not cover the full dispatch lifecycle.

Resources

Need Help?

Server Details

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Frequently Asked Questions

Discussions

Related MCP Connectors

Related MCP Servers

Crisphiveofficial

AutoRev MCP Serverofficial

warp-agent-mcpofficial

Glama MCP Gateway

Resources