Skip to main content
Glama
crisphive

Crisphive

Official
by crisphive
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

Matching crew candidates for a job

listCrewCandidates
Read-only

Find ranked technician candidates to replace a scheduled job's crew. The smart-assignment engine matches by skills, availability, travel, and time off, returning lead options with scores and session plans.

Instructions

Matching crew candidates for a job

RE-STAFFING candidates for a CONFIRMED, SCHEDULED job (not yet completed/archived) — any earlier or later stage returns 409 JOB_REQUEST_INVALID_TRANSITION. This is the pool of technicians who could REPLACE the current crew: the currently assigned lead and buddies are deliberately excluded (they are the status quo, not an option), so on a small roster an empty leads list is a normal answer, not an error. For pre-booking discovery ("who could take this job before it is confirmed?") use listJobRequestBookingWindows / listMatchingSlots / the time-segments grid instead. Candidates are matched and ranked by the smart-assignment engine — skills per crew slot, weekly availability, existing schedule, time off and travel are all checked; each carries a score breakdown (distance, travel, matched skills) plus the exact on-site session plan they would work. NOT a raw roster list (use GET /technicians for that). Returns the ranked feasible LEAD pool by default; pass include_buddies=true to also return per-slot buddy pools, include_vehicle=true to include the available-vehicle list. force_lead_id checks one specific technician: returns only that lead (with their crew combo) if feasible, else 409 JOB_REQUEST_NO_TECHNICIAN_AVAILABLE.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYesJob request ID or short_code
force_lead_idNoCheck a specific technician as lead — returns only that lead if feasible, else 409
include_buddiesNoAlso return buddy candidate pools
include_vehicleNoAlso return the available-vehicle list

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A5/5.0
Behavior5/5

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

Annotations already mark this as read-only, and the description adds meaningful behavior beyond that: the current lead and buddies are deliberately excluded, an empty leads list is normal on small rosters, 409 errors are possible, and candidates carry a score breakdown and on-site session plan. No contradiction with annotations exists.

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 dense but every sentence adds a distinct fact: purpose, stage constraints, exclusions, alternatives, matching criteria, response content, defaults, and force_lead_id behavior. The core purpose is front-loaded and no filler is present.

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?

Despite lacking an output schema, the description effectively communicates the return payload (ranked leads, per-slot buddy pools, vehicle list, score breakdown, session plan), error semantics, and normal empty case. All four parameters are behaviorally covered, and sibling-tool routing is complete.

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

Parameters5/5

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

Although the input schema has 100% description coverage, the tool description enriches the parameters by explaining defaults ('returns the ranked feasible LEAD pool by default'), the effect of include_buddies/include_vehicle, and force_lead_id's behavior including the 409 NO_TECHNICIAN_AVAILABLE fallback. This goes well beyond the schema's basic 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 description clearly identifies the tool as matching/listing re-staffing candidates for a confirmed scheduled job, with the specific resource being the crew candidate pool. It further distinguishes itself from sibling tools by stating it is NOT a raw roster list and names the pre-booking discovery alternatives.

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?

Explicitly states when to use: for RE-STAFFING a CONFIRMED, SCHEDULED job not yet completed/archived, and that any other stage yields 409 JOB_REQUEST_INVALID_TRANSITION. It also directs users to listJobRequestBookingWindows/listMatchingSlots for pre-booking and GET /technicians for raw roster, giving clear exclusions and alternatives.

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

Deploy Server

Other Tools