STEADYWRK Field Service Dispatch

Read dispatch evaluations

dispatch.evals

Read-onlyIdempotent

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.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`period`	No		rolling_30d

Output Schema

TableJSON 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

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

Changed1 schema field changedSep 4, 2026

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

First observedJul 26, 2026

TDQS

A4.5/5.0

Behavior5/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters3/5

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.

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') 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.

Usage Guidelines4/5

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.

All STEADYWRK Field Service Dispatch tools Inspect

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

A3.7/5.0

Disambiguation4/5

dispatch.estimate, dispatch.quote, and dispatch.index all touch pricing, but their descriptions clearly distinguish public modeled estimates from credentialed quotes and reference catalog data. dispatch.order and dispatch.evals are distinct, while agentic.readiness_probe is unrelated but unambiguous.

Naming Consistency4/5

Most tools follow a consistent dispatch.<noun/verb> pattern with lowercase single-word names like dispatch.quote and dispatch.order. The agentic.readiness_probe tool breaks the pattern with a different prefix and underscore suffix, and dispatch.evals uses an abbreviation, but the overall convention remains readable and mostly predictable.

Tool Count4/5

Six tools is a reasonable, well-scoped count for a field-service dispatch server. However, agentic.readiness_probe appears to belong to a separate storefront-readiness product, which slightly dilutes the server's focus even though the count itself is not excessive.

Completeness3/5

The set covers public pricing estimates, quotes, reference data, methodology documentation, and order creation. It lacks order status, update, list, or cancel operations, and fulfillment is only represented by a returned status URL. That leaves a notable lifecycle gap for a server named Field Service Dispatch.

Resources

Need Help?