mcp

updateJobType

DestructiveIdempotent

Rename a job type or change its availability

Edits a catalog entry in place. A rename applies to NEW bookings only: every job stores the job-type name it was booked with, so existing and completed jobs keep their original label.

Partial update: omit a field to keep it. name rejects "" because a type must stay identifiable, and must stay unique (JOB_TYPE_DUPLICATE). Setting status to inactive is the reversible way to take a type off the booking form; inactive types are refused for new job requests.

Default quote bundle: default_duration_minutes / default_mobilization_minutes / default_demobilization_minutes follow the same partial rule; omit to keep, 0 to clear, a value to set. Clearing the duration while a buffer stays is refused (JOB_TYPE_INVALID_DEFAULT_DURATION).

priority follows the same partial rule: omit to keep, "" to clear, p0..p3 to set (JOB_TYPE_INVALID_PRIORITY otherwise). A change applies to FUTURE bookings only; existing jobs keep their priority and their surcharge snapshot.

Rows the platform ships with (is_system=true, e.g. the default "General" type) keep their name and status read-only (JOB_TYPE_SYSTEM_READ_ONLY); their default quote bundle IS editable. Create your own type if you need different wording.

Tool call template

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

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

Input Schema

Name	Required	Description
`id`	Yes	Job Type ID
`name`	No	nil = keep; min=1 rejects an explicit "".
`status`	No
`priority`	No	Priority a job of this type is booked with when the booking request names none (p0..p3). Omit = keep, "" = clear, a value = set; editable on the system "General" type too. Changing it affects FUTURE bookings only. Refused with JOB_TYPE_INVALID_PRIORITY when not p0..p3 (legacy "emergency" = p0).
`default_duration_minutes`	No	Default hands-on work duration in minutes for this kind of work (1–20160). A quote that sends no job_duration_minutes uses it, which is what lets an automation or voice agent schedule a job without knowing how long the work takes. Omit = keep, 0 = clear.
`default_mobilization_minutes`	No	Default mobilization (setup/travel-prep) minutes, 0–1440; used together with the default duration. Requires a default duration. Omit = keep, 0 = clear.
`default_demobilization_minutes`	No	Default demobilization (teardown) minutes, 0–1440; used together with the default duration. Requires a default duration. Omit = keep, 0 = clear.

Output Schema

Name	Required	Description
`data`	No	The response payload. Omitted on error unless the error carries structured data.
`errors`	No	Field-level validation details; present only for VALIDATION_ERROR responses.
`message`	No	Human-readable message ("Success" or an error description), localized via the X-Locale header.
`error_code`	No	0 on success; a stable string error code on failure (e.g. CUSTOMER_NOT_FOUND).

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 29, 2026

addedInput schema / properties / priority

Added value: +{
+  "description": "Priority a job of this type is booked with when the booking request names none (p0..p3). Omit = keep, \"\" = clear, a value = set; editable on the system \"General\" type too. Changing it affects FUTURE bookings only. Refused with JOB_TYPE_INVALID_PRIORITY when not p0..p3 (legacy \"emergency\" = p0).",
+  "example": "p1",
+  "type": "string"
+}

First observedOct 18, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Beyond the destructiveHint/idempotentHint annotations, the description discloses the blast radius (existing and completed jobs keep the old label and priority surcharge snapshot), the error codes that gate each mutation (JOB_TYPE_DUPLICATE, JOB_TYPE_SYSTEM_READ_ONLY, JOB_TYPE_INVALID_DEFAULT_DURATION, JOB_TYPE_INVALID_PRIORITY), and the read-only carve-out for shipped rows. That is exactly the extra context annotations cannot carry; only verbosity keeps it off a 5.

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?

Purpose is front-loaded in the first sentence and each subsequent paragraph maps to a concern (rename semantics, partial update, quote-bundle defaults, priority, system rows). It runs long and repeats the 'omit to keep' rule three times, which costs it the top score but not much more.

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?

An output schema exists so return values need no explanation, and annotations cover the safety profile. Against that, the description supplies every behavioral constraint an agent needs — partial semantics, uniqueness, cross-field validation, system-row protection, and the future-vs-existing job distinction.

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

Parameters4/5

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

Schema coverage is already 86%, so the baseline is 3; the description earns the bump by adding cross-field rules the schema states only partially — clearing duration while a buffer remains is refused, buffers require a duration, and priority uses ''-to-clear versus p0..p3. It reinforces rather than re-documents the field 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 opening line states a specific verb and resource ('Rename a job type or change its availability') and the second sentence clarifies the mechanism ('Edits a catalog entry in place'). This cleanly separates it from createJobType, deleteJobType and getJobType without the agent needing to open any schema.

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

Usage Guidelines5/5

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

It gives explicit when/when-not conditions: renames apply to new bookings only, inactive status is named as the reversible alternative to deletion for taking a type off the booking form, and system rows are excluded with a redirect ('Create your own type if you need different wording'). The partial-update contract (omit to keep) is stated once for every field group.

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

All mcp tools Inspect

Try in Browser

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

Glama MCP Gateway

Add one secure layer between your agents and this server.