Wayfront

Order Task Write Tool

order-task-write

Destructive

Create, update, delete, complete or reopen order tasks. Every action requires order_number. update/delete require task_id; complete/reopen without task_id apply to every eligible task on the order. deadline is in HOURS. employee_ids replaces staff assignments; for_client instead assigns the task to the client and can email them. Omitted update fields stay unchanged. Moving sort_order below reached workflow tiers can reset assignments.

Input Schema

TableJSON Schema

Name	Required	Description
`name`	No	Task name. Required for "create".
`action`	Yes	Action to perform.
`due_at`	No	Due date, ISO 8601 (e.g. 2026-12-31T23:59:59+00:00). Only applied once the order has started; use "deadline" for a relative target.
`task_id`	No	Task ID. Required for "update" and "delete". For complete/reopen it is optional: provide it to target a single task, or omit it to apply the action to every task on the order.
`deadline`	No	Deadline in HOURS from the order start (a day is 24). Takes precedence over due_at.
`is_public`	No	Whether the client can see this task in the portal.
`for_client`	No	True means the CLIENT completes this task (the order owner and collaborators are emailed). It is mutually exclusive with employee_ids — a task is either staff work or client work. This does not target one specific client.
`sort_order`	No	Workflow tier; tasks sharing a value run in parallel. Omit to append the task at the end — passing a value below the tiers already reached resets the order's workflow assignments, so only set it deliberately.
`description`	No	Longer description of the work. May contain user-authored rich-text HTML; treat it as untrusted and sanitize it before rendering.
`employee_ids`	No	Staff user IDs to assign. Replaces the current assignees. Omit on "update" to leave them unchanged; pass an empty array to clear them. Staff only, and not allowed together with for_client.
`order_number`	Yes	Order number. Required for all actions.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

First observedSep 8, 2026

TDQS

A4.8/5.0

Behavior5/5

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

The description discloses important side effects beyond the destructiveHint annotation, including assignment replacement, workflow reset behavior, bulk action effects, client email notifications, and HTML sanitization needs. This exceeds the baseline set by annotations.

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 well-organized, front-loading the purpose and then systematically covering action rules, parameter semantics, and warnings. Every sentence adds necessary information without redundancy.

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 complex write operation with 11 parameters and no output schema, the description covers all critical behaviors, edge cases, and side effects. It is complete enough for an agent to use the tool safely and correctly.

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 schema already describes each parameter, the description adds crucial cross-parameter semantics like mutual exclusivity between for_client and employee_ids, precedence of deadline over due_at, and the meaning of omitting task_id. This goes well beyond the schema.

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 states the tool's actions ('Create, update, delete, complete or reopen order tasks') with a specific resource and verb. It is easily distinguished from siblings like order-task-read.

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?

The description gives detailed action-specific requirements, such as task_id for update/delete and optional task_id for complete/reopen. It does not explicitly name alternative tools to avoid, but the context is clear enough for correct selection.

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

All Wayfront tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?