Skip to main content
Glama

Preview emergency insert + cascade reschedule

previewEmergencyReschedule

Preview the cascade of inserting an emergency job onto a technician, showing the emergency location and every job pushed back grouped by day. Read-only; supports overtime, next-day, and reassign modes.

Instructions

Preview emergency insert + cascade reschedule

Computes (WITHOUT writing) the cascade of inserting an emergency job onto a technician at a chosen time: where the emergency lands + every job pushed back, grouped per business-local day. displacement_mode=reassign instead hands each displaced job to another feasible technician at its ORIGINAL window (same-day promise) — jobs with no alternate capacity fall back to reschedule and stay in days. mode=overtime keeps everyone same-day (tech works late); mode=next_day rolls overflow to the next working day(s). Read-only — safe to call repeatedly; commit is a separate endpoint. Isolated feature (see EMERGENCY_RESCHEDULE_DESIGN.md). 409 NEXT STEPS: EMERGENCY_RESCHEDULE_SLOT_OCCUPIED — the landing window is blocked by a job the cascade may NOT move (another P0, a crew or multi-day job): choose another technician (walk the /candidates ranking) or another time; displacement never touches P0/crew/multi-day anchors. EMERGENCY_RESCHEDULE_NOT_ELIGIBLE / CREW_UNSUPPORTED / MULTIDAY_UNSUPPORTED / NO_WORKING_DAY / IN_PAST — same remedies as /candidates.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
modeYesCascade mode: overtime = displaced jobs stay same-day (tech works late); next_day = overflow rolls to the next working day.
start_atYesDesired start — business-local naive datetime, no offset. Must be in the future.
technician_idYesTarget technician (must belong to the business).
idempotency_keyNoOptional idempotency key (forwarded as the Idempotency-Key header). Reuse the same value when retrying so the operation runs at most once.
emergency_job_idYesID of the P0 job to insert.
displacement_modeNoFate of displaced jobs: reschedule (default — pushed to later windows) or reassign (handed to another feasible technician at their ORIGINAL time; no-capacity jobs fall back to reschedule).
Behavior1/5

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

Description claims 'Read-only' and 'Computes (WITHOUT writing)' but annotation readOnlyHint is false, constituting a direct contradiction. This undermines agent trust.

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?

Well-structured with front-loaded purpose, mode details, safety note, and error codes. Slightly long but every section earns its place.

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

Completeness3/5

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

Covers essential behavior and error handling, but no output schema exists and description does not explain the return format (e.g., the structure of the preview). Adequate for a preview tool but could be more complete.

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 coverage is 100% (all parameters described). Description adds contextual explanation of modes and displacement but does not provide significant value beyond the 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?

Clearly states it computes a cascade preview without writing, distinguishes from commit sibling via explicit 'Read-only — safe to call repeatedly; commit is a separate endpoint.'

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?

Provides error codes and next steps, mentions isolation feature reference. Could explicitly contrast with previewJobRequestMove or state when not to use, but context is adequate.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/crisphive/crisphive-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server