Wayfront

Company Write Tool

company-write

Destructive

Create, update or delete client companies (client teams) and their membership. Companies have no unique name — call company-read "list" with client_id first to check whether a client already belongs to a team before creating a new one. "add_member" requires an existing client account (create one with client-write first) and defaults collaborate_on_new_orders/collaborate_on_new_tickets to true, access_invoices to false, and share_existing_subscriptions to false. "update_member" changes only the flags supplied. "remove_member" of the current owner requires new_owner_client_id, unless they are the company's only member. Every ownership change ("create"/"update" with owner_client_id, "remove_member" with new_owner_client_id) decides whose invoices members with access_invoices can see and who manages the team in the portal, and shares the new owner's existing subscriptions with members who collaborate on orders. "delete" permanently deletes the team, its memberships, pipeline cards and SEO reporting data and cannot be undone; former members keep access to orders, tickets and subscriptions they already collaborate on (use "remove_member" first to revoke it) but lose access to the owner's invoices.

Input Schema

TableJSON Schema

Name	Required	Description
`name`	No	Company name. Max 255 characters, not unique — call company-read "list" with client_id first. Required for "create", optional for "update".
`action`	Yes	Action to perform.
`client_id`	No	Client ID of the member. Required for "add_member", "update_member" and "remove_member". Must already exist — create the client with client-write first.
`company_id`	No	Company ID. Required for "update", "add_member", "update_member", "remove_member" and "delete".
`access_invoices`	No	Whether the member can see invoices belonging to the company owner. "add_member" defaults to false.
`owner_client_id`	No	Client ID to set as the company owner. For "create", optional; the owner is attached as a member with all three flags false. For "update", moves ownership to an existing member of the company — cannot be cleared to null. Changes whose invoices members with access_invoices can see and who manages the team, and shares the new owner's existing subscriptions with members who collaborate on orders.
`new_owner_client_id`	No	Client ID of an existing other member to become the new owner. Required by "remove_member" when removing the current owner while other members remain. Shares the new owner's existing subscriptions with members who collaborate on orders.
`collaborate_on_new_orders`	No	Whether the member is added as a collaborator on the owner's new orders. "add_member" defaults to true.
`collaborate_on_new_tickets`	No	Whether the member is added as a collaborator on the owner's new tickets. "add_member" defaults to true.
`share_existing_subscriptions`	No	For "add_member" only. When true, this client's existing subscriptions are shared with company members who collaborate on orders, so they can submit requests. Defaults to false. Only set true when the user explicitly asks to share the client's existing subscriptions with the team.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedSep 21, 2026

changedInput schema / properties / new_owner_client_id / description

Previous value: -"Client ID of an existing other member to become the new owner. Required by \"remove_member\" when removing the current owner while other members remain."New value: +"Client ID of an existing other member to become the new owner. Required by \"remove_member\" when removing the current owner while other members remain. Shares the new owner's existing subscriptions with members who collaborate on orders."

changedInput schema / properties / owner_client_id / description

Previous value: -"Client ID to set as the company owner. For \"create\", optional; the owner is attached as a member with all three flags false. For \"update\", moves ownership to an existing member of the company — cannot be cleared to null. Changes whose invoices members with access_invoices can see and who manages the team."New value: +"Client ID to set as the company owner. For \"create\", optional; the owner is attached as a member with all three flags false. For \"update\", moves ownership to an existing member of the company — cannot be cleared to null. Changes whose invoices members with access_invoices can see and who manages the team, and shares the new owner's existing subscriptions with members who collaborate on orders."

Changed1 schema field changedSep 21, 2026

addedInput schema / properties / share_existing_subscriptions

Added value: +{
+  "description": "For \"add_member\" only. When true, this client's existing subscriptions are shared with company members who collaborate on orders, so they can submit requests. Defaults to false. Only set true when the user explicitly asks to share the client's existing subscriptions with the team.",
+  "type": "boolean"
+}

Changed2 schema fields changedSep 17, 2026

changedInput schema / properties / action / enum

Previous value: -[
-  "create",
-  "update",
-  "add_member",
-  "update_member",
-  "remove_member"
-]New value: +[
+  "create",
+  "update",
+  "add_member",
+  "update_member",
+  "remove_member",
+  "delete"
+]

changedInput schema / properties / company_id / description

Previous value: -"Company ID. Required for \"update\", \"add_member\", \"update_member\" and \"remove_member\"."New value: +"Company ID. Required for \"update\", \"add_member\", \"update_member\", \"remove_member\" and \"delete\"."

AddedSep 15, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations only declare readOnlyHint=false and destructiveHint=true. The description adds substantial behavioral detail: the non-unique name caveat, default flag values for add_member, the system-wide side effects of ownership changes (invoice visibility, portal management, subscription sharing), and the permanent, irreversible nature of delete including what data is destroyed. This goes well beyond the annotations.

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?

The description is a single dense paragraph that front-loads the purpose but then packs many behavioral rules into run-on sentences. Every claim is relevant and the length is justified for a six-action tool, but it would be more scannable with bullet points or clearer segmentation.

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 tool with six actions and 10 parameters, the description covers the essential preconditions (company-read first, client-write first), action-specific requirements (new_owner_client_id), default values, side effects, and the irreversible delete outcome. No output schema exists, but the tool is a write operation and return-value details are not essential for correct invocation.

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 100%, so baseline is 3. The description adds cross-parameter meaning beyond the schema by explaining how owner_client_id and new_owner_client_id affect invoice visibility and subscription sharing, and that update_member changes only the flags supplied. This elevates the agent's understanding of the parameters' interactions.

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 opens with a specific verb set and resource: 'Create, update or delete client companies (client teams) and their membership.' It mentions the sibling company-read tool and instructs calling it first, clearly distinguishing write behavior from read behavior.

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?

It explicitly tells the agent to call company-read 'list' with client_id first to check for existing teams, and to create a client with client-write before add_member. It also explains when new_owner_client_id is required for remove_member and how update_member differs from add_member, giving clear when/when-not guidance.

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?