Skip to main content
Glama
dandyer

jobkeepr-mcp

Create a job

create_job

Schedules a job for a customer, resolves the date and time from the message, and creates the customer record if new.

Instructions

Schedule/create a new job for a customer. Pull the date and time from anywhere in the user's message, including pasted or forwarded text (e.g. 'scheduled for Wednesday the 24th at 9am'). Resolve relative dates like 'next monday' or 'the 24th' using the DATE REFERENCE in your instructions. Only ask for a date/time when none appears anywhere in the message — never re-ask for one the user already provided. If the customer is new (doesn't exist yet), pass their contact details here — do NOT call create_customer separately. This tool handles creating the customer AND the job in one step. When user says 'create customer X and schedule a job', use ONLY this tool.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dateYesDate for the job. Accepts absolute or relative forms ('tomorrow', 'next monday', 'the 24th', 'feb 15th') — resolve relative dates using the DATE REFERENCE. Pull it from forwarded or pasted text too, not just direct instructions.
timeYesTime for the job (e.g., '2pm', '9am', '14:00'). Pull it from forwarded or pasted text too, not just direct instructions.
emailNoNew customer's email (only when creating a job for a new customer)
notesNoGeneral job description or notes. Use this when the user describes the job in general terms without specifying billable line items (e.g., 'check on the leak in the kitchen', 'annual maintenance visit'). Do NOT use both notes and lineItems — pick one based on user intent.
phoneNoNew customer's phone number (only when creating a job for a new customer)
sourceNoHow this customer heard about the business (e.g. 'Instagram', 'Referral word of mouth', 'Google Search'). It is saved on the customer, so it is only needed for a new customer with no source on file; the job cannot be created without it in that case. Never ask a returning customer for it. Must match one of the account's existing job sources — see `jobSources` from get_business_context, or call get_reference_data with types=job_sources. If the name does not match, the tool replies with the valid list so you can retry.
addressNoService address where the job will be performed. Always pass this when the user provides an address, whether the customer is new or existing.
lineItemsNoBillable services/products for this job. Include one entry for EVERY billable part of the work the user described, not just the main one: a mount plus wire concealment plus a bracket is three entries. Build them from the account's price catalog and pass catalogItemId on each. Do NOT use for general job descriptions — use notes instead.
serviceTypeNoType of service to be performed
customerNameYesName of the customer
durationMinutesNoHow long the appointment should last, in minutes (e.g. 180 for 3 hours, 90 for an hour and a half). Set this only when the user says how long the job will take, including when they give an end time ('9am to noon' is 180). Omit it and the account's default job duration is used.
createNewCustomerNoSet to true ONLY after this tool has asked whether an existing customer was meant, and the user answered that they want a new customer instead. It tells the tool to stop offering the existing near-matches and create the customer under the name in customerName. Never set it on a first attempt.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.0.2
  2. Removedv1.0.0
  3. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already declare this is a write, non-idempotent, closed-world operation with destructiveHint=false. The description adds substantial behavioral context beyond annotations: it creates both customer and job in one step, validates source against existing job sources and retries with valid options, and gates createNewCustomer behind a prior confirmation step.

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?

Four dense sentences, front-loaded with the primary action and then the most important edge cases: date/time extraction, relative-date resolution, and new-customer handling. Every sentence carries invocation-relevant guidance.

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 12-parameter creation tool with no output schema, the description covers the critical invocation behaviors well. It does not explain the success/return shape or broader error handling beyond the source-mismatch retry, so a small completeness gap remains.

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%, so parameter documentation is already thorough. The description repeats date/time extraction guidance that is also present in the schema and does not add new parameter-level semantics beyond that repetition.

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 verb+resource: 'Schedule/create a new job for a customer.' It also distinguishes the tool from create_customer by explicitly saying new-customer details should be passed here and that create_customer should NOT be called separately.

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?

Gives explicit when-to-use and when-not-to-use rules: use ONLY this tool when the user says 'create customer X and schedule a job,' do not call create_customer separately, and only ask for date/time when none appears in the message. The alternative path is named and excluded.

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