WorkWing

Create a job

create_job

Create a job for a customer. This writes to the user's live system and other people will act on it, so state the customer, the site, the work and any time back to the user and get their agreement BEFORE calling this. Take customer_id and location_id from find_customer; never guess either. A job with no site is a job nobody can be sent to, so when the customer has more than one, agree which before calling rather than letting it default. The job is created in its customer's brand (a project's unit, in the project's), and its template must come from that brand too; when the user named a brand, pass it as brand so a mismatch is refused rather than landing the job elsewhere. Report the job number, its brand and every entry in warnings back to the user.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`brand`	No	The brand the user wants this job in, by id or name. Optional: the job always goes in the brand of its customer (or project), and naming a different one is refused, so pass it when the user named a brand to have that checked.
`notes`	No	Anything else the user said.
`title`	Yes	Short description of the work, as the user described it.
`priority`	No		T_NORMAL
`project_id`	No	From find_project. Creates this job as a unit of that project, inheriting its customer, brand and default location.
`customer_id`	No	From find_customer. Never guess or construct this. Required unless project_id is given, in which case the project's own customer is used.
`location_id`	No	The site the work happens at, from the `locations` of the customer returned by find_customer. Must be one of that customer's sites. Leave it out to use their primary site.
`template_id`	No	Job template to create against, when the tenant uses one.
`custom_fields`	No	Tenant-defined fields, keyed by field key.
`scheduled_end`	No
`scheduled_start`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 16, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Goes well beyond the annotations (which only say write/non-destructive/non-idempotent/closed-world): it discloses that this writes to a live system other people act on, that brand inheritance rules apply, that a brand mismatch is refused rather than silently relocated, and that the response carries a job number and a `warnings` array to relay to the user. That is exactly the operational context annotations cannot express.

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?

Front-loaded with the action and the confirm-first rule, and every sentence carries a constraint or a consequence. It is dense and somewhat long for a single paragraph, with the brand/inheritance rules stacked toward the end, but there is little filler.

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 high-risk mutation with 11 parameters and no output schema, it covers the decision inputs (confirmation, ID sourcing, site resolution, brand validation) and the return surface (job number, brand, warnings). Nothing an agent needs to call it safely appears missing.

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 73% and already documents brand, customer_id, location_id and project_id in detail. The description reinforces the highest-risk ones with rationale (why a site must be agreed rather than defaulted, why brand is passed for validation), adding judgment beyond the field text, though it says nothing about priority, custom_fields, or the scheduled_* timestamps.

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 ('Create a job for a customer') and immediately distinguishes itself from sibling mutations like schedule_job, cancel_job and add_job_note by scoping the effect to a customer's live system. An agent can identify the operation without opening the 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?

Explicit preconditions and sequencing: confirm customer, site, work and time with the user BEFORE calling; source customer_id/location_id from find_customer and never guess; resolve the site when the customer has multiple. It names the sibling to use for sourcing IDs and the failure mode (job nobody can be sent to) that the guidance prevents.

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

All WorkWing 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.

Resources

Need Help?