Wayfront

Service Write Tool

service-write

Destructive

Create or update services and sync_task_templates. Pricing, recurrence and renewal settings affect future delivery. sync_task_templates replaces the full checklist: read service-read action get_task_templates first and retain IDs that should remain. Deadlines are in HOURS, not days. Relationship collections replace their full lists; omitted fields stay unchanged.

Input Schema

TableJSON Schema

Name	Required	Description
`name`	No	Service name. Required for "create".
`price`	No	One-time price. Used when recurring=0.
`action`	Yes	Action to perform.
`public`	No	Whether service is publicly visible. Defaults to true.
`f_price`	No	Trial/setup fee price. Used when recurring=2.
`r_price`	No	Recurring price. Used when recurring>0.
`currency`	No	3-letter currency code (e.g. USD, EUR). Required for "create".
`deadline`	No	Delivery deadline in HOURS (a day is 24 hours — e.g. 3 days = 72). Convert any day-based request to hours before sending.
`metadata`	No	Array of metadata objects with "title" and "value" keys.
`employees`	No	Array of staff/team member user IDs to assign to this service. Client accounts are rejected.
`folder_id`	No	Service folder ID for organization. The folder must exist. Set to null to remove the service from its folder; omit to leave it unchanged.
`recurring`	No	Pricing type. Required for "create". 0 = one-time, 1 = recurring, 2 = trial/setup fee + recurring, 3 = recurring (other).
`f_period_l`	No	Trial/setup fee period length (1-99). Required when recurring=2.
`f_period_t`	No	Trial/setup fee period type: D (days), W (weeks), M (months), Y (years). Required when recurring=2.
`is_taxable`	No	Whether tax applies to this service. Defaults to true.
`r_period_l`	No	Recurring period length (1-99). Required when recurring>0.
`r_period_t`	No	Recurring period type: D (days), W (weeks), M (months), Y (years). Required when recurring>0.
`service_id`	No	Service id. Required when updating an existing record.
`description`	No	Service description. Max 2000 characters.
`multi_order`	No	Max orders per client (0 = unlimited).
`intake_form_id`	No	Intake form ID to associate with this service.
`request_orders`	No	Enable request-based ordering. 0 = disabled.
`task_templates`	No	For "sync_task_templates": the FULL replacement list of task templates for the service — this overwrites the existing list, it does not append. Each item supports id (for an existing template on this service), name, description, deadline (in HOURS — a day is 24 hours, so "3 days" = 72; convert day-based requests to hours), sort_order, is_public, for_client, and employee_ids (staff/team member user IDs only; client accounts are rejected). To keep an existing template, call get_task_templates first and include its id here; any existing template whose id you omit is deleted. Pass an empty array to remove all templates.
`parent_services`	No	Array of parent service IDs (makes this service an add-on).
`group_quantities`	No	Group quantities on order forms.
`recurring_action`	No	What happens on renewal (only when recurring>0). 0 = reopen the same order, 1 = create new order(s), 2 = reset/allow service requests, 3 = no action.
`max_active_requests`	No	Max active requests at once. Only when request_orders > 0.
`onboarding_form_ids`	No	Array of onboarding form IDs to attach.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 2, 2026

changedInput schema / properties / employees / description

Previous value: -"Array of employee/staff user IDs to assign to this service."New value: +"Array of staff/team member user IDs to assign to this service. Client accounts are rejected."

changedInput schema / properties / task_templates / description

Previous value: -"For \"sync_task_templates\": the FULL replacement list of task templates for the service — this overwrites the existing list, it does not append. Each item supports id (for an existing template on this service), name, description, deadline (in HOURS — a day is 24 hours, so \"3 days\" = 72; convert day-based requests to hours), sort_order, is_public, for_client, and employee_ids. To keep an existing template, call get_task_templates first and include its id here; any existing template whose id you omit is deleted. Pass an empty array to remove all templates."New value: +"For \"sync_task_templates\": the FULL replacement list of task templates for the service — this overwrites the existing list, it does not append. Each item supports id (for an existing template on this service), name, description, deadline (in HOURS — a day is 24 hours, so \"3 days\" = 72; convert day-based requests to hours), sort_order, is_public, for_client, and employee_ids (staff/team member user IDs only; client accounts are rejected). To keep an existing template, call get_task_templates first and include its id here; any existing template whose id you omit is deleted. Pass an empty array to remove all templates."

First observedSep 8, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Annotations already declare destructiveHint=true and openWorldHint=true, but the description adds the crucial detail about what is destroyed: sync_task_templates replaces the full checklist, relationship collections replace their full lists, and any omitted template whose ID you drop is deleted. It also notes omitted fields stay unchanged and that pricing/recurrence/renewal affect future delivery, which annotations do not convey.

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?

Five tight sentences, each carrying a distinct constraint (write scope, future-delivery effects, checklist replacement, deadline units, list-replacement semantics), with the most important write-vs-read routing first. Slightly telegraphic in places but no filler.

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 28-parameter destructive write tool with no output schema, the description covers the highest-risk gotchas: full-list replacement, deletion of omitted templates, unit conversion, and partial-update semantics. It leaves unaddressed things like auth/permission requirements and the shape of success responses, which a caller may still need.

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 description coverage is 100%, so the baseline is 3; the description goes beyond it by calling out the replacement-and-retention workflow for task_templates and re-emphasizing the hours-vs-days conversion for deadline. It does not add new per-field detail beyond what the schema already documents for the remaining 26 parameters.

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 specific verbs and resources: create/update services plus a third action sync_task_templates, all front-loaded in the first sentence. It also names the sibling service-read and its get_task_templates action, so an agent can distinguish read vs write and pick the right tool without opening a schema.

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?

Gives concrete sequencing guidance: read service-read action get_task_templates first and retain IDs that should remain before calling sync_task_templates. It also flags the unit trap (deadlines in HOURS, not days). No explicit exclusions or when-not-use cases are stated, but the context is clear.

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

Pay for results, not tokens.Fund a bounty. Let AI agents compete and collaborate to solve your problems.agentbounties.appAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?